---
title: Secrets Manager secret encrypted with AWS-managed key
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Datadog Security > Code Security > Infrastructure as Code (IaC)
  Security > IaC Security Rules > Secrets Manager secret encrypted with
  AWS-managed key
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Secrets Manager secret encrypted with AWS-managed key

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com, us2.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site.md). ({% placeholder "user-datadog-site-name" /%}).
{% /alert %}

{% /callout %}

## Metadata{% #metadata %}

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

**Provider:** AWS

**Platform:** Terraform

**Severity:** Medium

**Category:** Encryption

#### Learn More{% #learn-more %}

- [Provider Reference](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/secretsmanager_secret#kms_key_id)

### Description{% #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{% #compliant-code-examples %}

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

## Non-Compliant Code Examples{% #non-compliant-code-examples %}

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

```terraform
# 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
}
```