Manage Workload Identities on Confluent Cloud

This document explains how to manage workload identities in Confluent Cloud to securely authenticate applications and services. Workload identities are organization-level resources that provision access to Confluent Cloud resources for applications and services.

Confluent Cloud provides the ResourceOwner and Assigner roles to help implement proper separation of duties and least-privilege access control. Using these roles, you can delegate the responsibility to manage workload identities to developers while maintaining security controls. This approach is preferred over granting broader RBAC roles like OrganizationAdmin or AccountAdmin to developers.

RBAC roles for managing workload identities

You can use the OrganizationAdmin or AccountAdmin roles to manage all identities.

To manage workload identities, you need different roles depending on whether you want to create a new service account, OAuth identity pool, or certificate identity pool, or manage an existing one.

Administrative roles (organization-wide)

The following roles can perform all workload identity operations, including creating, describing, updating (altering), and deleting service accounts, OAuth identity pools, and certificate identity pools:

Creation roles (limited scope)

The following roles grant limited permissions to create and describe workload identities:

The ResourceOwner role grants the ability to create workload identities regardless of the resource that the role is scoped to. For example, a principal with ResourceOwner on a single topic can create new service accounts and identity pools. For details, see ResourceOwner.

Delegation role (resource-specific)

The following role allows you to grant targeted permissions without giving broad administrative access:

Assigner: Assign existing service accounts to Flink statements and connectors.

For detailed information about these roles, see Predefined RBAC roles.

Delegate workload identity management

You can use the ResourceOwner and Assigner roles to delegate workload identity management without granting broad administrative access. This approach follows the principle of least privilege and provides the following advantages over giving broader RBAC roles like OrganizationAdmin or AccountAdmin:

Improved security: Users only get the minimum permissions they need.
Better audit trails: Clear separation between who can manage and who can assign.
Reduced risk: Limited scope reduces potential impact of compromised accounts.
Easier compliance: Granular permissions support regulatory requirements.

The examples below show practical implementation patterns for these delegation scenarios.

Common use cases for delegation include:

For service accounts:
- Development teams managing their own service accounts for applications.
- DevOps teams managing infrastructure service accounts for CI/CD pipelines.
- Data engineers managing service accounts for data pipeline applications.
- Security teams managing audit and monitoring service accounts.
For OAuth identity pools:
- Application teams managing SSO configuration for their web applications.
For certificate identity pools:
- Infrastructure teams managing mTLS certificates for microservices.

ResourceOwner permissions

The ResourceOwner role has the following permissions over assigned workload identities:

Update or alter workload identity details (for example, name or description).
Delete the workload identity.
Grant and revoke access permissions for the workload identity.
Describe and view workload identity information and settings.
Assign existing service accounts to Flink statements and connectors.
For a service account, create, describe, update, and delete the API keys that belong to that service account.

Beyond these permissions over an assigned workload identity, the ResourceOwner role grants the ability to create new workload identities, no matter which resource the role is scoped to. A principal with ResourceOwner on any resource, such as a single topic, can create service accounts, OAuth identity pools, and certificate identity pools. The principal can only grant those new identities permissions on the resources that the principal owns, unless the principal holds other roles that grant broader permissions. For details, see ResourceOwner.

Example: Delegate service account management to a team lead

For the following example, Sarah, an OrganizationAdmin, creates a service account (TeamAServiceAccount) for her development team and then delegates management of the service account to John, the team lead.

Sarah, an OrganizationAdmin, creates a service account (TeamAServiceAccount) for her development team and then decides to delegate management of the service account to John, the team lead, by granting him the ResourceOwner role. This gives John full control over the service account, including the ability to modify permissions, assign it to resources, and grant access to other team members.
John then grants the Assigner role to his team members, allowing them to use TeamAServiceAccount with their Flink statements while maintaining control over the service account’s configuration.

Assigner permissions

The Assigner role has the following permissions for service account assignment:

Describe and view service accounts.
Assign existing service accounts to Flink statements and connectors.

A principal with the ResourceOwner role for a service account can grant the Assigner role for that service account to other principals. This lets a team lead or an automation identity that holds ResourceOwner delegate service account usage without needing broader roles like OrganizationAdmin or AccountAdmin.

Example: Allow developers to use existing service accounts

For the following example, Marcus, an OrganizationAdmin, creates a service account (MarcusSA) and grants it the necessary permissions to read/write to specific Kafka topics. The Assigner role is granted to Alice, a developer, to allow her to assign MarcusSA to Flink statements.

Marcus, an OrganizationAdmin, creates a service account (MarcusSA) and grants it the necessary permissions to read/write to specific Kafka topics.
Marcus grants Alice, a developer, the Assigner role for MarcusSA. This lets Alice assign MarcusSA to Flink statements she creates, but she cannot modify the service account’s permissions or create API keys.
When Alice creates and deploys a new Flink SQL statement, she can see and select MarcusSA from the list of available service accounts to run the statement with MarcusSA’s permissions.

Example: Grant resource ownership during service account creation

For automated workflows, such as CI/CD pipelines, you can assign the ResourceOwner role at the same time you create a service account. This avoids granting the role in a separate step afterward. Doing so lets an AccountAdmin automation identity create service accounts with least-privilege delegation already in place, without needing to configure every end user’s access individually.

For the following example, an automation pipeline running as an AccountAdmin creates a service account (AutomationSA) and assigns Priya, a team lead, as the ResourceOwner at creation time. Priya can then grant the Assigner role to her team members as needed, without requiring further AccountAdmin involvement.

The automation pipeline, running with AccountAdmin permissions, creates the service account and assigns Priya as ResourceOwner in the same command:
```
confluent iam service-account create AutomationSA \
  --resource-owner u-111aaa \
  --description "Service account for automated deployment pipeline"
```
Requires CLI version 4.18.0 or later. For details, see confluent iam service-account create.

Priya, now the ResourceOwner for AutomationSA, grants the Assigner role to Diego, a developer on her team:

confluent iam rbac role-binding create \
  --principal User:u-222bbb \
  --role Assigner \
  --resource ServiceAccount:sa-1a2b3c

Diego can now assign AutomationSA to his Flink statements and connectors. Priya doesn’t need to change anything further, and no administrator needs to intervene to delegate access to Diego.

This pattern applies the principle of least privilege programmatically: administrators grant ResourceOwner directly during creation, and ResourceOwners take over granting Assigner to end users as needed.

When to use the ResourceOwner and Assigner roles

Use the following sections to help you decide when to use each role, and how to use them together.

Use ResourceOwner when:

You need someone to fully manage a workload identity (update, delete, configure permissions or settings).
You want to delegate ownership of a service account, OAuth identity pool, or certificate identity pool to a team lead or manager.
The person needs to grant access to others or modify the workload identity settings.
You want to implement a “hands-off” approach where administrators don’t manage day-to-day workload identity operations.

Use Assigner when:

You only need someone to use existing service accounts (not modify them).
Developers need to assign service accounts to their Flink statements and connectors.
You want to maintain strict control over service account configuration.
The person should be able to assign the service account but not change its permissions or settings.

Use both roles together:

Grant ResourceOwner to a team lead who manages service accounts.
Grant Assigner to team members who need to use existing service accounts.
This creates a clear separation between management and usage responsibilities.
The team lead can modify the service accounts as needed while developers can use them for their applications.
This pattern scales well as your team grows and you add more service accounts.
Note: This pattern is most effective with service accounts. OAuth and certificate identity pools typically use ResourceOwner-only delegation since they don’t support usage delegation through the Assigner role.