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