Enable HTTPS

charm
, ,
1

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.

Requirements

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:

Set up a domain name

Obtain a TLS certificate

Pass 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>

Configure 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)"

Migrate from configuration to action

These instructions should only run if migrating from istio-operators < 1.17 rev1197

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.
2 Likes
2

Hi,

I tried to follow the article, but it didn’t work for me. I am using a self-signed certificate with a local CA.

juju add-secret istio-tls-secret tls-crt="$(cat server.crt)" tls-key=$"$(cat server.key)"
juju grant-secret istio-tls-secret istio-pilot
juju config istio-pilot tls-secret-id=secret:ct10u2ojpp........
juju config oidc-gatekeeper ca-bundle="$(cat rootCA.crt)"
juju refresh istio-pilot

But when I executed the refresh, nothing happened I got only : charm “istio-pilot”: already up-to-date

I waited sometime, I executed “kubectl get pods -n kubeflow | grep istio” to see if the pods got restarted/redeployed, but nothing.

When I execute this command I got

 juju config istio-pilot ssl-crt
{}
ERROR key "ssl-crt" not found in "istio-pilot" application config or charm settings.

I tried to connect with https, the browser does show the warning of the self signed certificate, I got the dex authentication page, but after authenticating I got a blank page, I tried to refresh but not success, and now I am stuck, no https and no http, both are not working…

Did I miss something?

Regards.

3

The refresh command should only be run if you have istio-operators < 1.17 revision 1197. I have added a note so it is clear. Refreshing the charm should not affect your deployment, though, and if you already have the latest version of the istio-operators, the HTTPS functionality should be available already.

About the command juju config istio-pilot ssl-crt, since the istio-pilot does not have that configuration option at all, this is accurate and you are not expected to get anything from it. To check all the configuration options for this charm, you could run juju config istio-pilot.

Now, the way to check if the Gateway is correctly configured with HTTPS, you can run:

$ kubectl get gateway <gateway name> -oyaml
# In the output you should see these bits in the output:
...
    port:
      name: https
      number: {{ port }}
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: {{ gateway_name }}-gateway-secret
...

You can double down by checking the secret kubectl get secret {{ gateway_name }}-gateway-secret -oyaml and checking the values of tls.crt and tls.key match yours.

Now, we’ll need more information about the issue. Are you trying to reach the dashboard? Did you check the Ingress Gateway was up? If you could share more context on what the steps to reproduce are, it’ll be easier to debug this (: