Users & Access

When security is enabled (it is, on any real deployment), every request needs HTTP Basic auth, and what a user may do is defined by grants.

The model in one picture

flowchart TB
    subgraph user["user: billing-service"]
        g1["produce → invoices.*"]
        g2["consume → payments.*"]
    end
    user -->|"can produce"| t1[(invoices.eu)]
    user -->|"can produce"| t2[(invoices.us)]
    user -->|"can consume"| t3[(payments.captured)]
    user -.->|"403"| t4[(audit-log)]

A grant is an action plus a list of topic-name patterns:

Action	Allows
produce	producing to matching topics
consume	consuming from and acking matching topics
create	creating topics with matching names (the creator becomes that topic's owner)
admin	everything, including user management

Patterns are exact names or prefix wildcards: invoices.* matches invoices.eu, invoices.us, and so on.

Ownership rides on top: whoever created a topic can alter it, delete it, and manage its fan-out children; no extra grants needed. Admins can do that to any topic.

Managing users (admin only)

# create a user
curl -u $ADMIN -X POST $NARAD/v1/users \
  -H "Content-Type: application/json" \
  -d '{
    "username": "billing-service",
    "password": "a-strong-secret",
    "grants": [
      {"action": "produce", "patterns": ["invoices.*"]},
      {"action": "consume", "patterns": ["payments.*"]}
    ]
  }'

curl -u $ADMIN $NARAD/v1/users                       # list
curl -u $ADMIN $NARAD/v1/users/billing-service        # inspect
curl -u $ADMIN -X PUT $NARAD/v1/users/billing-service/grants \
  -d '{"grants": [{"action": "produce", "patterns": ["invoices.*", "receipts.*"]}]}'
curl -u $ADMIN -X DELETE $NARAD/v1/users/billing-service

Two rules that keep the system honest:

• No privilege escalation: you can never grant another user more than you hold yourself.
• Users can change their own password (PUT /v1/users/{name}/password with current_password); admins can reset anyone's without it.

Practical advice

• One user per service, scoped to exactly the topics it touches. produce and consume are separate on purpose: a producer that can't drain its own topic is a feature.
• Reserve admin for humans and deployment tooling.
• The root admin is seeded at cluster startup from the operator's secret; treat its credentials like any other root credential.