Open blafry opened 9 months ago
I have come across the following discussion: https://github.com/nats-io/k8s/discussions/833, which solves my issue. However, the proposed solution should be considered for inclusion in the documentation.
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.
👍 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.
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 intoSecrets
.What is the proposed change?
Changing the kind of the resource from
ConfigMap
toSecret
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 theStatefulSet
by overridingvolumes
andvolumeMounts
. However, its complexity and maintenance challenges are significant compared to the mechanisms provided by the Helm chart.