Manage Key Policies on Confluent Cloud for AWS

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

Key Management Service (KMS) keys belong to the AWS account in which they are created. The IAM user who creates a KMS key is not automatically the key owner and does not automatically have permission to use or manage the KMS key. 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.

Update an AWS KMS key policy

Avoid key policy updates

Because key policy misconfigurations can cause immediate cluster unavailability and service disruption, it is recommended that you avoid updates.

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

Policy update recommendations

Add new permissions rather than replacing existing ones.
Contact Confluent Support first to get the correct new ARNs before updating.
Add new principals to existing statements rather than creating separate statements.
Test thoroughly in non-production environments before applying to production keys.

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

Procedure

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.
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.
During your planned maintenance window, apply the policy update:
Using the AWS CLI (recommended)
Run this command in the AWS CLI:
aws kms put-key-policy \ --key-id <your-key-id> \ --policy-name default \ --policy file://updated-policy.json
Using the AWS Console
To update the policy using the AWS KMS console, follow these steps. Ensure you don’t remove any Confluent-required permissions during the update.

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.

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 and lookup-events CLI reference.

Monitor 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.

Troubleshoot AWS key policy updates

Follow these steps if you encounter problems after updating the key policy.

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

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

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.

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

{
  "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": "*"
}