Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
feat: refactor kubernetes helm chart #4480
base: master
Are you sure you want to change the base?
feat: refactor kubernetes helm chart #4480
Changes from all commits
57c2807
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it better to leave
INVIDIOUS_CONFIG
as a configmap, with secrets being templated in as needed? Having a separatesecrets.yaml
would also sensitive info to actually be encrypted (K8s Secret resources aren't actually encrypted by default), for example by using thehelm-secrets
plugin, without making changes toINVIDIOUS_CONFIG
needlessly difficult.For example:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do agree on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I wanted to do the same but I lack the idea how to do this properly. It would be easier if config options would be a separate env vars, but this is one env var and we are unable to concatenate it in helm chart before pushing it to the pod/container.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also the solution here allows the usage of helm-secret without any difficulty - it's an object, not a string in the values, so you can split the secret parts to other values file and encrypt it with helm-secrets using SOPS or provide it externally using vals.
Exactly the same solution as you proposed with snippets will work now without any changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Secret
s aren't encrypted by default, butConfigMap
s cannot be encrypted at all.If we have an idea how we can split part of config to go to
ConfigMap
andSecret
we can then roll it back toConfigMap
and selectively move parts of config values toSecret
. If we have no idea how to do this, I'd personally prefer to have wholeINVIDIOUS_CONFIG
env var in theSecret
due to sensitive values inside.Encryption of values being input to helm chart doesn't change anything here, as those values will be stored unencrypted in etcd even when someone enabled
Secret
encryption in the cluster due to being just aConfigMap
. Also it will be able to be accessed by applications running in the cluster withConfigMap
access, but withoutSecret
access.