Skip to main content
Authentication identifies a Pulsar client and returns a role. Authorization determines what that role can do. Configure both the authentication provider and the permissions for the returned role.

​
Choose a provider

For Kubernetes workloads, a projected ServiceAccount token provides a short-lived credential that Kubernetes refreshes. Clients outside Kubernetes need credentials issued through their identity provider or API key service, or a client certificate. Configuring an issuer on a broker does not itself create credentials for clients.

​
Separate server and internal client authentication

The Operator exposes three configuration surfaces: Starting with StreamNative Operator 0.20.16, clientAuth is rendered even when you omit authentication. Upgrade the Operator and its CRDs before using that combination. See Upgrade StreamNative Operator. Custom authentication properties override the corresponding properties generated from typed authentication fields. For example, PULSAR_PREFIX_authenticationProviders in custom determines the effective authentication providers. Keep overrides consistent with the remaining authentication and authorization settings. This precedence does not make generated service URLs suitable for a TLS client; check the actual TLS endpoint separately. Supported properties in spec.config.custom can use names without a prefix, as shown in the JWT example. Use the PULSAR_PREFIX_ form when a custom value must override a property generated from typed fields. Inspect the generated ConfigMap and effective configuration after changing providers.

​
Grant permissions to the authenticated role

For the API key service procedure, the Pulsar role is the token jti. For a custom OIDC issuer, configure its role claim separately; Kubernetes ServiceAccount tokens use sub. With certificate authentication, the role is the client certificate’s common name. Grant permissions to that exact role, and reserve superUserRoles for administrative identities. See Grant permissions. When you trust multiple OIDC issuers, check the issuer and role boundary. Audience validation alone does not give identical role names separate permissions for each issuer.

​
Validate the configuration

Verify an authorized connection, rejected credentials, message production and consumption, and any broker operation that uses an internal client, such as topic-policy updates. A broker Pod can be Ready while an internal client is misconfigured. The detector has its own authentication settings and runtime. Configure and validate it separately using Pulsar Detector.