apache/pulsar · warning · RestException

Don't have permission to connect to this namespace

Error message

Don't have permission to connect to this namespace

What it means

HTTP 401 UNAUTHORIZED thrown by canLookupTopic (validateTopicOperation-style path): the authorization service decided the given role is not allowed to look up (connect to) the topic's namespace. The client cannot discover or attach to the topic.

Source

Thrown at pulsar-broker/src/main/java/org/apache/pulsar/broker/web/PulsarWebResource.java:961

    }

    protected static CompletableFuture<Void> checkAuthorizationAsync(PulsarService pulsarService, TopicName topicName,
                        String role, String originalPrinciple, AuthenticationDataSource authenticationData,
                        AuthenticationDataSource originalAuthenticationData) {
        if (!pulsarService.getConfiguration().isAuthorizationEnabled()) {
            // No enforcing of authorization policies
            return CompletableFuture.completedFuture(null);
        }
        // get zk policy manager
        return pulsarService.getBrokerService().getAuthorizationService().allowTopicOperationAsync(topicName,
                TopicOperation.LOOKUP, originalPrinciple, role, originalAuthenticationData, authenticationData)
                .thenAccept(allow -> {
                    if (!allow) {
                        LOG.warn()
                                .attr("topic", topicName)
                                .attr("role", role)
                                .log("Role is not allowed to lookup topic");
                        throw new RestException(Status.UNAUTHORIZED,
                                "Don't have permission to connect to this namespace");
                    }
        });
    }

    // Used for unit tests access
    public void setPulsar(PulsarService pulsar) {
        this.pulsar = pulsar;
    }

    protected boolean isLeaderBroker() {
        return isLeaderBroker(pulsar());
    }

    protected static boolean isLeaderBroker(PulsarService pulsar) {
        // For extensible load manager, it doesn't have leader election service on pulsar broker.
        if (ExtensibleLoadManagerImpl.isLoadManagerExtensionEnabled(pulsar)) {
            return true;

View on GitHub (pinned to 820761864e)

Solutions

  1. Grant the role lookup/produce/consume permission: admin.namespaces().grantPermissionOnNamespace(ns, role, Set.of(AuthAction.consume))
  2. Verify the client is authenticating with the role you intend (check clientAppId/originalPrincipal in broker logs)
  3. If using wildcard role matching, ensure the policy pattern actually matches the authenticated role
  4. If the principal differs from the authenticated one (proxy scenarios), also grant the originalPrincipal

Example fix

// before: role denied at lookup
PulsarAdmin admin = PulsarAdmin.builder().serviceHttpUrl(...).authentication(...).build();
// after (as superuser) grant the action
admin.namespaces().grantPermissionOnNamespace("public/default", "my-role",
    Set.of(NamespaceOperation.PRODUCE, NamespaceOperation.CONSUME));
Defensive patterns

Strategy: try-catch

Validate before calling

try {
    Map<String, Set<AuthAction>> perms = admin.namespaces().getPermissions(ns);
    if (!perms.containsKey(myRole)) throw new IllegalStateException("role has no grants on namespace");
} catch (PulsarAdminException e) { /* not authorized even to read */ }

Try / catch

try {
    lookupTopic(topic);
} catch (PulsarAdminException e) {
    if (e.getStatusCode() == 401 && e.getMessage().contains("permission to connect")) {
        throw new SecurityException("grant consume/lookup on namespace to role first", e);
    } else throw e;
}

Prevention

When it happens

Trigger: A client calls topic lookup (or an admin operation that performs lookup) with a role lacking 'consume'/'lookup' authorization on the namespace; superuser checks fail and namespace-level authorization denies the role.

Common situations: Missing grant for the client's role on the namespace; role changed after rotating credentials (e.g. new OIDC subject); authorizationEnabled=true but policies never granted the role; wildcard role patterns not matching the actual role.

Related errors

AI-assisted analysis of apache/pulsar@820761864e (2026-09-06). Data as JSON: /api/errors/ce0b3a31f54579c5. Report an issue: GitHub.