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.
Role Permissions¶
You can use the OrganizationAdmin or AccountAdmin roles to manage all identities.
When working with workload identities, you can use the following roles to manage access to workload identities while maintaining security controls and delegating responsibility to developers:
ResourceOwner¶
Each service account or identity pool can specify accounts that are granted the ResourceOwner role. This principal, or additional principals granted the ResourceOwner role (or Assigner role) after the identity is created, can assign a service account, OAuth identity pool, or certificate identity pool to a Confluent Cloud resource. During creation, you optionally specify one account that is granted the ResourceOwner role. After creation, you can add additional principals to the ResourceOwner role.
As the owner of the service account or identity pool, the ResourceOwner role has the following permissions:
- Grant and revoke access to the specific resource.
- Assign the resource to a Confluent Cloud resource.
- Describe (or view), alter, and delete the resource.
For details about the ResourceOwner role, see Predefined RBAC roles.
Assigner¶
The Assigner role has the following permissions for workload identity management:
- Describe or view service accounts.
- Assign existing service accounts to Confluent Cloud resources.
- Cannot create or manage service accounts.
For details about the Assigner role, see Predefined RBAC roles.
Examples¶
ResourceOwner example¶
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 allows John to:- Manage API keys for the service account.
- Modify the service account’s permissions.
- Assign the service account to different resources.
- Grant other team members the ResourceOwner and Assigner roles to manage and use the service account.
- Assign a group mapping as the principal in the ResourceOwner role to automatically assign the service account to new resources.
- 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 example¶
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 assignMarcusSA
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 withMarcusSA
’s permissions.