[Jetstream Controller] Use secrets for username/password authentication

[praveenperera]

What motivated this proposal?

I'm using username and password authentication and would like to use the controller. I'm using ArgoCD so all my yamls are in my git repos.

What is the proposed change?

One way I think is allowing the controller to interpolate env variables: nats-io/nack#76 (comment)

And then change the deployment.yaml file to accept extraSecretMounts. I could do the PR for this.

Who benefits from this change?

Anyone using username/password authentication, gitops and wants to use the jetstream controller.

With gitops practices all the helm/yaml files are stored in git, so without this you would be exposing your creds.

What alternatives have you evaluated?

No response

[hhk7734]

This is an example using account.

apiVersion: jetstream.nats.io/v1beta2
kind: Account
spec:
  name: <accountName>
  servers:
  - nats://<user>:<password>@<host>:<port>

apiVersion: jetstream.nats.io/v1beta2
kind: Stream
spec:
  account: <accountName>

[praveenperera]

@hhk7734 with this the username and password would still be exposed because the account.yaml would also be in git

[hhk7734]

Do you use an external secret like a vault?

[praveenperera]

Using AWS secrets manager with external-secrets operator.

[akhenakh]

Bump because this form can not be used with a secret manager since there is no way to tell it to fetch from a secret in the Kubernetes secret API or via CSI Kubernetes secrets.

[vavsab]

@samuelattwood @wallyqs @caleblloyd @Jarema @bruth
Are you ok with the idea of env vars interpolation like described here?
nats-io/nack#76 (comment)

I'm ready to contribute. It's blocking my company from adopting NATS.

[pbennett]

Not sure if it helps, but at least w/ GKE you can also now mount secrets from the secret manager into locally mounted files:
https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component