Apache Pulsar Tenant Authorization Starts With the Token Subject
Apache Pulsar is often described by its topic namespace, but the security boundary begins earlier. A client authenticates, receives a principal such as a role or token subject, and then requests access to a tenant, namespace, or topic. If an operator only reviews topic names, the same role may have rights across multiple business units without an obvious topical clue.
Authentication is not authorization
Pulsar's security overview states that a fresh deployment configures no encryption, authentication, or authorization. An authentication provider establishes identity and assigns a role token. A separate authorization provider decides whether that role may perform a produce, consume, or administrative action.
Enable authentication and authorization together. A broker that authenticates clients but runs without authorization can still expose data to any valid principal. A broker that enables authorization but accepts unauthenticated clients may have an anonymous path that bypasses the intended role model.
Scope tokens to the workload
Pulsar's JWT documentation warns that token transport is equivalent to sending a password, so TLS should be used. Create tokens for a specific application, environment, and tenant. Do not share a long-lived token across producers, consumers, and administrative jobs.
Review namespace grants, subscription authorization, and administrative roles. The MultiRolesTokenAuthorizationProvider can evaluate a claim containing multiple roles. It should not be used to turn a broad identity claim into unlimited access. Document which role claim is trusted, which authority signs it, and how token revocation works.
Include proxies and brokers
Documentation notes that a proxy may need the same permissions as the client when the client produces or consumes through it. That creates a second identity in the path. The proxy's identity should be scoped to the resources it forwards and separated from human administration.
Test direct broker access and proxy access separately. A perfectly scoped application token can still fail, or gain too much authority, if proxy configuration changes which role is evaluated. Review TLS settings, trust stores, and token audience validation at both layers.
Build a tenant inventory
For each token, record tenant, namespaces, topics, permissions, issuer, audience, expiry, owning application, and secret storage. Compare that record with actual grants returned by Pulsar administrative tooling. Look for roles that can produce into security or audit topics, create subscriptions on sensitive namespaces, or change retention and backlog policy.
Inspect namespaces used by connectors and functions. These components often run with credentials broader than the application workload because they were configured during a pilot. Give them dedicated roles and review their outbound destinations.
Verify revocation
Revoke a test token and confirm that every broker and proxy rejects it. Check whether cached authorization decisions or open connections continue to work. Rotate a role used by a client application and observe the deployment during the transition. The old token should fail; the new one should reach only the intended namespaces.
Review logs for authentication failures, authorization denials, new subscription creation, and administrative changes. Unexpected successful access from a retired token is more important than a large volume of expected denials.
Pulsar makes multi-tenant messaging possible, but the tenant label only becomes a security boundary when token subjects, namespace grants, proxy permissions, and revocation behavior agree. Start with the token principal, follow it through every broker path, and verify the smallest set of resources that the workload actually needs.
