nats-io/nats-operator

How to configure accounts

rgarrigue opened this issue · 4 comments

Hi there

Simply put, I want to configure

leafnodes {
    port: 12345
}

accounts: {
  AUAREANKEY: {
    users: [
      {
        user: UAREANKEY
      }
    ]
  }
}
authorization: {
  users: [
    { 
      nkey: UAREANKEY
    }
  ]
}
no_auth_user: UAREANKEY

I searched a bit in the code, I guess there's no "no_auth_user" and "accounts" possible with the operator ? Is there another way to inject that ? Or should I try to nuke the nats-server secret to replace it with a homemade one ?

I can't comment on the operator side of things, but this is not a valid configuration and will be rejected in the up-coming release. Having the same user in authorization{} and accounts{} will return an error saying that the user has to be unique. When using accounts{}, you should not have any user defined in authorization{} (you can fully configure users' permissions directly in the definition of the user in the accounts{} block).

There does not seem to be a way to define accounts and leafnodes that way in the operator right now. Closest that you can do is to include an auth secret but this would only work with the authorization block it seems:

auth:
# Needs to be under /etc/nats-config where nats looks
# for its config file, or it won't be able to be included
# by /etc/nats-config/gnatsd.conf
clientsAuthFile: "authconfig/auth.json"
template:
spec:
initContainers:
- name: secret-getter
image: "busybox"
command: ["sh", "-c", "echo 'users = [ { user: 'foo', pass: 'bar' } ]' > /etc/nats-config/authconfig/auth.json"]

I would try to migrate from the operator to a helm charts based one using the extraRoutes functionality to mesh the two clusters: https://github.com/nats-io/nats-operator/blob/71318679585df15a9b734586798f759d636e2ee0/README.md#connecting-operated-nats-clusters-to-external-nats-clusters

We're migrating out of this kubernetes cluster, so I don't want to spend a couple of days more trying to hop on another helm provisioned cluster, tried that quickly without success. Injecting the parameter with a init container is perfectly fine for me. I'll try that

Conclusion, we postponed enabling auth to after migrating out of the operator due to the above issue. Having a "wildcard" for additional configuration would be really handy.