Secrets Manager secret encrypted with AWS-managed key

이 제품은 선택한 Datadog 사이트에서 지원되지 않습니다. ().
이 페이지는 아직 한국어로 제공되지 않습니다. 번역 작업 중입니다.
현재 번역 프로젝트에 대한 질문이나 피드백이 있으신 경우 언제든지 연락주시기 바랍니다.

Metadata

Id: terraform-aws-secretsmanager-secret-encrypted-with-aws-managed-key

Provider: AWS

Platform: Terraform

Severity: Medium

Category: Encryption

Learn More

Description

AWS Secrets Manager secrets should be encrypted with customer-managed KMS keys rather than the default AWS-managed keys. Relying on AWS managed keys limits an organization’s ability to control, rotate, and audit encryption keys, which are important factors in enforcing robust security policies and compliance requirements. Without customer-managed KMS keys, there may be a greater risk of unauthorized access or insufficient key lifecycle management. If left unaddressed, sensitive information stored in Secrets Manager could be compromised due to weaker or less transparent key management practices.

Compliant Code Examples

resource "aws_secretsmanager_secret" "test222" {
  name       = "test-cloudrail-1"
  kms_key_id = "alias/MyAlias"
}

Non-Compliant Code Examples

resource "aws_secretsmanager_secret" "test2" {
  name       = "test-cloudrail-1"
  kms_key_id = "alias/aws/secretsmanager"
}

# Known gap: when kms_key_id is set via a data source reference (e.g.
# data.aws_kms_key.by_alias.arn), the plan-JSON parser (which only reads
# planned_values.root_module) never resolves data-source attributes into
# resource.kms_key_id -- it comes through as null, and the alias name used
# to look up the data source (uses_aws_managed_key's `.data.aws_kms_key`
# branch) is never populated for plan-JSON documents at all (data sources
# only appear there, never under a `.data` key). There is no reliable
# signal to detect this case from plan-JSON alone, since even a resolved
# KMS key ARN doesn't encode which alias it came from. This file exercises
# the case via HCL (where it still works) but its plan-JSON equivalent,
# test/known_gap_data_source1.json, is deliberately not prefixed
# "positive"/"negative" so the test harness (which only asserts on
# positive*/negative* prefixed files) skips it -- it is kept only to
# document the limitation.
provider "aws" {
  region = "us-east-1"
}

data "aws_kms_key" "by_alias" {
  key_id = "alias/aws/secretsmanager"
}

resource "aws_secretsmanager_secret" "test" {
  name       = "test-cloudrail-1"
  kms_key_id = data.aws_kms_key.by_alias.arn
}