Helm for Kubernetes. Setup ingress with HTTPS.
The current chapter is the continuation of Helm exploration journey started with previous ones:
The input for the current chapter is here. The project has two Helm charts (RabbitMQ is maintained by Bitnami and hand crafted chart with naive REST API server communicating with RabbitMQ). The recent improvement was to introduce Ingress as API gateway for both charts to be accessible from outside Kubernetes. Current step is to upgrade Ingress to use HTTPS for local deployment in minikube.
Since it is a local development and HTTPS, the need for self-signed certificate is strong. mkcert to the rescue. This utility allows custom certificates generation and produces Certificate Authority (CA) which can be trusted on local computer. Thus, in the scope of the local computer only, it becomes possible to fully test HTTPS access to services located inside Kubernetes.
#1: installs local CA as trusted to local store.
#2: generates custom certificates key pair valid to localhost and any subdomain of localdev.me. Here, the approach to use this domain for local development (see my another article) is used, so any subdomain.localdev.me will be resolved to 127.0.0.1 where minikube’s Ingress expects incoming connection.
After both commands are executed, the current folder has two new keys files (strange name, like _wildcard.localdev.me+2.pem in my case) with the public and private keys. These keys are first-class citizens on local computer due to mkcert’s CA registration.
The custom certificate will be used in couple of places inside Kubernetes. The certificate needs to be wrapped as Kubernetes secrets of special type kubernetes.io/tls. Due to sensitive nature of the certificate, the plan is to reuse SOPS encryption for this certificate also (refer to my early secrets and SOPS-related article).
And, it also means, it is time for a new tiny hand crafted Helm chart. The chart itself will be rather simple as its only purpose is to create Kubernetes secrets with certificate in it.
Given the fact, file name is keys.yaml and locally installed PGP key fingerprint is 88D3C0D03895A07DB04A393FE6C332F04B58CA6A, the file data can be encrypted with:
and looks like this:
Create new chart folder tlscert with the following Helm chart folder structure (github link):
The most interesting file is templates/secret.yaml
It has a structure of plain Kubernetes secret, watered with Go substitution injections:
#2: get key-value pairs from temporary decrypted certificate keys (refer to my SOPS manipulation article for details).
#7: concrete secret name is taken from values.yaml file.
#11…13: inject bare secrets as data.
To preview what Helm deploys in Kubernetes, helm template …. command can be used:
And above secret can be deployed to Kubernetes with:
Thus, the certificate keys are now inside Kubernetes secret named
my-domain-certificate in namespace medium.
The next section is minikube plugin specific. There is a configuration extra step for TLS Ingress connection there. The very same keys needs to be linked with Ingress plugin:
#1...2: reference certificate from secret in plugin.
#4…5: restart plugin to refresh active configuration.
Time to upgrade RabbitMQ Helm chart to start using HTTPS. Since Bitnami’s chart is used and all files are kept in local git-repo, locate ingress in a list of all variables chart has and read through section params. New edition of my-values.yaml with overridden chart values:
#7: subdomain rabbitmq will be used to access RabbitMQ administrative console
#8…10: access with HTTPS enabled and certificate incorporated in secret is used to access it.
The needed part is to deploy this chart:
Ingress now has TLS specified and 443 listed:
And HTTPS access through browser now is on(do not forget minikube tunnel to allow access through localhost to Ingress):
In certificate details, the mention of mkcert can be found:
The upgrade in the second Helm chart is matter of upgrading Kubernetes Ingress YAML file to use TLS according to the official documentation.
#6: forcing redirect to HTTPS.
#8…12: telling that HTTPS certificate is in the same secret (variable file is below) and host value as expected.
Similar deployment procedure:
And the same HTTPS enabled results for my handcrafted test server:
Secure access in the browser:
And the same certificate and issuer details:
Although local development (rather, troubleshooting) exactly with HTTPS is not so frequent case, when it is unavoidable, it becomes tricky to do. Still, all that preparations (how to create self-signed certificate, how to set Ingress details and make a friendship between the certificate and minikube), most likely push the developer toward doing HTTPS exercises somewhere in the cloud. Still, good to know that local procedure is also available.
