This guide presents an overview of security features and guidance for hardening the security of Charmed Kubeflow (CKF) deployments.
Environment
The environment where CKF applications operate can be divided into two components:
- Kubernetes (K8s).
- Juju.
Kubernetes
CKF can be deployed on top of several K8s distributions.
The following table provides references to the security documentation for the main supported cloud platforms:
| Cloud | Security guide |
|---|---|
| Charmed Kubernetes | Security in Charmed Kubernetes |
| AWS EKS | Best practices, AWS security credentials, Security in EKS |
| Azure AKS | Best practices, Managed identities for Azure resource, Security in AKS |
| Google GKE | Security overview |
Juju
Juju is the component responsible for orchestrating the entire lifecycle, from deployment to day-2 operations, of CKF applications. Therefore, it is critical to set it up securely.
See the following documentation for more details:
Cloud credentials
When configuring cloud credentials to be used with Juju, ensure that users have correct permissions to operate at the required level on the K8s cluster.
Juju superusers responsible for bootstrapping and managing controllers require elevated permissions to manage several kinds of resources.
For this reason, the K8s user used for bootstrapping and managing deployments should have full permissions, including the ability to create, delete, patch, and list:
-
Namespaces.
-
Services.
-
Deployments.
-
Stateful sets.
-
Pods.
-
Persistent volume claims (PVCs).
In general, it is common practice to run Juju using the K8s admin role to ensure full permissions on the cluster.
Juju users
It is essential that Juju users are granted only the minimum permissions required for their scope of operations. See User access levels for more details.
Juju user credentials must be stored securely and rotated regularly to reduce the risk of unauthorized access due to credential leakage.
Applications
This section outlines methods to enhance the security of your CKF applications.
Base images
CKF runs on top of Rock images, available in these Github repositories, on top of Ubuntu 22.04.
Security upgrades
CKF uses pinned revisions of Rocks. Charms are refreshed to a newer revision periodically, but each revision is pointing to a specific Rock hash. This provides reproducible and secure environments.
New versions of these Rocks and Charms may be released to provide patching of vulnerabilities (CVEs).
It is important to refresh charms regularly to make sure the workload is as secure as possible. See Upgrade for details on how to upgrade CKF.
Encryption
Encryption for CKF is enabled via HTTPs, through a Transport Layer Security (TLS) certificate. See Enable HTTPS for more details.
CKF uses Istio Gateway as the ingress, and this gateway is configured via Istio Pilot with the TLS secret.
Authentication
See Authentication to learn about how authentication works in CKF.
Authorisation
See Authorisation to learn about how authorisation works in CKF.
Cryptography
See Cryptography for an overview of all cryptographic processes in CKF.
Monitoring and auditing
CKF provides integration with the Canonical Observability Stack (COS).
To reduce the blast radius of infrastructure disruptions, it is generally recommended to deploy COS and the observed application in separate, isolated environments. See COS production deployments best practices for more details.
See Integrate with COS to learn how CKF and COS can be integrated using Juju.