MySQL

ManagementCore APIServices

MySQL

Setting the Service mode to MYSQL enables it to operate in application-layer aware MySQL mode. This mode enables you to provide secretless access for Users to the protected upstream MySQL-based server without having to share the upstream's password. This mode also provides you with clear application-layer aware visibility where your MySQL sessions and queries are logged and audited in real-time.

Secretless Access

Secretless access enables you to provide secretless access for authorized Users to MYSQL-based Service by automatically injecting passwords to authenticate to the upstream MySQL database, and force the User to connect to the upstream as a specific user, possibly with a certain role corresponding to specific permissions, to a specific database.

First, you need to create a Secret to store the password of your upstream SSH server (read more here) as follows:

octeliumctl create secret mariadb-password
# OR via a --value flag
octeliumctl create secret --value <PASSWORD> mariadb-password
# OR via a --file flag
octeliumctl create secret --file /PATH/TO/PASSWORD mariadb-password

Now, you define your Service as follows:

1kind: Service
2metadata:
3  name: mariadb
4spec:
5  mode: MYSQL
6  port: 3306
7  config:
8    upstream:
9      url: mysql://address-to-db
10    mysql:
11      user: root
12      database: mysql
13      auth:
14        password:
15          fromSecret: mariadb-password

Now, the above configuration forces the User to authenticate as root with the password value set in the Secret mariadb-password and connect to the database mysql regardless of the information supplied by the downstream.

NOTE

You can see more examples for PlanetScale databases here.

NOTE

For now, authorized Users have to use an empty password value to access the Service.

NOTE

For internal/private MySQL upstreams behind NAT, you need to remotely serve them via a connected octelium client or container as discussed here.

If the upstream database is serving over TLS, you have to use the isTLS boolean field as follows:

1kind: Service
2metadata:
3  name: mariadb
4spec:
5  mode: MYSQL
6  port: 3306
7  config:
8    upstream:
9      url: mysql://address-to-db
10    mysql:
11      user: root
12      database: mysql
13      auth:
14        password:
15          fromSecret: mariadb-password
16      isTLS: true

Access Control

You can control access based on the MySQL request information. Such information are stored in ctx.request.mysql where it contains the username and database. Here is a detailed example of a inline Policy that controls access based on MySQL-specific information:

1kind: Service
2metadata:
3  name: svc1
4spec:
5  mode: MYSQL
6  port: 1234
7  config:
8    upstream:
9      url: mysql://address-to-db
10    # rest of the config
11  authorization:
12    inlinePolicies:
13      - spec:
14          rules:
15            - effect: ALLOW
16              condition:
17                any:
18                  of:
19                    - match: ctx.request.mysql.connect.user == "db-user-1"
20                    - match: ctx.request.mysql.connect.database == "db-01"

NOTE

You do not actually need to control access by checking against the database user since you already override the database user in your Service configuration as illustrated above regardless of the database user value provided by the User. You can also use dynamic configuration in order to map different databases and/or database users to different Users under different conditions. You can read more about dynamic configuration here

Dynamic Configuration

You can use dynamic configuration (read more about dynamic configuration here) to, for example, route to different upstreams or different database users with different privileges and roles (e.g. more privileged Users can automatically delete tables or databases while other Users cannot do so) based on identity and/or context. Here is an example:

1metadata:
2  name: example-svc
3spec:
4  mode: MYSQL
5  dynamicConfig:
6    configs:
7    - name: prod
8      upstream:
9        url: mysql://address
10      mysql:
11        user: prod
12        database: prod-db
13        auth:
14          password:
15            fromSecret: prod-password
16    - name: dev
17      upstream:
18        url: mysql://address
19      mysql:
20        user: dev
21        database: dev-db
22        auth:
23          password:
24            fromSecret: dev-password
25    rules:
26    - condition:
27        match: '"prod" in ctx.user.spec.groups'
28      configName: prod
29    - condition:
30        matchAny: true
31      configName: dev

Visibility

The Service emits access logs in real time to the audit collector. Each log provides MySQL application-layer aware information about the request such as the command type, the query details, etc.... Here is an example:

1{
2  "apiVersion": "core/v1",
3  "kind": "Log",
4  "metadata": {
5    // Omitted for the sake of brevity of the example
6  },
7  "entry": {
8    "service": {
9      "info": {
10        "common": {
11          "status": "ALLOWED"
12          // Omitted for the sake of brevity of the example
13        },
14        "mysql": {
15          "query": {
16            "query": "CREATE DATABASE db01;"
17          },
18          "type": "QUERY"
19        }
20      }
21      // Omitted for the sake of brevity of the example
22    }
23  }
24}

As you can see in the above example, the type of this MYSQL access Log is a QUERY. The MYSQL mode has currently 8 Log types: SESSION_START, SESSION_END, QUERY, PARSE, CLOSE, EXECUTE, BIND, FUNCTION_CALL and some of these types include different detailed information according to their type. You can read more in the API reference.

On this Page

Dynamic Configuration

Visibility