Chart stores secrets in ConfigMap rather than Secret

[jtackaberry]

Values such as DRONE_DATABASE_SECRET, DRONE_RPC_SECRET, DRONE_GITEA_CLIENT_SECRET (and similar such secrets from other providers) are stored in a ConfigMap rather than a K8s Secret.

I understand I can use extraSecretNamesForEnvFrom and pass my own pre-created secret, but of course the value proposition of the Helm chart is that it creates K8s resources for me. I use the Helm Secrets plugin that allows security passing secret values into Helm charts, and I'd prefer to use this mechanism for Drone secrets as well, rather than manually create a secret outside the chart.

Perhaps a separate envSecrets in the Helm chart, to facilitate this? Something like:

env:
  DRONE_SERVER_HOST: drone.example.com
  DRONE_SERVER_PROTO: https
  DRONE_GITEA_SERVER: https://git.examle.com
  DRONE_GITEA_CLIENT_ID: 9e145da5-692b-42a1-999b-3f09b103906c

envSecrets:
  DRONE_DATABASE_SECRET: d6a7835fd429a27e3f96fc64962f7b0c
  DRONE_RPC_SECRET: c9da1cd55e4f57c6026a0cf47d94f5b7
  DRONE_GITEA_CLIENT_SECRET: +1dV0BB024M/qkIrwPqO5J27tG7WhOCX3d3tXmqPMes=

Or, maybe the chart could be clever enough to automagically place everything matching *_SECRET into a k8s secret.

Happy to submit a PR if you'd accept it.

[shmileee]

+1, would love such implementation.

[jimsheldon]

Apologies for the delay on this.

This sounds like a great feature request, but since so much time has passed since August of 2020, I do want to investigate other options before implementing this.

I will get back to you.

[sebastiangaiser]

I've implemented that via Sealed Secrets which is added via extraSecretNamesForEnvFrom.

[jtackaberry]

Sealed Secrets is one very specific and opinionated approach. The request here is first of all to ensure secret content is stored in the appropriate K8s resource (Secret rather than ConfigMap), and then to provide a mechanism to receive secrets as direct helm chart values and leave it up to the user to manage the input, such as, in my case, using a secrets plugin for Helm.

[loeffel-io]

+1