---
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
# kms_key_id is set via a data source reference (data.aws_kms_key.by_alias.arn)
# targeting the AWS-managed secretsmanager alias. On the HCL path this is
# evaluated directly via uses_aws_managed_key's data-source branch. See
# positive3.tf/json for the plan-JSON equivalent, where the resolved value is
# unavailable (data sources aren't resolvable offline) but the rule still
# detects it via _dd_tfplan_meta.configuration_expressions.
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
}
```

```terraform
# Plan-JSON counterpart of positive2.tf: kms_key_id is set via a data source
# reference (data.aws_kms_key.aws_managed.key_id) targeting the AWS-managed
# secretsmanager alias. positive3.json is a hand-built fixture representing
# the real `terraform show -json` shape for this configuration (data sources
# require a live provider call during `terraform plan`, so this exact plan
# can't be generated offline) -- the rule detects it via
# _dd_tfplan_meta.configuration_expressions.kms_key_id.references combined
# with configuration.root_module.data_resources, without needing the
# resolved key value at all.
provider "aws" {
  region = "us-east-1"
}

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

resource "aws_secretsmanager_secret" "test" {
  name       = "test-cloudrail-1"
  kms_key_id = data.aws_kms_key.aws_managed.key_id
}
```
