Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow loading secrets from a separate config file #455

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

reegnz
Copy link

@reegnz reegnz commented Jun 14, 2024

Currently all config is in a kubernetes secret because some of the
config keys the helm chart renders might be secrets.

This is a problem, as a lot of people don't want to, or don't have the
option to manage secrets with helm (eg. secret management is fully
decoupled from helm deployments).

To fix this, utilize go viper's solution that allows deep-merging
multiple config file contents. This allows for splitting out the
potentially sensitive keys into a separate config file, and then having
viper merge them back together.

The helm chart was modified so it retains backward compatibility with
the existingTargetConfig config option. If that key exists then it
is assumed that it is a kubernetes secret (as before), and the
separation of config values and secrets is not performed by the chart.

This PR should be able fixes #454

Currently all config is in a kubernetes secret because some of the
config keys the helm chart renders might be secrets.

This is a problem, as a lot of people don't want to, or don't have the
option to manage secrets with helm (eg. secret management is fully
decoupled from helm deployments).

To fix this, utilize go viper's solution that allows deep-merging
multiple config file contents. This allows for splitting out the
potentially sensitive keys into a separate config file, and then having
viper merge them back together.

The helm chart was modified so it retains backward compatibility with
the `existingTargetConfig` config option. If that key exists then it
is assumed that it is a kubernetes secret (as before), and the
separation of config values and secrets is not performed by the chart.

This PR should be able fixes kyverno#454

Signed-off-by: Zoltán Reegn <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow for not rendering a Kubernetes Secret
1 participant