[nats helm chart] Changing the configuration resource from ConfigMap to Secret due to sensitive authorization data.

[blafry]

What motivated this proposal?

I'm using the nats helm chart to deploy a cluster.

I configured authorization and realized that I'm forced to use passwords in plain text because using bcrypt-encrypted passwords is not possible due to the configuration of URLs in routes.

Storing sensitive data in ConfigMap is problematic because, in my case, on production environments, we keep the resource definitions in YAML on Git.

In the case where the configuration is in a Secret, this problem does not occur because we use the Sealed Secrets operator. This allows store encrypted Custom Resources (CR) on Git and be applied on the cluster, where they are decrypted and converted into Secrets.

What is the proposed change?

Changing the kind of the resource from ConfigMap to Secret for storing configuration.

Who benefits from this change?

Sensitive data, such as authentication details like passwords, will be stored according to best practices for all users of the Helm chart.

What alternatives have you evaluated?

Considering the possibility, I contemplated creating a custom Secret resource with prepared configuration and mounting it in the StatefulSet by overriding volumes and volumeMounts. However, its complexity and maintenance challenges are significant compared to the mechanisms provided by the Helm chart.

[blafry]

I have come across the following discussion: #833, which solves my issue. However, the proposed solution should be considered for inclusion in the documentation.

[dwooldridge-ctoken]

Hi, I have exactly the same issue. I cannot use this chart unless there is a way to load the authentication/accounts sections of my configs securely. I have tried using $include but that mounts files relative to /etc/nats-config, and I cannot see a way to mount a custom secret in to the pods.

[jabbrwcky]

👍
I am also facing issues with building proper configuration (There are several issues in this topic).

If you are fine with working around te automatic values built into config, you can mount extra secrets by patching the stateful set:

  statefulSet:
    name: "nats-test-cluster"
    patch:
      - op: replace
        path: /spec/template/spec/volumes/0
        value:
          name: config
          secret:
            secretName: nats-configuration
            defaultMode: 420
       # Mount secret as includes     
      - op: add
        path: /spec/template/spec/volumes/0
        value:
          name: nats-config-includes
          secret:
            secretName: nats-includes-file
      - op: add
        path: /spec/template/spec/containers/0/volumeMounts/0
        value:
          name: nats-config-includes
          mountPath: /etc/nats-config/includes/

For mounting includes you need to provide a subfolder of /etc/nats-config/ as base, so it does not conflict with the mounted main configuration.

Caveat: Even while being able to mount files and referencing them as includes, they do not work as documented in the NATS configuration because $include apparently does not work with the generated JSON configuration format.