Charmed MySQL K8s Tutorial - Enable security with TLS

Enable encryption with TLS

Transport Layer Security (TLS) is a protocol used to encrypt data exchanged between two applications. Essentially, it secures data transmitted over a network.

Typically, enabling TLS internally within a highly available database or between a highly available database and client/server applications requires a high level of expertise. This has all been encoded into Charmed MySQL K8s so that configuring TLS requires minimal effort on your end.

TLS is enabled by integrating Charmed MySQL K8s with the Self Signed Certificates Charm. This charm centralises TLS certificate management consistently and handles operations like providing, requesting, and renewing TLS certificates.

In this section, you will learn how to enable security in your MySQL K8s deployment using TLS encryption.

Self-signed certificates are not recommended for a production environment.

Check this guide for an overview of the TLS certificates charms available.


Configure TLS

Before enabling TLS on Charmed MySQL K8s we must first deploy the self-signed-certificates charm:

juju deploy self-signed-certificates --config ca-common-name="Tutorial CA"

Wait until self-signed-certificates is up and active, use juju status --watch 1s to monitor the progress:

Model     Controller  Cloud/Region        Version  SLA          Timestamp
tutorial  overlord    microk8s/localhost  2.9.38   unsupported  23:04:02+01:00

App                        Version   Status  Scale  Charm                      Channel      Rev  Address         Exposed  Message
mysql-k8s                  8.0.31    active      2  mysql-k8s                  8.0/stable   36   10.152.183.234  no       
self-signed-certificates             active      1  self-signed-certificates   stable   72   10.152.183.76   no       

Unit                          Workload  Agent  Address      Ports  Message
mysql-k8s/0*                  active    idle   10.1.84.74          Unit is ready: Mode: RW
mysql-k8s/1                   active    idle   10.1.84.127         Unit is ready: Mode: RO
self-signed-certificates/0*   active    idle   10.1.84.71 

Add external TLS certificate

To enable TLS on Charmed MySQL, relate the two applications:

juju relate mysql-k8s self-signed-certificates

Check the TLS certificate in use:

Use openssl to connect to the MySQL and check the TLS certificate in use:

> openssl s_client -starttls mysql -connect 10.1.84.74:3306 | grep Issuer
...
depth=1 C = US, CN = Tutorial CA
...

Congratulations! MySQL is now using TLS certificate generated by the external application self-signed-certificates.

Remove external TLS certificate

To remove the external TLS and return to the locally generated one, remove the relation:

juju remove-relation mysql-k8s self-signed-certificates

Check the TLS certificate in use:

> openssl s_client -starttls mysql -connect 10.1.84.74:3306 | grep Issuer

The output should be similar to:

...
Issuer: CN = MySQL_Server_8.0.31_Auto_Generated_CA_Certificate
...

The Charmed MySQL K8s application reverted to the certificate that was created locally during the MySQL server installation.

Does we really need to wait here? Can the charm not do the right thing for us in this case (only perform the specified action when it’s reached the correct status)? Having this requirement would mean that deploying via some automation like Terraform would be significantly harder.

Hi @mthaddon! Thanks for this. Yes, indeed. The charm should already be able to handle this such that one can deploy secured mysql with security via bundles (either charm bundle or terraform). So, if you encounter some problems with this, please raise an issue with us.

However here we are within a tutorial and we are sort of guiding the user through the deployment, providing a “lesson”. The “Wait until” is not really quite a hard constraint but more of a teaching flow to the user, where we also show him the expected output after deploying the charm

Thanks, good to know.