Issue with denying unauthenticated connections

[alexherington]

I'm trying to set up a NATS server instance which:

• uses username/password authentication from an application to publish/subscribe to any subject
• has a separate set of credentials for a system user to use with the NATS CLI tool server commands (viewing metrics, listing servers etc)
• rejects all connection attempts with no auth credentials

From reading the docs it suggests you can create a user under the $SYS account which will map to the system account, which works fine.

The issue I have is that when this system account is defined, connections with no credentials passed are still able to connect and act as a normal user and publish/subscribe, which I'm trying to avoid!

This is the test configuration I've been using:

accounts {
  "$SYS" {
    users = [
      {user: "foo", pass: "pass"}
    ]
  }
}

authorization {
  users = [
    {user: "bar", password: "pass"}
  ]
}

jetstream {}

http = "0.0.0.0:8222"
listen = "0.0.0.0:4222"

I can connect as these users as expected. I can also connect with no user/pass. If I comment out the accounts block, unauthenticated connections fail, as expected.

I'm aware of the no_auth_user option and mapping this to a user with permissions denied but this doesn't work with the Python client as it then won't send credentials because auth_required isn't present in the server info, so connections fall back to the no_auth_user. The go client seems to work fine.

I've scoured the documentation, but please could someone help me understand why defining a separate account changes this behaviour 🙏Thanks!

[wallyqs]

Hi @alexherington, could you try with nats-py v2.4.0 which I have just published? I think this should be fixed there: https://pypi.org/project/nats-py/

[alexherington]

Hi @wallyqs 👋 I can confirm upgrading from nats-py v2.2.0 to v2.4.0 fixed the issue with credentials not being used when auth_required wasn't present 🎉 Thank you for your help!

I'd still be very interested in finding out an answer to the first question though, as with this config it's still possible to connect to the cluster with no credentials and have some degree of access. But this nats-py update helps me work around it for now :)

[cascadia-sati]

I ran into the same issue and can confirm that simply having an accounts block somehow enables unauthenticated access, but we wanted to keep the system account, so removing it was not an option. We solved this by using the no_auth_user field, which is the user that gets assigned to unauthenticated connections, and then pointed it to a user that gets denied everything. Silly that we have to jump through this hoop, but there it is.

https://docs.nats.io/running-a-nats-service/configuration/securing_nats/accounts#no-auth-user

system_account: "$SYS"

no_auth_user: no_auth_user

authorization: {
  timeout: 5
  users: [
    {
      nkey: "...",
      permissions: {
        publish = ">"
        subscribe = ">"
      }
    },
    {
      user: no_auth_user, password: foobar, permissions: {
        publish: { deny: ["*"] },
        subscribe: { deny: ["*"] }
      }
    }
  ]
}
accounts: {
  "$SYS": {
    "users": [
      { nkey: "..." }
    ]
  }
}

[alexherington]

@cascadia-sati Yeah, this is the workaround I used as well but it does feel a bit hacky. no_auth_user seems like it's designed to specifically add permissions to anonymous users rather than be used to block access, as it's bypassing authentication.

[bruth]

Hey folks, the user/pass, token, or a list of users in the top-level authorization block was one of original config options (pre-multi tenancy and system account). When multi-tenancy was introduced, this block still works and defaults to an implicit $G account.

For setups that want the system account exposed and one or more application accounts, the accounts block should be used.

However if you only define the system account, the default account named $G is still in effect and does not require auth. the simplest way to address is to define a new explicit account.

accounts {
  SYS: {
    users: [
      { user: sys, password: sys }
    ]
  }
  APP: {}  # <- whatever name you want
}

system_account: SYS

When a non-system account is defined, the default $G account is no longer in effect and since APP does not define any users, no non-sys authenticated clients will work.

At that point you can add users under APP as needed for client applications and/or add additional accounts if desired.

[cascadia-sati]

Here's another question that I don't believe the documentation answers: What are a user's permissions when no permissions block is defined for the user and no defaultPermissions block is defined, either?

[bruth]

After talking with the server team, there is a correction to what I said above, we are checking whether this is a bug in that defining the accounts block appears to outright ignore any users/creds defined in authorization.

[alexherington]

Many thanks for clarifying this @bruth 🎉 That makes sense.

Although now I have an exciting issue! This config is already deployed to a production cluster. Is there a way I can migrate the existing streams/msgs to a new account?

[derekcollison]

nats account backup then nats account restore should allow you to move JetStream assets from one account to another. And I am looking into the issue mentioned above.

[alexherington]

@derekcollison Ah of course, thank you!

[derekcollison]

ok found the bug and will do a PR and should be in 2.10.2 release which is coming very soon.

[derekcollison]

#4605

[derekcollison]

Merged, will be in 2.10.2 release.