dadrus
Support vanilla cert-manager provided tls secrets (separate pem files for cert and key).
Preflight checklist
- [x] I agree to follow this project's Code of Conduct.
- [x] I have read and am following this repository's Contribution Guidelines."
- [x] I have discussed this feature request with the community.
Describe the background of your feature request
Heimdall currently expects a single file containing both, the certificate and secret key for tls on it's endpoints (ingress, management and webhook). This unfortunately makes it unergonomic to use with the most prevalent certificate-solution in the kubernetes-ecosystem: cert-manager. There are work-arounds - see below - but it would make the entire experience of using heimdall on k8s more accessible and encourage people to actually use tls instead of opting for --insecure.
Describe your idea
The implementation would probably require adding appropriate fields to the TLS type and then appropriate handling when setting up the listeners. Example:
tls:
certificate: /etc/secrets/heimdall-cert/tls.crt
key: /etc/secrets/heimdall-cert/tls.key
certificate and key should probably be mutually exclusive with key_store and key_id.
Are there any workarounds or alternatives?
Workaround 1: Use cert-manager's additionalOutputFormats
You can explicitly instruct cert-manager to also create a combined pem file with a feature that is currently in beta.
Documentation: https://cert-manager.io/docs/usage/certificate/#additional-certificate-output-formats
Warning: This features is in beta (enabled by default) since cert-manager 1.15, in earlier versions, you would need to enable the corresponding feature gate.
Workaround 2:
If you are stuck with an older version of cert-manager and can't enable the above mentioned feature, your best option is probably to have add an init container that combines the tls.crt and tls.key into one pem file as part of your heimdall deployment.
Version
heimdall version v0.17.3
Additional Context
Given that cert-managers additionalOutputFormats already made it to beta, it might be a worthy consideration to just add appropriate hints to the documentation instead of implementing support for split cert/key.
Hi @NiklasBeierl. Please excuse me for the very belated answer. I personally vote for extending the documentation and make this information more prominent. At least for now. There is also #1036, which will be addressed for the upcoming v0.18.0 release. Despite the name of this FR, the idea is to come up with a pluggable approach and allow loading of secrets from different places, like k8s secrets, external secret management systems, etc. This would make the part you're referring to much simpler to configure as well.
Related to my comment above. You can find the related ideas here in Discord. Unfortunately there were no much related discussions and I'm still looking for an approach (from the configuration point of view), which would be easy to use and also future proof. With other words, I really appreciate your thoughts on that topic :).