cncf / clowarden

CLOWarden is a tool that manages access to resources across multiple services
https://clowarden.io
Apache License 2.0
39 stars 5 forks source link

Support seeding secrets from non-plaintext sources (consider using External Secrets Operator) #216

Open justaugustus opened 1 week ago

justaugustus commented 1 week ago

Highlighted by @mshoosht-cisco, there are several areas within the chart templates which may suggest the use/committing of plaintext credentials e.g., https://github.com/cncf/clowarden/blob/c966d3b4515b076c2158c314af696feda93d4faa/charts/clowarden/templates/server_secret.yaml#L22

It would be great to consider extending the chart to use External Secrets Operator, specifically ExternalSecret: https://external-secrets.io/latest/api/externalsecret/

Matt can say more, but I'm filing this to get the convo started!

cc: @lelia @sriaradhyula

mshoosht-cisco commented 6 days ago

A good initial start is to allow the secrets to be optional. This would support the chart being installed, but the secrets to be created by other means. ES Operator is one method, but manual, or CD could be another.

Here is an example that illustrates the use of a value in values file. The value can be defaulted to true to maintain current behavior(secret always created), but overridden to not create the secret if another tool is to be used. I have the complete solution. I can PR if there is interest.

{{ if .Values.dbmigrator.createSecret }}

In regard to the external secret controller, you could use a flag to use that. Supporting multiple secret generation processes may be cumbersome. Users of this chart could extend by calling this chart as a dependency and then having a template folder with the Helm external secret resources.

tegioz commented 6 days ago

Hi! 👋

@justaugustus it's possible to use the chart as it is without using / committing plaintext credentials 😇 (i.e. using helm-secrets). Another option is to have the chart's custom values layered into multiple files, and store the credentials in one that'd remain encrypted until needed (i.e. to rotate keys).

But I understand that this may not work for some teams, so having some flexibility is great. Making the secrets optional -keeping the current default behavior- sounds good @mshoosht-cisco, and we'd gladly accept a PR for this 🙂 We'd like to keep it as simple as possible, so we'd rather not to include support for any specific secrets generation process at the moment. That can always be handled separately as you mentioned.

I will also update the CLOWarden server to allow configuration values to be set/overridden using environment variables in addition to be read from the config file (maybe it'll help eventually with further improvements to the chart).

Thanks!