Learn NATS - Accounts & Multi-Tenancy

#Introduction

All the examples so far use a single default account. Episode 12 opens up the world of multi-tenancy: separating services, teams, and environments into accounts so a single NATS server can safely serve many isolated tenants.

We'll cover the concept of accounts, users and permissions, then the nsc tooling that manages everything via JWT. This is the security foundation that will continue in episode 13.

#The Account Concept

#Logical Isolation Between Services

An account is the isolation unit in NATS: subjects, streams, consumers, and permissions within one account can't be seen by another account without explicit permission. Think of accounts as separate namespaces on the same server.

account PAYMENTS   -> subject payments.>, stream PAY_ORDERS
account ORDERS     -> subject orders.>, stream ORDERS
account ADMINS     -> subject admin.>, full access

The account PAYMENTS structure shows each account has its own world. Two accounts may use the same subject names — for example orders.created — without interfering with each other.

#When to Create Accounts

Some common patterns:

• One account per team or department.
• One account per service for strict isolation.
• A dedicated admin account for monitoring.

nats account info

nats account info shows the account currently in use along with its JetStream quotas. With accounts, stream and resource quotas can be allocated fairly per account.

#Users and Permissions

#Users Within an Account

Each account contains one or more users. Each user has its own identity and permissions:

nats add user --account ORDERS --name api-worker

The nats add user --account ORDERS --name api-worker command (in an nsc environment) creates an api-worker user in the ORDERS account. Permissions determine what that user is allowed to do.

#Subscribe, Publish, and Response Permissions

NATS distinguishes three permission types:

• Subscribe: subjects that may be listened to.
• Publish: subjects that may be published to.
• Response: reply subjects that may be used for request-reply.

authorization {
  users = [
    { user: worker, permissions: {
      subscribe: { allow: ["jobs.>"] }
      publish: { allow: ["jobs.done"] }
      response: { allow: ["_INBOX.>"] }
    }}
  ]
}

The permissions block above gives the worker user the right to subscribe to all jobs subjects, publish only to jobs.done, and answer any request. This response model is what keeps request-reply safe.

#nsc and JWT

#What Is nsc

nsc (NATS Tooling) is the toolkit for managing JWT-based operators, accounts, and users. JWTs aren't stored in the server configuration file — each client carries its own credentials.

nsc add operator --generate-signing-key
nsc add account ORDERS
nsc add user --account ORDERS api-worker
nsc generate creds --account ORDERS --user api-worker

The nsc add account ORDERS sequence creates an account, nsc add user creates a user, and nsc generate creds generates a .creds credential file for clients to use. This flow is far more secure than distributing plaintext passwords.

#JWT and the Decentralized System

JWT moves trust from the server to cryptographic signatures:

nats-server --js --auth config.json

With JWT, the server doesn't need to store a user list. Clients present an operator-signed token, and the server verifies its signature. This lets accounts and users be created and revoked without restarting the server.

#Exporting and Importing Subjects

#Sharing Subjects Between Accounts

For cross-account communication, use export and import:

exports: [
  { stream: { subject: "orders.created" } }
]

The exports block in the ORDERS account allows the orders.created subject to be shared. Another account then imports it:

imports: [
  { stream: { subject: "orders.created" }, to: "orders.imported" }
]

The imports block accepts that subject and maps it to orders.imported in the receiving account. This export-import mechanism enables a clean multi-account architecture — each account chooses what it publishes and what it consumes.

#Conclusion

Episode 12 introduced NATS multi-tenancy: accounts as the unit of logical isolation between teams and services, users with subscribe, publish, and response permissions, the nsc tooling managing everything via JWT, and subject export-import for controlled cross-account communication.

Key takeaways:

• Accounts isolate subjects, streams, and permissions between tenants.
• Each account can have many users with different permissions.
• Permissions are split into subscribe, publish, and response.
• nsc creates JWT-based operators, accounts, and users.
• JWT moves authentication to cryptographic signatures.
• Subject export and import connect accounts with full control.

In episode 13 next, we'll discuss security & authentication — user and password authentication, tokens, nkeys with public-private key pairs, and JWT, followed by TLS for connection encryption and per-user authorization, complete with production best practices. NATS security starts being tested on real ground.