Closed ridoo closed 10 months ago
I agree on storing sensitive data in secrets makes sense. But I don't understand why you want to deploy them separately. In my opinion this makes the deployment more complex.
Could we keep the definition inside the values.yaml but store them in kubernetes secrets? Generally securing sensitive data in the values.yaml must be part of the CI tool, like argocd or flux. Those tools provide mechanisms to secure secrets in values.yaml like sops or vault.
Apart from the passwords you mentioned there are more which should be added to kube-secrets like: geonode.mail.password
, geonode.ldap.bind_password
, rabbitmq.auth.password, rabbitmq.auth.erlangCookie
.
I think most helm deployments handle this the same way as we do in geonode-k8s, therefore users must take care of the passwords themself. I suggest sops here.
In general, we want to avoid outsourcing secrets when not necessary. Having an in-house CD pipeline is not the standard case IMO. Our current use case is, to version the deployment specific values.yaml
but without the sensitive data in it. Sensitive data, e.g. credentials, are stored in a password safe separately.
Could we keep the definition inside the values.yaml but store them in kubernetes secrets?
We can configure the Secret contents in the values.yaml
:
global:
secrets:
# -- the name of the secret to use
name: demo-secret
# -- The default secret
content: |
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
type: Opaque
data:
# superuser
ADMIN_USERNAME: {{ admin | base64 }}
ADMIN_PASSWORD: {{ geonode | base64 }}
ADMIN_EMAIL: {{ support@example.com | base64 }}
I put it in a dedicated section for now. We can discuss, if we want one Secret for all, or provide one for each deployment.
The values in the Secret's content can be set by the CD pipeline (or the like). Still, I would be able to change the Secret's name to use a different Secret.
We should document both options accordingly:
secrets
section if you want to keep sensitive data in the values.yaml
(recommend to set them as masked values in a CD setup, or not to version the values.yaml
)kustomize
, then.SOPS look interesting but requires to throw more tools on the problem. I also had a look at Helm plugins which handle encrypting secrets. However, this makes the toolchain more complicated in IMO, but still we out-source (now encrypted) secrets.
I have updated the PR #71 but did not added missing credentials so far (geonode.mail.password
, geonode.ldap.bind_password
, rabbitmq.auth.password
, rabbitmq.auth.erlangCookie
). Please have a first look.
@mwallschlaeger I marked the PR as Draft for now.
However, I revised the status and found some bugs which (I hope) could fix in the last commit. However, I have to update the minikube values to match the changes in the values.yaml
and check the external database config still.
@mwallschlaeger minikube values are in line with values.yaml
. I also had a look at the external database config and fixed the username_email
default setting in the values.yaml
.
Feature Description
Currently, I have to configure confidential values in the 'values.yaml'. So this is also true for local values.yaml file for which I want to version configuration settings but not the secret ones.
Proposed Solution
Provide a secret sample including demo setting (from the current values.yaml) and make the name configurable. Then, we can reference to secrets in the env section of each deployment.
In case of overriding, one would have to create a custom secret file within a dedicated configure and configure that secret name. The secret can be safely ignored by version management while all other configuration can be put under version control.