Skip to content
Ask AI about this
Help improve this page

Kinesis streams should have server side encryption enabled

Kinesis streams often carry sensitive real-time data: clickstreams, financial transactions, IoT telemetry, application logs. Without SSE, those records sit unencrypted on the underlying storage shards. Any compromise at that layer exposes plaintext. The performance overhead is low; KMS key usage incurs charges at scale, and compliance frameworks that cover cloud storage expect encryption at rest for sensitive streaming data.

Retrofit consideration

Enabling SSE on an existing stream is an in-place operation via StartStreamEncryption, but the KMS key policy must already grant kinesis.amazonaws.com kms:GenerateDataKey and kms:Decrypt before you enable it, or records will fail to encrypt immediately.

Implementation

Choose the approach that matches how you manage Terraform.

Use AWS provider resources directly. See docs for the resources involved: aws_kinesis_stream.

resource "aws_kinesis_stream" "this" {
  kms_key_id       = "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012"
  name             = "pofix-abc123"
  retention_period = 168
  shard_count      = 1

  encryption_type = "KMS"
}

What this control checks

On the aws_kinesis_stream resource, encryption_type must be set to "KMS". Setting it to "NONE" or omitting it fails the control; the provider default is no encryption. When encryption_type is "KMS", kms_key_id must also be provided. Accepted values include a KMS key ID, key ARN, alias name, or alias ARN. Using alias/aws/kinesis selects the AWS-managed key for Kinesis, which passes the control but gives you no control over key rotation or cross-account key policies. A customer-managed key (CMK) is preferred for tighter governance. The KMS key must exist in the same region as the stream, and its key policy must allow the Kinesis service principal to call kms:GenerateDataKey and kms:Decrypt.

Common pitfalls

  • AWS-managed key limits cross-account access

    Setting kms_key_id to alias/aws/kinesis passes the control, but AWS-managed key policy constraints can block some cross-account access patterns. Consumers in another account may get access denied errors. Use a customer-managed CMK with an explicit key policy instead.

  • KMS key policy missing Kinesis service principal

    When using a CMK, the key policy must grant kms:GenerateDataKey and kms:Decrypt to kinesis.amazonaws.com. Without this, the aws_kinesis_stream resource will apply cleanly but the stream will silently fail to encrypt or decrypt records at runtime, producing KMSAccessDeniedException errors.

  • Terraform import of unencrypted streams keeps default

    Get this wrong and you won't know the stream is unencrypted after import. If you import an existing unencrypted stream and your configuration omits encryption_type, Terraform sees no drift because NONE matches the provider default. Set encryption_type = "KMS" explicitly before or immediately after import.

  • On-demand vs provisioned mode does not affect SSE

    Both ON_DEMAND and PROVISIONED capacity modes support SSE, but some teams assume on-demand streams are encrypted by default. They're not. Set encryption_type explicitly regardless of stream_mode_details.

Audit evidence

An auditor will look for Config rule results from kinesis-stream-encrypted showing all evaluated streams as COMPLIANT. Supplementary evidence includes aws kinesis describe-stream --stream-name <name> output: EncryptionType should show KMS and KeyId should reference a valid KMS key ARN. If a customer-managed key is in use, the auditor may also request the KMS key policy to verify that only authorized principals can decrypt stream data.

For continuous compliance, Security Hub findings or a CSPM tool export showing no failures for this control over the audit period works as point-in-time evidence.

Framework-specific interpretation

PCI DSS v4.0: Requirement 3.5 mandates that PANs are rendered unreadable wherever they're stored. If Kinesis streams carry cardholder data, SSE with KMS covers the encryption-at-rest piece. Key management practices for the CMK, including rotation and access controls, map to Requirements 3.6 and 3.7.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: kinesis_stream_server_side_encryption_enabled

  • AWS Config Managed Rule: KINESIS_STREAM_ENCRYPTED

  • Checkov Check: CKV_AWS_43

  • Powerpipe Control: aws_compliance.control.kinesis_stream_server_side_encryption_enabled

  • Prowler Check: kinesis_stream_encrypted_at_rest

  • AWS Security Hub Control: Kinesis.1

  • KICS Query: 862fe4bf-3eec-4767-a517-40f378886b88

  • Trivy Check: AWS-0064

Last reviewed: 2026-03-09