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 and can only create and describe workload identities:

Delegation roles (resource-specific)

The following roles allow you to grant targeted permissions without giving broad administrative access:

  • ResourceOwner: Manage specific assigned workload identities.
  • 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.

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.

  1. 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.
  2. 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.

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.

  1. Marcus, an OrganizationAdmin, creates a service account (MarcusSA) and grants it the necessary permissions to read/write to specific Kafka topics.
  2. 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.
  3. 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.

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.

Related content