Manage Key Policies on Confluent Cloud

This document provides guidelines for managing key policies for self-managed encryption keys (BYOK) in Confluent Cloud across different cloud providers.

Warning

Avoid updating key policies unless absolutely necessary. Key policy misconfigurations can cause immediate cluster unavailability and service disruption. Follow a “set it and forget it” approach - ensure your key policy is configured correctly during initial setup. If policy changes are required, thoroughly test them in non-production environments first and implement proper change management procedures.

AWSAzureGoogle Cloud

KMS keys belong to the AWS account in which they are created.

• The IAM user who creates a KMS key is not automatically considered to be the key owner and does not automatically have permission to use or manage the KMS key they created. To get permission, you must specify a key policy that includes permission statements that control access. For details, see Permissions for creating KMS keys.

By default, the key policy grants every principal in an AWS account access to the AWS KMS customer-managed key (CMK). To restrict access to your encryption key, you can create your own AWS KMS key policy that specifies a permission set.

• The permission sets must be added to the key policy when you create the KMS key to ensure that you can control access to the KMS key.
• Aliases can be used to control access to KMS keys, following the best practice of granting least privileged access. For details, see Using aliases.

For details, see Key policies in AWS KMS.

Example of an AWS KMS key policy

Your AWS KMS key policy consists of two distinct permission statements that grant access for compute and storage requirements.

The first permission statement grants Confluent AWS accounts the permissions required to describe the KMS encryption key, list metadata information about the key, perform encryption, decryption, re-encryption, and data-key generation. In the example below, the first statement specifies the required Confluent AWS accounts that are granted these permissions using the two roles for blob (tiered) and block (disk) storage. As the current Confluent Cloud infrastructure continues to grow and scale, an increasing number of accounts is required to maintain scalability.

The second permission statement grants Confluent AWS accounts the permissions required to manage (create, list, and revoke) grants for data storage. These grants are internally used to provide access for performing cryptographic operations to the specified grantee principal. In this case, the permission statement creates a grant for the role that manages block storage, which in turn creates the grant for the AWS internal roles (for example aws:ec2-infrastructure) to persistently attach AWS EBS volumes (block storage) to the AWS EC2 instance where the Kafka broker (pod) runs.

{
  "Sid": "Allow Confluent account(s) (152535741197) to use the key",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "arn:aws:iam::152535741197:role/cc-kafka-d45e6381-b878-11ed-bdff-028e28f108bd"
    ]
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:DescribeKey"
  ],
  "Resource": "*"
},
{
  "Sid": "Allow Confluent account(s) (152535741197) to attach persistent resources",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "arn:aws:iam::152535741197:role/cc-kafka-d45e6381-b878-11ed-bdff-028e28f108bd"
    ]
  },
  "Action": [
    "kms:CreateGrant",
    "kms:ListGrants",
    "kms:RevokeGrant"
  ],
  "Resource": "*"
}

For "Resource": "*" above, the wildcard character (*) indicates that the KMS key policy applies to the customer-managed key (CMK).

Update an AWS KMS key policy safely

Follow these steps to safely update your AWS KMS key policy without disrupting your Confluent Cloud cluster operations:

Warning

Important: Incorrectly modifying key policies can cause immediate cluster unavailability. Always follow these procedures carefully and have a recovery plan ready.

Prerequisites

• Administrative access to your AWS account and KMS service.
• Current working backup of your key policy.
• Planned maintenance window for policy updates.
• Understanding of the required Confluent permissions

Step 1: Create a backup of your current key policy

Before making any changes, create a backup of your current working key policy. You can retrieve the current policy using the AWS CLI:

aws kms get-key-policy \
  --key-id <your-key-id> \
  --policy-name default \
  --output text > key-policy-backup-$(date +%Y-%m-%d).json

Alternatively, you can use the AWS KMS console to view and copy the policy. For detailed steps, see Viewing a key policy in the AWS documentation.

Step 2: Validate your proposed changes

Before applying changes, validate the policy using AWS IAM Access Analyzer:

aws accessanalyzer validate-policy \
  --policy-document file://new-policy.json \
  --policy-type RESOURCE_POLICY

Review the findings and fix any issues with severity ERROR before proceeding. For more details, see Validate policies with IAM Access Analyzer and the validate-policy CLI reference.

Step 3: Apply the policy update

During your planned maintenance window, apply the policy update:

Using the AWS CLI (recommended)

aws kms put-key-policy \
  --key-id <your-key-id> \
  --policy-name default \
  --policy file://updated-policy.json

Using the AWS Console

You can also update the policy through the AWS KMS console. For detailed steps, see Changing a key policy in the AWS documentation. Ensure you don’t remove any Confluent-required permissions during the update.

Step 4: Verify the update

1. Immediately after applying the policy, verify your cluster is still operational:
   • Check cluster status in the Confluent Cloud Console.
   • Verify producers and consumers are still functioning.
   • Monitor for any error messages or alerts.
2. Check |aws| CloudTrail events for any access denied errors related to your KMS key:

# For macOS (BSD date):
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=kms.amazonaws.com \
  --start-time "$(date -v-10M +%Y-%m-%dT%H:%M:%S)" \
  --end-time "$(date +%Y-%m-%dT%H:%M:%S)"

# For Linux (GNU date):
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=kms.amazonaws.com \
  --start-time "$(date --date='10 minutes ago' +%Y-%m-%dT%H:%M:%S)" \
  --end-time "$(date +%Y-%m-%dT%H:%M:%S)"

For more information, see `Logging AWS KMS API calls with AWS
CloudTrail
<https://docs.aws.amazon.com/kms/latest/developerguide/logging-using-cloudtrail.html>`__
and `lookup-events CLI reference
<https://docs.aws.amazon.com/cli/latest/reference/cloudtrail/lookup-events.html>`__.

Step 5: Monitor cluster health

Continue monitoring your cluster for at least 30 minutes after the policy update:

• Watch cluster metrics and health indicators.
• Check for any encryption-related errors.
• Verify that automatic operations (like scaling) continue to work.

Recovery procedure if issues occur

If you encounter problems after updating the key policy:

1. Immediately restore the backup policy:

aws kms put-key-policy \
  --key-id <your-key-id> \
  --policy-name default \
  --policy file://key-policy-backup-YYYY-MM-DD.json

1. Monitor cluster recovery for up to 30 minutes.
2. Contact Confluent Support if the cluster doesn’t recover after restoring the original policy.

Common policy update scenarios

• Adding additional IAM users or roles: Always add new permissions rather than replacing existing ones.
• Updating Confluent account information: Contact Confluent Support first to get the correct new ARNs before updating.
• Enabling cross-account access: Add new principals to existing statements rather than creating separate statements.
• Implementing least-privilege access: Test thoroughly in non-production environments before applying to production keys.