Feature: Externalize secrets

[ridoo]

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.

[mwallschlaeger]

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.

[ridoo]

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: {{ [email protected] | 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:

1. Use the 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)
2. Maintain a custom secret (which is not versioned), separated from config version control. This can be created either by hand or by other tools like 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.

[ridoo]

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.

[ridoo]

@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.

[ridoo]

@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.