Open praveenperera opened 5 months ago
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>
@hhk7734 with this the username and password would still be exposed because the account.yaml would also be in git
Do you use an external secret like a vault?
Using AWS secrets manager with external-secrets operator.
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.
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: https://github.com/nats-io/nack/issues/76#issuecomment-1995808911
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