Skip to main content

MySQL

Otterize is able to create just-in-time username-and-password pairs for your workload, providing them as a Kubernetes Secret that can be mounted to file or mapped to environment variables, as well as GRANTing access to databases and tables, based on ClientIntents (Intent-Based Access Control) declarations.

Tutorials

To learn how to use the Intents Operator and Credentials Operator to enforce access using MySQL GRANTs, try one of these quickstart tutorials:

How does Otterize work with MySQL?

The Otterize credentials operator will create a unique MySQL username-password combination for each workload's use, exposed via a Kubernetes Secret. The workload will use these credentials to connect to the database. ClientIntents will define the access required by that workload. As the intents are applied, The Otterize intents operator will keep the database's list of users and GRANTs up to date so that the workload is able to access it.

  1. To get started, your cluster must have Otterize deployed.
  2. You'll need to create a MySQLServerConfig in your cluster, providing a connection URL and admin-level credentials for Otterize to manage permissions in your database. Below is an example MySQLServerConfig resource.
apiVersion: k8s.otterize.com/v2beta1
kind: MySQLServerConfig
metadata:
name: mysql-tutorial-db # database instance name - should match the target in ClientIntents
namespace: otterize-tutorial-mysql
spec:
address: <HOST:PORT> # Your MySQL servers address
credentials:
# Username Otterize will connect with & configure permissions as; optional, can be omitted if using a secretRef
username: <USER>
# Password for the above username; optional, can be omitted if using a secretRef
password: <PASSWORD>
# Secret containing the database credentials; optional, can be omitted if using the above username & password fields
secretRef:
# Name of the secret containing the database credentials; required
name: mysql-credentials
# Namespace where the secret is stored; optional, defaults to the namespace of the MySQLServerConfig
namespace: otterize-tutorial-mysql
# Key in the secret containing the username; optional, defaults to 'username'
usernameKey: username
# Key in the secret containing the password; optional, defaults to 'password'
passwordKey: password
  1. Each workload can request a username-password Secret to be created, by annotating the Pod with credentials-operator.otterize.com/user-password-secret-name. Below is an example of that annotation and passing the generated credentials into a container with environmental variables.
apiVersion: apps/v1
kind: Deployment
metadata:
name: server
spec:
replicas: 1
selector:
matchLabels:
app: server
template:
metadata:
annotations:
credentials-operator.otterize.com/user-password-secret-name: server-creds
labels:
app: server
spec:
serviceAccountName: server
containers:
- name: server
imagePullPolicy: Always
image: 'supercool/my-example-container'
ports:
- containerPort: 80
env:
- name: DB_SERVER_USER
valueFrom:
secretKeyRef:
name: server-creds
key: username
- name: DB_SERVER_PASSWORD
valueFrom:
secretKeyRef:
name: server-creds
key: password
  1. Apply ClientIntents and the specified access will be GRANTed to the workload in the ClientIntents.
apiVersion: k8s.otterize.com/v2beta1
kind: ClientIntents
metadata:
name: client-intents-for-server
namespace: otterize-tutorial-mysql
spec:
workload:
name: server
kind: Deployment
targets:
- sql:
name: mysql-tutorial-db # Same name as MySQLServerConfig metadata.name
privileges:
- databaseName: otterize-tutorial
table: example
operations:
- SELECT
- INSERT
  1. Done!