Security hardening guide
This document provides an overview of security features and guidance for hardening the security of Charmed MySQL K8s deployments, including setting up and managing a secure environment.
Environment
The environment where Charmed MySQL K8s operates can be divided into two components:
- Kubernetes
- Juju
Kubernetes
Charmed MySQL K8s can be deployed on top of several Kubernetes distributions. The following table provides references for the security documentation for the main supported cloud platforms.
| Cloud | Security guides |
|---|---|
| Charmed Kubernetes | Security in Charmed Kubernetes |
| AWS EKS | Best Practices for Security, Identity and Compliance, AWS security credentials, Security in EKS |
| Azure | Azure security best practices and patterns, Managed identities for Azure resource, Security in AKS |
| GCP GKE | Google security overview, Harden your cluster’s security |
Juju
Juju is the component responsible for orchestrating the entire lifecycle, from deployment to Day 2 operations. For more information on Juju security hardening, see the Juju security page and the How to harden your deployment guide.
Cloud credentials
When configuring cloud credentials to be used with Juju, ensure that users have the correct permissions to operate at the required level on the Kubernetes cluster. Juju superusers responsible for bootstrapping and managing controllers require elevated permissions to manage several kinds of resources. For this reason, the K8s user for bootstrapping and managing the deployments should have full permissions, such as:
- create, delete, patch, and list:
- namespaces
- services
- deployments
- stateful sets
- pods
- PVCs
In general, it is common practice to run Juju using the admin role of K8s, to have full permissions on the Kubernetes cluster.
Juju users
It is very important that Juju users are set up with minimal permissions depending on the scope of their operations. Please refer to the User access levels documentation for more information on the access levels and corresponding abilities.
Juju user credentials must be stored securely and rotated regularly to limit the chances of unauthorized access due to credentials leakage.
Applications
In the following sections, we provide guidance on how to harden your deployment using:
- Base images
- Charmed operator security upgrades
- Encryption
- Authentication
- Monitoring and auditing
Base images
Charmed MySQL K8s and Charmed MySQL Router K8s run on top of the same rock (OCI-compliant rockcraft-based image). The rock is based on Ubuntu 22.04 and ships the MySQL distribution binaries built by Canonical. It is stored in a GitHub registry and is used as the base image for different pods providing MySQL services.
Charmed operator security upgrades
Charmed MySQL K8s operator and Charmed MySQL Router K8s operator install pinned versions of the rock to provide reproducible and secure environments. New versions (revisions) of charmed operators can be released to update the operator’s code, workloads, or both. It is important to refresh the charm regularly to make sure the workload is as secure as possible.
For more information on upgrading Charmed MySQL K8s, see the How to upgrade MySQL and How to upgrade MySQL Router guides, as well as the Release notes.
Encryption
By default, encryption is optional for external connections. Internal communication between cluster members is always encrypted with TLS with self-signed certificates.
To enforce encryption in transit for external connections, integrate Charmed MySQL K8s with a TLS certificate provider. Please refer to the Charming Security page for more information on how to select the right certificate provider for your use case.
Encryption in transit for backups is provided by the storage service (Charmed MySQL K8s is a client for an S3-compatible storage).
For more information on encryption, see the Cryptography explanation page and How to enable encryption guide.
Authentication
Charmed MySQL K8s uses the caching_sha2_password plugin for authentication.
Monitoring and auditing
Charmed MySQL K8s provides native integration with the Canonical Observability Stack (COS). To reduce the blast radius of infrastructure disruptions, the general recommendation is to deploy COS and the observed application into separate environments, isolated from one another. Refer to the COS production deployments best practices for more information or see the How to guides for MySQL K8s monitoring, alert rules, and tracing for practical instructions.
The Audit log plugin is enabled by default and produces login/logout logs. See the Audit Logs guide for further configuration. These logs are stored in the /var/log/mysql directory of the MySQL container and are rotated every minute to the /var/log/mysql/archive_audit directory. It’s recommended to integrate the charm with COS, from where the logs can be easily persisted and queried using Loki/Grafana.
Additional Resources
For details on the cryptography used by Charmed MySQL K8s, see the Cryptography explanation page.