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.