Description
Without a customer managed KMS key, a Redshift cluster may not meet requirements for direct control over key policies and lifecycle. New provisioned clusters are encrypted by default today, so omitting KmsKeyId does not mean plaintext storage. Check existing clusters and snapshot restores separately.
Potential impact
The default key may not meet organizational key-access and audit requirements. Disabling or deleting a needed key can instead affect data access and recovery.
Remediation
When a customer managed key is required, set Encrypted: true and specify the actual key in KmsKeyId. Preserve the key permissions Redshift needs and assess the supported key-change process and service impact for existing clusters. Manage key permissions, rotation and deletion alongside backup retention requirements.
Examples
These cluster excerpts require a supported RedshiftNodeType, subnet group and any required key. Redshift manages the administrator password. The retained PubliclyAccessible: true setting and network access require separate review.
Before
Resources:
RedshiftCluster:
Type: AWS::Redshift::Cluster
Properties:
ClusterSubnetGroupName: !Ref RedshiftClusterSubnetGroup
DBName: analytics
MasterUsername: admin
ManageMasterPassword: true
PubliclyAccessible: true
NodeType: !Ref RedshiftNodeType
Port: 5439
No customer managed key is specified. Check whether current default encryption for a new cluster meets organizational requirements.
After
Resources:
RedshiftCluster:
Type: AWS::Redshift::Cluster
Properties:
ClusterSubnetGroupName: !Ref RedshiftClusterSubnetGroup
DBName: analytics
MasterUsername: admin
ManageMasterPassword: true
PubliclyAccessible: true
NodeType: !Ref RedshiftNodeType
Port: 5439
Encrypted: true
KmsKeyId: !Ref RedshiftKeyArn
Encryption with the specified KMS key is requested. Verify key permissions and the cluster’s actual configuration.