Identity Pools — Confluent Self-Service Docs

Overview

Identity pools enable external identity providers (like Microsoft Entra ID) to authenticate directly with Confluent Cloud without needing separate Confluent credentials. Applications authenticate using OAuth/OIDC tokens from your identity provider, and Confluent maps those tokens to the appropriate pool and its permissions.

Each identity pool has a filter expression (written in CEL — Common Expression Language) that determines which tokens are accepted, and a type that determines the role bindings (permissions) assigned to matching identities.

Confluent Documentation

Identity Pools vs. Service Accounts

Both identity pools and service accounts enable machine-to-machine authentication, but they use different credential models:

	Service Accounts	Identity Pools
Credentials	Confluent API key + secret	OAuth/OIDC tokens from your IdP
Rotation	Manual key rotation	Automatic via IdP token refresh
Mapping	One account per application	One pool can serve multiple identities
Best for	Simple setups, legacy apps	Modern OAuth-based apps, centralized IdP

Note

If your applications already use Microsoft Entra ID for authentication, identity pools provide a more seamless and secure experience since credentials are managed by your existing identity provider.

Naming Convention

Identity pool names follow the same naming convention as other resources:

Dedicated Clusters


      {business_unit}-{stage}-{id}

Example: sales-dev-data-pipeline

Shared Clusters


      {landing_zone}-{business_unit}-{stage}-{id}

Example: edh-shared-scada-dev-data-pipeline

Note

When creating an identity pool, you only need to provide the identifier. The system automatically normalizes it and adds the appropriate prefix.

Pool Types

Like service accounts, the type determines which role bindings are applied. These are system-defined templates — additional types will be added in future releases.

Producer

Read/write access to topics and transactional IDs, read access to consumer groups and Schema Registry subjects, plus Operator role. Suitable for applications that produce data to Kafka.

Consumer

Read access to topics, consumer groups, and Schema Registry subjects, plus Operator role. Suitable for applications that only consume data from Kafka.

Filter Expressions

Each identity pool has a CEL (Common Expression Language) filter that determines which OAuth/OIDC tokens are accepted. The filter is evaluated against the claims in the incoming token.

Base Filter

All identity pools automatically include a base filter that verifies the token comes from the configured Azure tenant issuer. You can optionally append additional CEL conditions.

Custom Filter Suffix

You can add a custom CEL expression to further restrict which tokens match. This is combined with the base filter using a logical AND. For example:

# Only match tokens from a specific application
claims.appid == "your-app-client-id"

# Only match tokens with specific group membership
"your-group-id" in claims.groups

Note

The filter can be updated after creation using the edit functionality. This allows you to refine access control without recreating the pool.

Creating Identity Pools

When you create an identity pool, the following happens automatically:

Name normalization: Your identifier is normalized and prefixed based on the naming convention
Pool creation: The identity pool is registered with the configured identity provider
Filter application: The CEL filter is set (base tenant filter + optional custom suffix)
Role bindings: Permissions are assigned based on the selected type (producer/consumer)

Important

Deleting an identity pool also removes all its associated role bindings, immediately revoking access for any applications using that pool. This operation requires admin privileges.

Best Practices

Use identity pools when your applications already authenticate via Microsoft Entra ID
Create separate pools for producers and consumers to follow the principle of least privilege
Use specific CEL filters to restrict which applications can use each pool
Test identity pool configuration in dev/qas before creating in production
Monitor pool usage to ensure only expected applications are authenticating
Keep filter expressions simple and well-documented
Prefer identity pools over service accounts for new applications to avoid managing API key secrets