SPIFFE authentication

Configuration

SPIFFE configuration is enabled per-user by means of the user attribute: ‘spiffe_id‘. This user attribute should be configured with the name of the specific SPIFFE workload in which ProxySQL is going to be deployed. E.g.: ‘{“spiffe_id”: “spiffe://example.org/workload-proxysql”}’. Please note that the first part of the SPIFFE identifier, i.e. “spiffe://” isn’t optional and should be always present.

For making use of SPIFFE in a client connection, there are two requirements that should be fulfilled:

  • User attribute spiffe_id should be modified for the users which are going to be used in the SPIFFE connections. After modifying the attribute, command: ‘LOAD MYSQL USERS TO RUNTIME‘ should be issued.
  • A client SSL connection supplying a certificate that can be verified against proxysql-cert.pem and which contains and X509v3 Subject Alternative Name (SAN URI) with the same ‘id’ as specified in the user attribute spiffe_id. E.g.: ‘X509v3 Subject Alternative Name: URI:spiffe://example.org/workload-proxysql’. Please note that the first part of the SPIFFE identifier set as part of the SAN URI, i.e. “spiffe://” isn’t optional and should be always present.

Since ProxySQL version v2.4.0, it’s possible to use regular expressions in the user attribute, this allows one user to match with several certificates as long as the X509v3 Subject Alternative Name (SAN URI) they provide satisfies the regex. To activate the regex processing of ‘spiffe_id’ user attribute, this should start with an exclamation mark (‘!’). For example, user attribute:

'{"spiffe_id": "!spiffe:\/\/example\\.org\/workload-proxysql\/.*"}'

will allow authentication against certificates supplying X509v3 Subject Alternative Name (SAN URI) of the following kind:

spiffe://example.org/workload-proxysql/service-A
spiffe://example.org/workload-proxysql/service-B
spiffe://example.org/workload-proxysql/service-C
... etc ...

Important Note: ProxySQL doesn’t support mTLS support for SSL connections, it’s just in case a client connection supplies a certificate which holds a SAN URI identifier starting with ‘spiffe‘, like in the previously given example, that ProxySQL will perform the verification of the client certificate against proxysql-cert.pem.

Integration of intermediate CA certs

In case of using SPIRE or other SPIFFE implementation that generates intermediate CA certificates, this certificates should be bundle into proxysql-ca.pem. E.g:

Supposing that we have:

  • Intermediate CA certificate: IntermediateCA.pem
  • The current CA certificate file: proxysql-ca.pem

Bundling both would be a matter of:

cat IntermediateCA.pem proxysql-ca.pem >> proxysql-ca.pem.tmp && mv proxysql-ca.pem.tmp proxysql-ca.pem

After this, ProxySQL should be able to verify the client supplied certificate.

Limitations

Due to the nature of how SPIFFE works, the fact that it’s a per-user capability and how authentication is performed, command ‘COM_CHANGE_USER‘ is not supported for connections that are making use of SPIFFE authentication.