Description
SQS server-side encryption protects stored message bodies. It supports SSE-SQS with SQS-managed keys and SSE-KMS with AWS KMS, so an absent kmsMasterKeyId does not establish that messages are stored in plaintext. New queues have server-side encryption enabled by default, but verify the actual queue settings.
Specify an appropriate KMS key when your organization requires customer-managed key policies and key-use auditing. Encryption at rest does not replace queue access controls or TLS in transit.
Potential impact
- If encryption is actually disabled, new message bodies lack this encryption-at-rest protection.
- Missing required key-management controls may leave organizational data-protection requirements unmet.
Remediation
- Check the queue's actual encryption mode and choose SSE-SQS or SSE-KMS according to requirements. For SSE-KMS, set
kmsMasterKeyIdto an available KMS key in the same Region. - Configure the necessary key permissions for producers, consumers and integrated services, then test sending and receiving messages.
- Review existing messages and dead-letter queues too. Enabling encryption does not automatically encrypt unencrypted messages already in the backlog.
Examples
These partial examples compare encryption settings. Replace the example KMS ARN with an actual key ARN in the queue's Region and configure the required key policy separately.
Before
apiVersion: sqs.aws.crossplane.io/v1beta1
kind: Queue
spec:
forProvider:
region: us-east-1
delaySeconds: 4
No KMS key is specified. Check the effective encryption settings, including SSE-SQS; this definition alone does not imply plaintext storage.
After
apiVersion: sqs.aws.crossplane.io/v1beta1
kind: Queue
spec:
forProvider:
region: us-east-1
kmsMasterKeyId: arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012
delaySeconds: 4
A KMS key is explicitly selected for SSE-KMS. Verify key permissions and actual message sending and receiving.