-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Conversation
labels: | ||
{{- include "invidious.labels" . | nindent 4 }} | ||
stringData: | ||
INVIDIOUS_CONFIG: | |
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 separate secrets.yaml
would also sensitive info to actually be encrypted (K8s Secret resources aren't actually encrypted by default), for example by using the helm-secrets
plugin, without making changes to INVIDIOUS_CONFIG
needlessly difficult.
For example:
# secrets.yaml
postgresql:
auth:
username: kemal
password: kemal
primary:
initdb:
username: kemal
password: kemal
config:
db:
user: kemal
password: kemal
hmac_key: hmac_key
# values.yaml
postgresql:
enabled: true
image:
tag: 16
auth:
# username: SECRET
# password: SECRET
database: invidious
primary:
initdb:
# username: SECRET
# password: SECRET
scriptsConfigMap: invidious-postgresql-init
config:
db:
# user: kemal
# password: kemal
host: invidious-postgresql
port: 5432
dbname: invidious
# hmac_key: SECRET
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, but ConfigMap
s cannot be encrypted at all.
If we have an idea how we can split part of config to go to ConfigMap
and Secret
we can then roll it back to ConfigMap
and selectively move parts of config values to Secret
. If we have no idea how to do this, I'd personally prefer to have whole INVIDIOUS_CONFIG
env var in the Secret
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 a ConfigMap
. Also it will be able to be accessed by applications running in the cluster with ConfigMap
access, but without Secret
access.
Hello @unixfox, are you still there? ;) |
hello @JuniorJPDJ, Very sorry for the lack of replies lately! I really lack of free time. I made a big decision, I have moved the helm chart to a new dedicated repository: https://github.com/iv-org/invidious-helm-chart I have invited you as a maintainer of the repository. I think you will do great in order to keep this helm chart active if you agree. We now even have a dedicated helm repository for the helm chart located at http://charts-helm.invidious.io/. Feel free to continue creating pull requests on that repository. The code there is the one from your GitHub repository, so consider this pull request "merged". If anybody else wants to be added as a maintainer of that repository, feel free to ask me. Thank you. I'll close this pull request. |
Thanks! That's nice! I accepted the invite and will try to help with things a bit in my free time. |
ConfigMap
->Secret
(we are holding passwords andhmac_key
here)Ingress
supportinvidious
instead ofinvidious-invidious
if helm release is calledinvidious
pg_isready
use (wait_for_postgres
initContainer)envFrom
instead ofenv
with config (simpler syntax)securityPolicy
(andpodSecurityPolicy
separatly)tolerations
,affinity
andnodeSelector
support