Move user configuration to a secret

[madestreel]

Hey,

Thanks for adding the user provisioning through a configuration file! The only issue here is that passwords need to be in plain text in our configuration file (we could also auto generate them in a template file but this would change their value at each apply) our we need to save them to a secret, read from it and write that value to the configuration. This is not very practical...

Furthermore, I think passwords should be in secrets anyway...

Would it be possible to change this so that the user configuration would be fetched from a custom / pre-defined secret instead of being part of the default configuration ConfigMap.

I suppose this would require some changes on the server side to be able to read the configuration from another directory since it is not possible to mount two ConfigMap / Secret at the same place.

and I would then have a volume that would be mounted like this

volumes:
    - name: initial-user-configuration
      secret:
        secretName: {{ .Values.auth.existingSecret }}

And in the container definition

volumeMounts:
  - name: initial-user-configuration
    readOnly: true
    mountPath: "/etc/nats-config/conf.d/user-configuration"

Finally, in the memphis.conf I would include everything that is in /etc/nats-config/conf.d/**/*.conf and on the memphis server read the user configuration directly from the main configuration file.

That way configuration is make more dynamic and gives the possibility to user to mount extra configuration volumes to /etc/nats-config/conf.d like they which.

Of course this is just a proposition, if you prefer this can also be a ConfigMap.

[valeraBr]

Hi @madestreel,
Thanks for the proposal, your input is really valuable.
We are aware of this issue and we are working on a more complex solution.

[madestreel]

@valeraBr Ok then closing this issue. Because now it is not really usable :/ Or do I keep it open?

[madestreel]

Any news for this one? :)

[valeraBr]

Hi @madestreel ,

We are planning to publish a refactored version of it in the following releases. Every contribution and idea sharing is more than welcome.

[madestreel]

@valeraBr My proposition is in the description of this Issue ;)

I can of course contribute but I would need to know which solution you prefer