Kubeflow

  • Kubeflow Charmers | bundle
  • Cloud
Channel Revision Published
latest/candidate 294 24 Jan 2022
latest/beta 430 30 Aug 2024
latest/edge 423 26 Jul 2024
1.9/stable 426 31 Jul 2024
1.9/beta 420 19 Jul 2024
1.9/edge 425 31 Jul 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/beta
Show information

Platform:

This guide describes how to enable HTTPS on Charmed Kubeflow (CKF) through a Transport Layer Security (TLS) certificate.

TLS is a cryptographic protocol designed to provide secure communication over a computer network. It ensures privacy, data integrity, and authenticity between communicating applications. By enabling HTTPS,which uses TLS, in your Charmed Kubeflow setup, you protect the data transmitted between clients and the Kubeflow services from being intercepted or tampered with. See Transport Layer Security for more details.

Prerequisites

Before you can enable HTTPS in your CKF deployment, you need to obtain a domain and create a TLS certificate for that domain. This process varies depending on the cloud provider or certificate authority you choose. Below are some resources to help you generate certificates and set up domain names on different cloud platforms:

Setting up a domain name

Obtaining a TLS certificate

Passing TLS certificate and key values

To pass the TLS certificate and key values, do the following:

  1. Create a user secret to hold the TLS certificate and key values (as strings):
juju add-secret istio-tls-secret tls-crt="$(cat CERT_FILE)" tls-key=$"$(cat KEY_FILE)"

where

  • tls-crt holds the value of the TLS certificate file as a string.
  • tls-key holds the value of the TLS key file as a string.
  1. Grant istio-pilot access to the secret:
juju grant-secret istio-tls-secret istio-pilot
  1. Pass the secret ID as configuration:
juju config istio-pilot tls-secret-id=secret:<secret ID resulting from step 1>

Configuring self-signed certificates

If you are using self-signed certificates, you need to configure the oidc-gatekeeper with the Certificate Authority (CA) bundle to ensure proper validation.

This step is typically unnecessary for public cloud certificates, as their CAs are already trusted by browsers.

To configure oidc-gatekeeper with the CA, follow these steps:

  1. Create a CA bundle file that includes your self-signed CA certificate:
cat <<EOF > /path/to/ca-bundle.crt

-----BEGIN CERTIFICATE-----

# Your CA certificate content

-----END CERTIFICATE-----
EOF
  1. Update the oidc-gatekeeper configuration to use the CA bundle:
juju config oidc-gatekeeper ca-bundle="$(cat /path/to/ca-bundle.crt)"

Migrating from configuration to action

Passing the TLS certificate and key using Juju secrets means replacing the ssl-* configuration options for the istio-pilot . This migration is as simple as doing:

juju refresh istio-pilot

It implies the following considerations:

  1. The ssl-key and ssl-crt values passed as configuration options will be lost. It is recommended to save them before upgrading.
  2. A downtime is expected while upgrading to newer versions of istio-pilot as the Ingress Gateway has to be reconfigured. This is expected to happen between the juju refresh command and the time after running the set-tls action.
  3. Migrating and not setting the TLS certificate and private key values can lead to unexpected results. Make sure they are set.

To upgrade and re-configure, do the following:

  1. Get existing configuration values and save them:
juju config istio-pilot ssl-crt
juju config istio-pilot ssl-key
  1. Refresh the istio-operators charms to the desired version:
juju refresh istio-pilot --channel $ISTIO_PILOT_CHANNEL
juju refresh istio-ingressgateway --channel $ISTIO_INGRESSGATEWAY_CHANNEL
juju status istio-pilot/<unit-number> --wait 5s # Wait for the unit to go to active and idle
  1. Pass TLS certificate and key using Juju secrets.

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