Helm for Kubernetes. Setup ingress with HTTPS.

The current chapter is the continuation of Helm exploration journey started with previous ones:

#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.

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:

The most interesting file is templates/secret.yaml

#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.

#1...2: reference certificate from secret in plugin.

#4…5: restart plugin to refresh active configuration.

#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:

#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.

Related posts:

It is a world where metaverse is attracting But there is still a question. What’s the difference between metaverse and traditional games? Why don’t you call everything metaverse? metaverse has the…

Because as long as we believe something is wrong with us, we can spend all our time fixing that thing that is wrong instead of getting out there and living our real, vulnerable lives. This part would…

My private stuff is still on a floppy disk and my 6 y/o daughter has it’s custody. Trust me, she has a better privacy policy than GDPR; no sharing, no reproduction, no exchange, no AI, and no…