Allow option to expose mounted certs as secret

[c-p-b]

What would you like to be added

The ability to either have autocert create a secret in the namespace with the cert credentials (similar to what step-issuer does) or to write out to the volume mount a kubernetes secret containing cert file contents instead of the crt files themselves.

Why this is needed

In some cases it's nice to be able to have certs available as a secret in addition to or instead of three flat files made available via a volume mount. One use case I ran into is when I was bootstrapping timescaledb-kubernetes. In this helm chart, you can only specify certs as environment variables (secrets.certificate) or as an existing secret (secrets.certificateSecretName) when bootstrapping: https://github.com/timescale/timescaledb-kubernetes/blob/master/charts/timescaledb-single/admin-guide.md

There are some alternative solutions I could explore to continue to use volume mounted certs in this case - but none of them were particularly great as far as I could tell. Some variations to solve my problem that I explored include:

• add some configmap with some bash script that would pull the file contents into environment variables to be used by the helm chart
• modify the timescaledb-kubernetes helm chart to also take volume mount as input to read the cert contents
• install some other automation to pull the info out into an existing secret

I might have gone down one of those routes if autocert wrote out the contents of the cert files as a kubernetes secret for me. There is a well documented path to using secrets in your app that are in the pod filesystem provided they are written out in the kubernetes secret format.

In the end for my use case I just manually created a secret with the certs for this use-case using cert-manager, step-issuer, step-certificates and referenced that secret in the timescaledb-kubernetes helm chart values. It would be nice to not have to have that workflow, however, and be able to use autocert to manage that.

[maraino]

Hi @cpdeethree, the current version of autocert is not designed to write data to secrets, for that we will require to convert autocert into a different tool, basically a k8s controller/operator, very similar to cert-manager + step-issuer. The current implementation runs as a sidecar container and obtains and renews the certificate in a fixed path.

I would love to add autocert that functionality, almost deprecating step-issuer, but right now we don't have any plans to support it.