Skip to main content
In Apache Pulsar, authorization is a critical security feature that controls what users can do within the system. By granting permissions, you can ensure that users only have access to the resources and actions they need, enhancing the security and integrity of your messaging infrastructure.

Key Concepts

Role: A role is an identifier that represents a user or an application. Permissions are granted to roles, not individual users directly. Actions: Actions are the operations that a role is permitted to perform. Common actions include producing and consuming messages.

OIDC issuer boundaries

When OIDC uses sub as its role claim, permissions apply to the returned subject string. The API key authentication provider does not automatically include the issuer in that role. Two trusted issuers can therefore assert the same role and receive the same permissions, including a matching superUserRoles entry. AuthorizationProviderApiKeys also checks issuer-specific authorization claims, such as authzRoleClaim and authzAdminRole. Configure these for each trusted issuer. The global superUserRoles list and role permissions still match role strings without including the issuer. An audience check rejects a token issued for a different audience. It does not prevent a trusted issuer from signing a new token with the target audience and an existing privileged subject. Before adding an issuer, ensure that its issuance policies enforce your role and audience boundaries, or use a role mapping and authorization design that separates issuers. For example, system:serviceaccount:pulsar:broker-admin from either trusted issuer maps to the same role when the provider selects sub. Identical namespace and ServiceAccount names in separate Kubernetes clusters do not provide role isolation within a Pulsar cluster that trusts both issuers. See OIDC authentication for configuration and validation steps.

Permission Levels

Pulsar allows you to grant permissions at two main levels:
  • Namespace Level: When you grant permissions at the namespace level, the role receives those permissions for all topics within that namespace. This is useful for granting broad access to a set of related topics.
  • Topic Level: For more granular control, you can grant permissions directly on a specific topic. This restricts the role’s access to only that individual topic.

Available Actions

The following actions can be granted to roles:
  • produce: Allows the role to publish messages to a topic.
  • consume: Allows the role to subscribe to and consume messages from a topic.
  • sources: Allows the role to interact with Pulsar IO sources.
  • sinks: Allows the role to interact with Pulsar IO sinks.
  • functions: Allows the role to manage Pulsar Functions.
  • packages: Allows the role to manage packages.

Grant Permissions with pulsar-admin

You can use the pulsar-admin command-line tool to manage permissions.

Grant Namespace Permissions

To grant permissions on all topics within a namespace, use the pulsar-admin namespaces grant-permission command. Command Syntax:
Parameters:
  • --role <role>: The role to which you are granting permissions.
  • --actions <actions>: A comma-separated list of actions to grant (e.g., produce,consume).
  • <tenant>/<namespace>: The target namespace.
Example: To grant the role my-app permission to produce and consume messages on all topics in the my-namespace namespace under the my-tenant tenant, run the following command:

Grant Topic Permissions

To grant permissions on a single topic, use the pulsar-admin topics grant-permission command. Command Syntax:
Parameters:
  • -r, --role <role>: The role to which you are granting permissions.
  • -a, --actions <actions>: A comma-separated list of actions to grant.
  • <topicName>: The full name of the topic, in the format persistent://<tenant>/<namespace>/<topic>.
Example: To grant the role my-specific-app permission to only produce messages to the topic my-topic in the my-namespace namespace and my-tenant tenant, use this command:
For more information about authorization and access control in Pulsar, see the Apache Pulsar documentation.