Kubeflow

Channel Revision Published
latest/candidate 294 24 Jan 2022
latest/beta 430 30 Aug 2024
latest/edge 438 30 Jun 2025
1.10/stable 440 05 Aug 2025
1.10/candidate 441 05 Aug 2025
1.10/beta 433 24 Mar 2025
1.9/stable 432 03 Dec 2024
1.9/beta 420 19 Jul 2024
1.9/edge 431 03 Dec 2024
1.8/stable 414 22 Nov 2023
1.8/beta 411 22 Nov 2023
1.8/edge 413 22 Nov 2023
1.7/stable 409 27 Oct 2023
1.7/beta 408 27 Oct 2023
1.7/edge 407 27 Oct 2023
juju deploy kubeflow --channel 1.9/edge
Show information

Platform:

Ubuntu

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:

  1. Kubernetes (K8s).
  2. 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:

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.


Help improve this document in the forum (guidelines). Last updated 2 months ago.