Leveraging RKE2 with TLS Passthrough

What did I do?

As a new engineer at Rancher Federal (Suse Rancher Government Solutions) I wanted to setup Keycloak with TLS Passthrough on my shinny new RKE2 cluster. For the uninitiated TLS Passthrough is a way for the ingress or proxy to all TLS to passthrough. Meaning the pod itself will terminate TLS and not the ingress/proxy. RKE2 is fantastic that it ships with Nginx Ingress. There are a few other options out there on the market for ingress. Another favorite is Traeifk. But for this cluster I wanted to use the built in pieces. Nginx it is!

Why do I need it?

This is important if you want to support multiple tenants and don’t have access to Let’s Encrypt. There are several other use cases for using segregated Certificate Authorities (CA). Think logical separation of certificate domains. I know, geeky stuff. 

Fun fact, Nginx Ingress does not come configured with TLS Passthrough enabled by default. This is true everywhere. So we will need to enable it. Nginx has some ok docs on this. Basically --enable-ssl-passthrough: true needs to be added the command line for starting nginx. Let’s set up a cluster and update Nginx with Helm.

RKE2 for the win!

Setup the Cluster

For setting up RKE2 let’s look at the documentation. For simplicity, I like following the Tarball method, aka curl|bash. The instructions should be straight forward. The gist is to set up the server first and then add the other nodes. If you want the easy button there is a script for everything at the end of the post.

Updating Nginx Helm – HelmChartConfig

One cool feature of RKE2 is that it monitors a directory on the server to automatically deploy/update helm charts. We can easily take advantage of this for update Nginx to allow TLS Passthrough. From the documentation we can add a chart to /var/lib/rancher/rke2/server/manifests on the server. This will then automatically update. Below is the exact chart we used to automatically update Nginx to enable TLS Passthrough. Specifically the line enable-ssl-passthrough: true.

  apiVersion: helm.cattle.io/v1
  kind: HelmChartConfig
  metadata:
    name: rke2-ingress-nginx
    namespace: kube-system
  spec:
    valuesContent: |-
      controller:
        config:
          use-forwarded-headers: true
        extraArgs:
          enable-ssl-passthrough: true

Fairly simple right?

Update Ingress Annotations

Once enable-ssl-passthrough is enabled we will need to update the Ingress object. Take a quick look at the formal Nginx documentation. We need to add nginx.ingress.kubernetes.io/ssl-passthrough: "true" to the annotation section to tell Nginx to pass the traffic to the pod.

Here is an example.

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    name: keycloak
    namespace: keycloak
  spec:
    rules:
    - host: keycloak.dockr.life
      http:
        paths:
        - backend:
            service:
              name: keycloak
              port:
                number: 8443
          path: /
          pathType: Prefix

Profit!

Automate Things

What if we wanted to take things a step further? How can we automate all this? Let’s not get into a battle over which automation tool is better, bash of course. Take a look a repo/script I use to build clusters. github.com/clemenko/k3s. Specifically on line 187 there is an ssh –> echo command that will write out the help chart to the correct directory.

And for fun here is a snippet for deploying keycloak.

  # deploy
  kubectl apply -f https://raw.githubusercontent.com/clemenko/k8s_yaml/master/keycloak.yml

  # add ingress
  kubectl apply -f https://raw.githubusercontent.com/clemenko/k8s_yaml/master/keycloak_nginx.yml

Need Help?

Please feel free to reach out to me at:

• email: andy.clemenko@rancherfederal.com
• GitHub: @clemenko
• twitter: @clemenko

“This publication was prepared or accomplished by the author in a personal capacity. All opinions expressed by the author of this publication are solely their current opinions and do not reflect the opinions of Rancher Federal, Inc., respective parent companies, or affiliates with which the author is affiliated. The author's opinions are based upon information they consider reliable, but neither Rancher Federal, Inc., nor its affiliates, nor the companies with which the author is affiliated, warrant its completeness or accuracy, and it should not be relied upon as such.”