I tried out ECS_NO_ENVIRONMENT_SECRETS since 191 AWS Config managed rules were added

Introduction

On July 9, 2026, 191 managed rules were added to AWS Config all at once.

https://aws.amazon.com/jp/about-aws/whats-new/2026/07/aws-config-additional-managed-rules/

The targets include more than 30 services such as ECS, Bedrock, RDS, and S3. Rules have been added to evaluate resource configurations from a security and compliance perspective.

In this article, we will enable ECS_NO_ENVIRONMENT_SECRETS from among the newly added rules and verify how ECS task definitions containing environment variables with specified key names are detected as NON_COMPLIANT. We will also pick up and introduce particularly useful rules from the 191 added.

Verification Details

Overview of the ECS_NO_ENVIRONMENT_SECRETS Rule

This rule checks whether container environment variable names in ECS task definitions match the key names specified in secretKeys. It does not analyze the actual values of environment variables to determine whether they are secrets.

https://docs.aws.amazon.com/config/latest/developerguide/ecs-no-environment-secrets.html

For the parameter secretKeys, specify the key names you want to detect, separated by commas. If the key name of an environment variable directly specified in the container definition of a task definition matches secretKeys, it becomes NON_COMPLIANT.

Verification Procedure

Enabling the Config Managed Rule

Create the rule with put-config-rule.

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "ecs-no-environment-secrets",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "ECS_NO_ENVIRONMENT_SECRETS"
  },
  "InputParameters": "{\"secretKeys\": \"AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY,DB_PASSWORD\"}",
  "Scope": {
    "ComplianceResourceTypes": ["AWS::ECS::TaskDefinition"]
  }
}'

Creating an ECS Task Definition That Becomes NON_COMPLIANT

Register a task definition that includes an environment variable named DB_PASSWORD, which is specified in secretKeys. Use a dummy string for the value for verification purposes.

aws ecs register-task-definition \
  --family config-rule-test-secrets \
  --network-mode awsvpc \
  --requires-compatibilities FARGATE \
  --cpu 256 --memory 512 \
  --container-definitions '[{
    "name": "app",
    "image": "nginx:latest",
    "memory": 256,
    "essential": true,
    "environment": [
      {"name": "DB_PASSWORD", "value": "dummy-password-for-config-test"},
      {"name": "APP_ENV", "value": "test"}
    ]
  }]'

Since DB_PASSWORD matches secretKeys, this task definition becomes NON_COMPLIANT.

Checking Evaluation Results

Retrieve NON_COMPLIANT resources using get-compliance-details-by-config-rule.

aws configservice get-compliance-details-by-config-rule \
  --config-rule-name ecs-no-environment-secrets \
  --compliance-types NON_COMPLIANT

{
    "EvaluationResults": [
        {
            "EvaluationResultIdentifier": {
                "EvaluationResultQualifier": {
                    "ConfigRuleName": "ecs-no-environment-secrets",
                    "ResourceType": "AWS::ECS::TaskDefinition",
                    "ResourceId": "config-rule-test-secrets",
                    "EvaluationMode": "DETECTIVE"
                },
                "OrderingTimestamp": "2026-07-10T13:11:55.328000+00:00"
            },
            "ComplianceType": "NON_COMPLIANT",
            "ResultRecordedTime": "2026-07-10T13:12:03.607000+00:00",
            "ConfigRuleInvokedTime": "2026-07-10T13:12:03.368000+00:00",
            "Annotation": "The following containers have secret key names defined in their environment variables: ['app']."
        }
    ]
}

config-rule-test-secrets was detected as NON_COMPLIANT. The task definition family name is used for ResourceId (not the ARN). The Annotation indicates which container is in violation — in this case, the container named app. In this verification environment, evaluation completed approximately 8 seconds after registering the task definition (when recording frequency is CONTINUOUS).

Introduction of Useful Rules

From the 191 rules, here are the ones the author found particularly useful, picked up by category.

Containers (ECS)

In environments using ECS, the following rules are helpful for basic security hygiene checks.

Storage & Data (S3 / RDS)

From a data protection perspective, rules are available to detect settings worth considering at creation time or settings to continuously verify.

Authentication & Authorization (IAM / Cognito / KMS)

Rules to detect misconfigurations in access control settings.

AI / ML (Amazon Bedrock / Bedrock AgentCore)

These are newly added rules for Amazon Bedrock and Bedrock AgentCore. Configuration items such as authentication, networking, and encryption can now be checked using built-in Config rules.

Logging & Auditing

Rules to verify the presence of log configurations. Useful for early detection of the risk of having no logs in the event of an incident.

The full list of rules can be found in the official documentation.

https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html

Summary

We enabled ECS_NO_ENVIRONMENT_SECRETS and confirmed that ECS task definitions containing environment variables with key names specified in secretKeys are detected as NON_COMPLIANT. Since this rule evaluates environment variable names rather than their values, you specify the key names you want to detect in secretKeys.

With the addition of 191 rules this time, the range of services and configuration items that can be checked with AWS Config managed rules has expanded. Rules have also been added for Amazon Bedrock / Bedrock AgentCore to verify configurations such as authentication, networking, and encryption.

In particular, for rules with a Configuration changes trigger, the target resource type must be included in the AWS Config recording targets. Be sure to check the target resource types and trigger types for the rules you want to use in advance.