Use API Keys to Control Access in Confluent Cloud

Confluent Cloud API keys are used to control access to Confluent Cloud components and resources. Each API key consists of a key and a secret. For details about using user and service accounts and their ownership of API keys, see Ownership of API keys.

Use the resource API keys to control access to Confluent Cloud components and services. Here are the API keys for Confluent Cloud components:

Resource API key Description
Kafka Required to access your Kafka clusters and Kafka resources. Each Kafka API key is valid for one specific Kafka cluster.
Schema Registry Required to access the Confluent Cloud Schema Registry. Each Schema Registry API key is valid for one specific Schema Registry.
ksqlDB Required to interact with your ksqlDB applications in Confluent Cloud. Each ksqlDB API key is valid for one specific ksqlDB application.
Flink Required To manage Flink workoads programmatically in Confluent Cloud for Apache Flink®️. You can create API keys for user accounts and service accounts.

Use Cloud API keys to control access to Confluent Cloud resources and use the Confluent Cloud APIs available for environments, user accounts, service accounts, connectors, Metrics API, and other resources.

To create and manage API keys in Confluent Cloud, you can use the following tools:

For recommendations on using API keys, see Best Practices for Using API Keys in Confluent Cloud.

Ownership of API keys

Each API key is associated with a specific service account or user account. The limit on the number of API keys that can be associated with user or service accounts is specified in Service Quotas for Confluent Cloud.

  • A best practice is to create separate service accounts associated with an API keys for each applications or use case.
  • Using API keys associated with a user account is not recommended for production environments, but can be used for development and testing. If you use an API key associated with a user account, the API key inherits the permissions of the user account. If the user account is deleted, the API key is also deleted.
  • API keys are immutable and cannot be modified. If you need to change the permissions associated with an API key, you must delete the key and create a new one.
  • Access control lists (ACLs) and role bindings are associated with principals, not with API keys. For details, see Role-based Access Control (RBAC) in Confluent Cloud and Use Access Control Lists (ACLs) for Confluent Cloud.
  • Restrict access to an application that uses an API key associated with a service account:

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.

Resource API keys

Use the resource API keys to control access to specific Confluent Cloud components and services. Resource API keys are available for Kafka, Schema Registry, and ksqlDB resources.

Each resource API key is valid for one specific resource — one Kafka cluster, one Schema Registry, or one ksqlDB application.

Important

Resource API keys propagate quickly after creation, usually within a few minutes. If you try to use an API key before propagation completes, authentication failures occur. Depending on workloads, you might need to wait a few minutes more and try again.

Create a resource API key

You can create resource API keys for Kafka clusters, Schema Registry, and ksqlDB applications.

Prerequisites
  1. Verify that you have any required access control lists (ACLs) for the service account.

    Important

    You cannot use Confluent Cloud Console to associate a resource key with a service account.

    For Schema Registry and ksqlDB, no access control is available.

  2. Sign in to your cluster using the confluent login CLI command.

    confluent login
    
    Enter your Confluent Cloud credentials:
    Email: susan@myemail.com
    Password: ********
    
  3. Get the resource ID (<resource-id>) for Kafka, Schema Registry, or ksqlDB. To find the resource ID, use the following Confluent CLI commands:

    • Kafka: confluent kafka cluster list
    • Schema Registry: confluent schema-registry cluster describe
    • ksqlDB: confluent ksql cluster list
  4. Create the API key and secret using the confluent api-key create command.

    confluent api-key create --service-account <service-account-id> --resource <resource-id> --description "prod key"
    
  5. Save the API key and secret in a secure location. The secret cannot be retrieved later.

  6. Use the confluent api-key use command to specify the API key and secret you will be using with Confluent CLI commands on the resource. For Schema Registry resources only, you do not need to specify the API key to use.

    confluent api-key use <api-key>
    

Edit a resource API key description

Follow the procedures below to add, edit, or delete the optional description of an API key.

To edit the description of a resource API key, use the confluent api-key update command.

confluent api-key update <api-key> --description <description-string>

Delete a resource API key using the Confluent Cloud Console

You should delete API key if it no longer needed or if its secret is compromised.

Warning

When a resource is deleted, associated API keys are also deleted.

  1. From the appropriate API Access tab for the Kafka, Schema Registry, or ksqlDB resource, select the key that you want to delete.

  2. Click the trash icon. The Confirm API key deletion dialog appears.

  3. Click Confirm.

    Caution

    The delete API key action cannot be undone.

Create a Kafka API key associated with a user account

You can create a new Kafka API key and associate it with an existing user account.

  1. Navigate to the cluster in which you want to create a Kafka API key.
  2. Click the API access tab, and then click +Add key.
  3. Select Create an API key associated with your account. When you specify this option, the new API key will inherit the same access permissions that are already specified for your existing user account.
  4. Enter a description, save your API key and secret in a safe place, and select the checkbox indicating you have saved the key and secret. Click Save.

Cloud API keys

Use Cloud API keys to control access to Confluent Cloud resources and use the Confluent Cloud APIs available for environments, user accounts, service accounts, connectors, Metrics API, and other resources.

Important

Cloud API keys are scoped to your entire organization, not just to a specific resource.

Create a Cloud API key

Prerequisites
  1. Sign in to your cluster using the confluent login command.

    confluent login
    
    Enter your Confluent Cloud credentials:
    Email: susan@myemail.com
    Password: ********
    
  2. Before creating an Cloud API key associated with a service account, use RBAC to restrict access to applications that use the key.

  3. Create the Cloud API key using the confluent api-key create command, specifying the resource (--resource) as cloud. By default, this associates the key with your user account. If you want to associate the key with a service account instead, specify the service account flag (--service-account). A description (--description) is optional but recommended.

    confluent api-key create --resource cloud --description <key-description> --service-account <service-account-id>
    
  4. Save the API key and secret output in a secure location. The secret is not retrievable later.

Important

When you remove a user’s role assignment on a cluster for which the user created an API key, then the API key will continue to work even after the user’s role assignment has been removed. For example:

  • Bob has the OrganizationAdmin role.
  • Bob creates an API key for cluster_1 in the Prod_1 environment.
  • Bob’s roles are updated, and he no longer has the OrganizationAdmin role in Prod_1. Now he is assigned the EnvironmentAdmin role for the Dev_1 environment.
  • The API key that Bob created continues to work for cluster_1.

In such cases, if the API key allows unintended access, you must delete it:

# List the API keys for ``cluster_1``
confluent api-key list --resource lkc-123456
# Delete the API key that Bob created for ``cluster_1``
confluent api-key delete <api-key>