Best Practices for Using API Keys on Confluent Cloud

Review the following recommendations for best practices when using Confluent Cloud API keys and incorporate them into your security strategy.

Use service account API keys for production

API keys for Confluent Cloud can be created with user and service accounts. A service account is intended to provide an identity for an application or service that needs to perform programmatic operations within Confluent Cloud. When moving to production, ensure that only service account API keys are used. Avoid user account API keys, except for development and testing. If a user leaves and a user account is deleted, all API keys created with that user account are deleted and might break applications using user API keys.

Use global API keys

For applications using more than one Confluent Cloud resource, use a global API key to simplify client authentication to Confluent Cloud to a single API key. As long as the associated user or service account has access to the resources, the same global API key can be used across these possible Confluent Cloud resources:

  • Cloud Management API

  • Kafka clusters * Enterprise and Freight (currently private only) * Dedicated clusters (public and private)

  • Schema Registry (private networking)

  • Tableflow

  • Flink

  • ksqlDB

Global API keys can streamline development workflows by simplifying credential management, improve the user experience of using Terraform, or enable multi-cluster failover scenarios for clients.

Note

You cannot convert an existing API key to a global API key.

Due to resource quotas on global API keys, it is not recommended to use global API keys where only a single Confluent resource is accessed, such as an Kafka client that only needs to access one cluster.

Delete unneeded API keys and service accounts

As a standard practice of your security strategy, you should regularly review and clean up your existing API keys and service accounts.

To better understand which API keys are being used, you can review and monitor authorization and authentication events in Confluent Cloud audit logs.

To list the API keys that you currently have, run the confluent api-key list command. Use the --service-account option to list only the API keys associated with the specific service account.

To list the service accounts, run the confluent iam service-account list command.

To delete an API key that is no longer needed, run the confluent api-key delete command.

To delete a service account that is no longer needed, run the confluent iam service-account delete command.

Rotate API keys regularly

Rotating API keys is a good security practice to limit the impact of any potentially leaked API keys.

When you rotate API keys, you perform the following steps:

  1. Create a new API key.

  2. Update the resource or application to use the new API key.

  3. Delete the old API key.

Because service accounts can have multiple active API keys, you can create a new API key without having to remove the old key. This short time period of overlap enables applications to continue running until they can be updated to the new API key. Using a secrets manager can make API key rotation easier by removing the need to make client-side changes during the rotation.

To rotate an API key:

  1. Get the following information:

    • Service Account ID

    • Resource ID (if applicable)

  2. Create an API key for the service account of the appropriate scope (such as resource-scoped to the Kafka cluster). Ensure the API key create request is made by a user with access to create an API key for this service account.

  3. Replace the old key with the new API key.

    1. Update your client or application with the new API key.

    2. Verify that the new API key is working properly.

  4. Delete the old API key.

  5. Verify the old key was deleted.

After verifying that the old API key is deleted, you have successfully rotated the API key.