# Protect Data at Rest Using Self-Managed Encryption Keys on Confluent Cloud Basic encryption of [data at rest](../../../_glossary.md#term-data-at-rest) is provided to all Confluent Cloud clusters by default. This encryption is transparent to the user and is provided through the native encryption services offered by cloud service providers. As a stronger security option, Confluent Cloud provides optional support for self-managed encryption keys when you create Dedicated, Enterprise, or AWS Freight Kafka clusters in Confluent Cloud. Also known as bring-your-own-key (BYOK) encryption, this option might be preferable for organizations that want to use their encryption key to protect data at rest or require the option to disable access by Confluent Cloud. This provides greater privacy and data integrity, which is often required for compliance by government, health, finance, and many other industries. #### IMPORTANT **Key Policy Management is Critical** Self-managed encryption keys require careful management of key policies and permissions. Incorrectly modifying key policies can cause immediate cluster unavailability and data access issues. Always follow the [best practices](best-practices.md#byok-best-practices) and [safe update procedures](byok-aws.md#update-aws-kms-key-policy) when managing your encryption keys. For troubleshooting key policy issues, see [Troubleshoot Key Policy Issues for Self-Managed Encryption Keys](troubleshoot-key-policies.md#byok-troubleshoot-key-policies). ## Benefits of self-managed encryption keys By using self-managed encryption keys, you gain the following benefits: * **Full control over encryption keys**: You have full control over your master key in your cloud service provider’s key management service, as well as the data at rest stored in your Confluent Cloud account. * **Ability to revoke access**: You can revoke access to your encryption keys during a security breach to prevent access to your data at rest. For details, see [Revoke access to data at rest](revoke-access.md#byok-revoke-access). * **Rotate your encryption keys**: You can enable automatic key rotation on your key management service to increase the security of your data at rest. ## Encryption key support for Kafka clusters Confluent Cloud supports self-managed encryption keys across select cloud providers, cluster types, and features. All cloud providers support automatic key rotation for self-managed encryption keys. Confluent Cloud does not support self-managed encryption keys for Flink on any cloud provider. This table shows the self-managed encryption key support by cloud provider, cluster type, and feature: ### AWS #### AWS BYOK Support | Cluster Type | BYOK Support | Tableflow | External Key Manager (EKM) | Imported Key Material | |----------------|----------------|-------------|------------------------------|-------------------------| | Dedicated | ✓ | ✓ | ✓ | ✓ | | Enterprise | ✓ | | ✓ | ✓ | | Freight | ✓ | | | | ### Azure #### Azure BYOK Support | Cluster Type | BYOK Support | Tableflow | External Key Manager (EKM) | Imported Key Material | |----------------|----------------|-------------|------------------------------|-------------------------| | Dedicated | ✓ | ✓ | | | | Enterprise | ✓ | | | | | Freight | | | | | ### Google Cloud #### Google Cloud BYOK Support | Cluster Type | BYOK Support | Tableflow | External Key Manager (EKM) | Imported Key Material | |----------------|----------------|-------------|------------------------------|-------------------------| | Dedicated | ✓ | | ✓ | | | Enterprise | ✓ | | ✓ | | | Freight | | | | | ## Encryption of data at rest on Kafka clusters Confluent Cloud supports encryption of data with self-managed encryption keys for supported Kafka clusters on AWS, Azure, or Google Cloud. Supported cluster types can be encrypted using the key management service (KMS) on your cloud service provider, but there are some differences between the cluster types. For Dedicated, Enterprise, and Freight Confluent Cloud clusters: * Configure and manage encryption of data at rest on your clusters using Confluent Cloud for supported cloud service providers ( [AWS](byok-aws.md#byok-encrypted-clusters-aws), [Azure](byok-azure.md#byok-encrypted-clusters-azure), or [Google Cloud](byok-gcp.md#byok-encrypted-clusters-gcp)) * Use the key management service (KMS) on your cloud service provider to create and manage self-managed encryption keys. * Your data at rest is always stored and encrypted using your self-managed encryption keys. * (Optional) Use client-side field level encryption (CSFLE) to encrypt the most sensitive data on your clients before it is sent to Confluent Cloud. CSFLE ensures that if your data is compromised, only users with access to the encryption keys for sensitive data can access the data. For more information, see [Protect Sensitive Data Using Client-Side Field Level Encryption on Confluent Cloud](../csfle/overview.md#csfle-overview). #### NOTE Self-managed encryption keys are different from Client-Side Field Level Encryption (CSFLE) keys. Self-managed encryption keys encrypt data at rest for your Kafka clusters, while CSFLE keys encrypt specific fields within your data at the client level before it is sent to Confluent Cloud. ### Summary of the encryption process Your persisted data is always encrypted at rest. Your self-managed encryption keys (BYOK) are used to encrypt and protect your data, ensuring strong security and compliance with regulatory requirements. The encryption method depends on your cluster type, cloud provider, and the specific storage tier being used. #### Temporary storage * Enterprise and Freight clusters use Confluent-owned encryption keys to protect your data-at-rest. * Dedicated clusters use your self-managed encryption key to protect your data. The cloud provider handles the encryption transparently. #### Infinite storage * For Dedicated clusters on AWS and Azure, once the data is moved to Infinite Storage, your data is protected using your self-managed encryption key. The cloud provider handles the encryption transparently. * For Dedicated clusters on Google Cloud, once the data is moved to Infinite Storage, Confluent uses a Confluent-owned key coupled with your self-managed encryption key via envelope encryption to protect your data-at-rest. * For Enterprise and Freight clusters, once the data is moved to Infinite Storage, Confluent uses a Confluent-owned key coupled with your self-managed encryption key via envelope encryption to protect your data-at-rest. ##### Global Key Management Confluent Cloud provides a centralized **Encryption Keys** page for managing all your self-managed encryption keys across your organization. This global key management interface provides a consolidated place to view and manage keys. ### Accessing the Encryption Keys page To access the global Encryption Keys page: 1. In the Confluent Cloud Console, click the hamburger menu in the upper right corner. 2. Select **Encryption keys** from the menu. ### Key management features The Encryption Keys page provides the following features: **Key usage and limit tracking** * **Keys in use**: Keys that are attached to clusters for encryption use (will show the attached cluster in the table column) * **Available keys**: Keys that have been onboarded to Confluent but are not attached to clusters * **Total keys**: Total number of keys that you have onboarded to Confluent * **Key limit**: The service quota - maximum number of keys allowed per organization **Key status tracking** Each key displays a “Last known key status” with the following possible states: * **INITIALIZING** (shown as “PENDING” in the UI): Key was newly onboarded to Confluent Cloud and is in the initializing state to check for key validity. This can take up to 5 minutes. The key will stay in initializing state if not set up properly and will only change to “VALID” if validation passes. * **INVALID** (shown as “VALIDATION FAILED” in the UI): The key was valid previously and attached to a cluster. Some change in either key validity or the associated cluster causes this state. * **VALID** (shown as “READY” in the UI): Key has finished onboarding and validation checks passed. Key is ready to be attached to a cluster or is already attached to a cluster. **Key management actions** For each key in the table, you can: * **View key details**: Opens a side panel containing details used to identify the key and a “Permissions and policy” section that restates the instructions for access configuration that were present during key creation. * **Edit key alias**: Edit the human-friendly name of the key. * **Delete key**: Remove keys from your organization. #### NOTE Keys cannot be deleted if they are still attached to a cluster. After you delete a cluster, there is also a five-day cool-down period before the encryption key is released and can be deleted. ### Creating encryption keys A self-managed encryption key can be created in two ways: **Method 1: From the global Encryption Keys page (recommended)** 1. From the global Encryption Keys page, click **Add new key**. 2. **Step 1**: Choose a cloud provider (AWS, Azure, or Google Cloud). 3. **Step 2**: Enter key details including an optional Key Alias to identify the key and the key ID. 4. Once you click **Register key**, the key is created and will appear in the table. 5. **Step 3**: Follow cloud provider specific instructions and policy samples to allow access to the key. 6. Once you click **Finish**, the key enters the initializing state and key validation runs asynchronously. **Method 2: During cluster creation** You can also create and configure encryption keys while creating a new cluster. This method allows you to select existing keys from a dropdown or add new keys during the cluster creation process. ## Requirements To use self-managed encryption keys for your clusters on Confluent Cloud, you must meet the following requirements: * Supported Kafka cluster types: [Dedicated](../../../clusters/cluster-types.md#dedicated-cluster), [Enterprise](../../../clusters/cluster-types.md#enterprise-cluster), and [Freight](../../../clusters/cluster-types.md#freight-cluster). * Create a Kafka cluster on Confluent Cloud for a supported cluster type, selecting the **Use self-managed encryption keys** option. You cannot change this option after the cluster is provisioned. * Use a key management service (KMS) that supports the Key Management Interoperability Protocol (KMIP) version 1.1 or later. Supported key management services include: * Amazon Web Services Key Management Service (AWS KMS) * Azure Key Vault * Google Cloud Key Management Service (Cloud KMS) * Importing key material is supported on AWS KMS. * You can revoke access to data on a cluster by disabling access to the encryption key, but the cluster is inaccessible only after you delete the cluster. For details, see [Revoke Access to Data at Rest](revoke-access.md#byok-revoke-access). * After you delete a cluster, the encryption key associated with the cluster is released after five days and can be reused to create a new encrypted cluster. As a security best practice, encryption keys should not be reused for production clusters. * Each cluster requires a unique encryption key. Using unique encryption keys helps ensure that if one cluster is compromised, the attacker cannot use the same key to access data from other clusters. * Both the Kafka cluster and your KMS must be colocated in the same region. * Self-managed encryption keys are supported on the following cloud service providers: - AWS: See [Use Self-Managed Encryption Keys in Confluent Cloud on AWS](byok-aws.md#byok-encrypted-clusters-aws). - Azure: See [Use Self-Managed Encryption Keys in Confluent Cloud on Azure](byok-azure.md#byok-encrypted-clusters-azure). - Google Cloud: See [Use Self-Managed Encryption Keys in Confluent Cloud on Google Cloud](byok-gcp.md#byok-encrypted-clusters-gcp). * External key managers (EKM) are currently supported only on AWS and Google Cloud. For details, see [Key creation and management](byok-aws.md#byok-requirements-aws-key-management) and [Key creation and management](byok-gcp.md#byok-requirements-gcp-key-management). * Self-managed encryption keys currently apply only to Confluent Cloud Dedicated, Enterprise, and Freight Kafka clusters, and not to any consumer, including Confluent Cloud for Apache Flink®. ## List the service quota for self-managed encryption keys The service quota for self-managed encryption keys (BYOK keys) is applied at the Organization scope instead of the Kafka Cluster scope because self-managed encryption keys must be created before you create an encrypted Kafka cluster using those encryption keys. When you use the Confluent CLI and the Scopes (service-quota/v1) API, the service quota for self-managed encryption keys is displayed as `Max BYOK keys per organization` and the quota code is `byok.max_keys.per_org`. You can view your current key usage and limits on the global **Encryption Keys** page, which displays your keys in use, available keys, total keys, and key limit. The default service quota for self-managed encryption keys is listed in [organization service quotas](../../../quotas/service-quotas.md#ccloud-resource-limits-organization). To use the Confluent CLI to view the currently applied service quota for self-managed encryption keys in your organization, run the following command: ```shell confluent service-quota list organization ``` To use the [Scopes (service-quota/v1) API](https://docs.confluent.io/cloud/current/quotas/quotas.html) to display the currently applied service quota for self-managed encryption keys in your organization, see [Organization quotas](../../../quotas/quotas.md#cc-quotas-organization). ## View the cluster security settings After you create and provision a Kafka cluster that uses a self-managed encryption key, you can view the security settings. You can use these cluster security settings to verify the correct encryption key is used. To view your cluster security settings: 1. Select your Confluent Cloud cluster. 2. Click **Cluster settings** and then **Security**. Note that anyone authorized to view your clusters can view this information. ## Related content * [Use Self-Managed Encryption Keys in Confluent Cloud on AWS](byok-aws.md#byok-encrypted-clusters-aws) * [Use Self-Managed Encryption Keys in Confluent Cloud on Azure](byok-azure.md#byok-encrypted-clusters-azure) * [Use Self-Managed Encryption Keys in Confluent Cloud on Google Cloud](byok-gcp.md#byok-encrypted-clusters-gcp) * [Revoke Access to Data at Rest for Dedicated and Enterprise Kafka Clusters on Confluent Cloud](revoke-access.md#byok-revoke-access) * [Best Practices for Using Self-Managed Encryption Keys](best-practices.md#byok-best-practices)