# Manage Client-Side Field Level Encryption using Confluent Cloud Console Manage CSFLE encryption rules in the Cloud Console by defining schemas, adding tags to classify sensitive fields, registering encryption keys from your AWS, Azure, or Google Cloud key management system (KMS), and creating encryption rules that map tags to keys. **Quick actions:** - **View rules**: Go to **Stream Governance** → **Schema Registry** → **Rules**. - **Add encryption key**: Register your KEK from AWS KMS, Azure Key Vault, or Google Cloud KMS. - **Create rule**: Select schema + tag + encryption key. - **Grant access**: Assign RBAC permissions for producers (encrypt) and consumers (decrypt). You can use the Confluent Cloud Console to manage Client-Side Field Level Encryption (CSFLE) for protecting your organization’s sensitive data in Confluent Cloud on AWS, Azure, and Google Cloud. For requirements and supported clients, see [Requirements](client-side.md#csfle-requirements). ## Steps to manage CSFLE The high-level steps to manage CSFLE are: 1. Define the schema or choose an existing schema. 2. Add tags to classify your data. 3. Create encryption keys in your key management service (KMS) and add them to Confluent Cloud. 4. Add encryption rules. An encryption rule is a schema subject plus tags plus an encryption key. 5. Grant RBAC permissions. Producers need access to the encryption key to be able to produce messages. Consumers need access to the encryption key to be able to decrypt and access the unencrypted messages. If you do not grant Confluent access to your Key Encryption Key (KEK), you must set up the proper configurations for producers and consumers to access the KEKs. ## View encryption rules To view encryption rules: 1. Go to the Confluent Cloud Console and select your environment. 2. In the left navigation menu, click **Stream Governance** > **Schema Registry** > **Rules**. The **Rules** page displays. On the **Rules** page, you see a listing of any existing encryption rules. For each of the existing rules, the following information is displayed: * Schema subject name * Rule name * Rule category * Tags An *encryption rule* is defined as a schema subject plus tags plus an encryption key. * [Schema](../../../sr/schemas-manage.md#cloud-schemas-manage): The schema defines the structure of the data. Schemas are grouped under schema subjects, so when you work with schemas, you must refer to them by their [schema subject](../../../_glossary.md#term-schema-subject). * [Tags](../../../stream-governance/stream-catalog.md#data-discovery-tagging): The class of data that you want to encrypt. For example, if you have a tag called PII to indicate personally identifiable information, you can create an encryption rule to encrypt all fields tagged with PII. * [Encryption key](../byok/overview.md#byok-encrypted-clusters): The [Key Encryption Key (KEK)](../../../_glossary.md#term-key-encryption-key-KEK) that you want to use to encrypt the specified classification, such as PII. * You are billed for each encryption rule. For example, you can create an encryption rule to encrypt all fields tagged with PII (personally identifiable information). These might relate to credit card numbers, social security numbers, email addresses, names, and so on. The resulting JSON rule might look like this: ```json { "ruleSet": { "domainRules": [ { "name": "encryptPII", "kind": "TRANSFORM", "type": "ENCRYPT", "mode": "WRITEREAD", "tags": ["PII"], "params": { "encrypt.kek.name": "" } } ] } } ``` ## Edit encryption rules To edit an encryption rule: 1. Go to the Confluent Cloud Console and select your environment. 2. In the left navigation menu, click **Stream Governance** > **Schema Registry** > **Rules**. The **Rules** page displays a list of existing encryption rules. 3. Under **Mode** on the right side of the table, click the More button (3 dots) and select **Edit**. Here you can make changes to the rule definition and parameters, as described in [Add an encryption rule](#add-encryption-rule-csfle).  Click **Save** to save any changes you make, or click **Cancel** to discard the changes. ## Add an encryption key Before you can add an encryption rule, you must create an encryption key in your key management service (KMS). You can add that encryption key to Confluent using the Confluent Cloud Console. 1. Open the Confluent Cloud Console and select your environment. 2. In the left navigation menu, click **Stream Governance** > **Schema Registry** > **Encryption keys**. The **Encryption keys** page displays.  3. Click **Add encryption key**. The **Add encryption key** page displays. 4. In the **Name** field, enter a meaningful name. 5. In the **Key management system provider** field, select the key management service that you want to use to manage the encryption key. Supported key management options include AWS, Azure, and Google Cloud. Depending on which provider you select, you are given a link to that provider’s associated key management store. Add a description for the key in the **Description** field. 6. Optionally, enable **Share key access with Confluent Cloud** to allow Confluent to perform server-side operations that require temporary decryption within Confluent Cloud. If you enable this option, follow the steps below to create an encryption key for your key management service (AWS, Azure, or Google Cloud). If you do not want to enable this option, click **Add** at this point to add the encryption key, and skip to the next task: [Add an encryption rule](#add-encryption-rule-csfle). ### Share key access with Confluent Cloud If you enabled **Share key access with Confluent Cloud**, follow the steps below to create an encryption key for each key management service (AWS, Azure, or Google Cloud).  ### AWS 1. Provide your **Name**, select **AWS** as provider, and paste your **KMS key ARN**. 2. Enable **Share encryption key access with Confluent Cloud** if you want Confluent Cloud to perform server-side operations that require temporary decryption within Confluent Cloud services (for example, Schema Registry, ksqlDB, Flink). Confluent Cloud does not store decrypted data. 3. Ensure the KMS key policy and IAM permissions grant access to Confluent as shown in the Confluent Cloud Console. See [AWS KMS key policies](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) and [AWS KMS IAM permissions](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html). 4. Click **Add**. ### Azure 1. Provide your **Name**, select **Azure** as provider, paste the **Key Vault key ID**, and supply your **tenant ID** and **client ID** (user-assigned managed identity). 2. Enable **Share encryption key access with Confluent Cloud** if you want Confluent Cloud to perform server-side operations that require temporary decryption within Confluent Cloud. 3. Configure Azure access for Confluent using managed identity, a custom role with key permissions (encrypt/decrypt/read), and a federated identity credential tied to the Confluent service account as shown in the Confluent Cloud Console. See: [Managed identities](https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities), [Custom roles](https://learn.microsoft.com/azure/role-based-access-control/custom-roles), and [Federated identity credential](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). 4. Click **Add**. ### Google Cloud 1. Provide your **Name**, select **GCP** as provider, and paste the **KMS key resource name**. 2. Enable **Share encryption key access with Confluent Cloud** if you want Confluent Cloud to perform server-side operations that require temporary decryption within Confluent Cloud. 3. Grant the Confluent service account the needed IAM permissions (for example, `cloudkms.cryptoKeyVersions.useToEncrypt` and `useToDecrypt`) and assign them to the service account shown in the Confluent Cloud Console. See: [Custom IAM roles](https://cloud.google.com/iam/docs/creating-custom-roles) and [KMS IAM](https://cloud.google.com/kms/docs/iam). 4. Click **Add**. ## Add an encryption rule Follow the steps below to add encryption rules, which define the class of data that you want to encrypt, and the associated encryption key. * Encryption is only supported for fields of type `string` or `bytes`. 1. Open the Confluent Cloud Console and select your environment. 2. In the navigation menu, click **Stream Governance** > **Schema Registry** > **Schemas**. - Existing schemas are listed on the **Schemas** page.  - If no schemas are listed, or if you want to create a new schema to work with, click **Add a schema**, and follow the steps described in [Create a schema](../../../sr/schemas-manage.md#cloud-schema-create). 3. Select a schema from the list, click **Evolve**, then click **Rules** > **Add rules**. The **Add rules** side panel displays. 4. Create encryption rules for the fields in the schema subject that you want to encrypt. 1. Open the **Category** dropdown list and select **Data encryption rule**. 2. Enter a **Rule name**. Enter a meaningful name that is unique within the schema subject. 3. Enter a **Description**. 4. In the **Encrypt fields with** section, select the **Tags** that the rules apply to and select the **Encryption key** that you want to use. 5. In the **Apply action on** section, select the options that you want to apply to the fields that you want to encrypt. You can apply the following actions: * **On failure (WRITE)**: Default is **ERROR**. * **On success (WRITE)**: Default is **NONE**. * **On failure (READ)**: Default is **ERROR**. * **On success (READ)**: Default is **NONE**. For each action, you can select the following options: * **None** * **DLQ** * **Error** For example, if you select **On failure (WRITE)** and **DLQ**, and the write operation fails, the record is sent to the dead letter queue. If you select **On success (WRITE)** and **Error**, and the write operation succeeds, an error is returned. #### WARNING **Security Risk: Dead Letter Queue (DLQ) with CSFLE** When using DLQ actions with Client-Side Field Level Encryption (CSFLE), be aware that **data sent to the DLQ is written in plaintext (unencrypted)**. This poses a significant security risk as sensitive data that should be encrypted may be exposed in the DLQ. **Do not use DLQ actions with CSFLE** in the current version. If you need error handling for CSFLE-enabled data, use alternative approaches such as: * Setting the action to **Error** to throw exceptions instead of routing to DLQ * Implementing custom error handling in your applications * Using **None** to pass encrypted data through without decryption 6. In the **Parameters** section, you can optionally add parameters to the rule. The parameters are key-value pairs that you can use to configure the rule. 7. Click **Add**. The new rule defines the fields that you want to encrypt and the encryption key that you want to use to encrypt the fields. You can use the same encryption key for multiple fields. 8. Click **Add** to save the rule, or click **Add another rule** to add more encryption rules. The **Encryption rules** page displays with the new encryption rules.