Service Accounts for Confluent Cloud¶
Each service account represents an application programmatically accessing Confluent Cloud.
You can manage application access to Confluent Cloud by using service accounts. Permissions can be specified using ACLs and role bindings tied to a specific service account. ACLs and role bindings for service accounts are set by an administrator or another user with a similar role within the organization.
Service accounts are an organization-level resource, and there is a limit on the number of service accounts in an organization.
Service accounts span the entire organization and can own API keys for many different resources, including development and production clusters. A typical use case has one team administering the Confluent Cloud streaming platform and issuing service accounts (with ACLs applied) to various application teams that use the streaming platform. While service accounts cannot sign in to the Confluent Cloud Console, they can own any type of API keys that can be used for CLI or API access. Keep in mind the following:
- Although users can leave or change roles within a company, applications continue to operate independently of the users, service accounts are especially useful in organizations requiring special identifiers for applications or services not be tied to a specific user.
- The number of API keys that can belong to a specific service account is limited. For details, see Service Quotas for Confluent Cloud.
- You can create service accounts using any of the following methods:
- Confluent Cloud Console. When creating service accounts using the Confluent Cloud Console, you can create Kafka and Confluent Cloud API keys and make the owner a service account. The Cloud Console cannot create Schema Registry or ksqlDB API keys owned by a service account.
- Confluent CLI command confluent iam service-account create. When you create a service account using Confluent CLI, you can optionally create any type of API key and make the owner a service account.
- Confluent Cloud API
- Confluent Terraform Provider
- Kafka ACLs only apply to Kafka clusters and are not supported for other resource types. Hence, ACLs that exist for a service account are not inherited when you create a Schema Registry API key from that service account.
| API key type | Managed in Confluent Cloud Console? | Managed in Confluent CLI? | Managed in Confluent Terraform Provider? |
|---|---|---|---|
| Kafka | Yes | Yes | Yes |
| Schema Registry | Yes | Yes | Yes |
| ksqlDB | No | Yes | Yes |
| Flink | No | Yes | Yes |
| Confluent Cloud | Yes | Yes | Yes |
Caution
When you delete a user account or service account, all associated API keys will also be deleted. Any client applications using a deleted API key will lose access, which may cause an outage for your streaming application. Always confirm that none of the API keys owned by an account are in active use before deleting a user or service account.