Question

Difficulty: HardAmazon ECS and Docker Deployment

An organization runs a containerized data processing application on an Amazon ECS cluster using the EC2 launch type. The application uses the AWS SDK to interact with an Amazon DynamoDB table. During a security audit, the security team notices that the application is accessing DynamoDB using the credentials of the container host's EC2 instance profile role, rather than the more restrictive IAM role designed specifically for the ECS task. Which configuration issue explains why the application is using the EC2 instance profile credentials?

  1. A
    The DynamoDB access permissions were attached to the ECS Task Execution Role instead of the ECS Task Role.
  2. The trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal.Answer
  3. C
    The AWS SDK inside the application code is configured to bypass the ECS task metadata endpoint and directly query the EC2 instance metadata service (IMDS) at 169.254.169.254.
  4. D
    The task definition container definition is missing a secrets parameter mapping the EC2 instance profile role to an environment variable in the container.

Answer

The trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal.
The correct answer is that the trust policy of the IAM role designed for the ECS task is configured to trust the ec2.amazonaws.com service principal instead of the ecs-tasks.amazonaws.com service principal. When a containerized application uses the AWS SDK, the default credential provider chain searches for task credentials injected by the ECS agent. If the task role's trust relationship is misconfigured to trust EC2 instead of ECS, the ECS agent cannot assume the role, leaving the container credential URI unconfigured. Consequently, the AWS SDK's default credential provider chain falls back to checking the host EC2 instance's metadata endpoint (IMDS) for credentials, which succeeds but uses the host's broader permissions instead of the task-specific permissions.

Step-by-Step Solution

1
Determine how the AWS SDK resolves credentials inside an ECS container.
The SDK checks the AWS default credential chain, which queries the ECS task metadata endpoint (via the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable) before falling back to the EC2 Instance Metadata Service (IMDS).
Understanding the credential resolution hierarchy is key to diagnosing why the SDK defaulted to the host's EC2 instance profile credentials.
2
Analyze why the task-specific credentials were not provided to the container.
The ECS container agent could not retrieve temporary credentials for the task because the IAM role assigned to the task did not permit the ECS tasks service principal (ecs-tasks.amazonaws.com) to assume it.
This identifies why the container credentials relative URI remained empty or was not resolved, prompting the SDK fallback behavior.
3
Identify the misconfiguration in the trust policy.
The IAM role's trust policy allowed the EC2 service principal (ec2.amazonaws.com) instead of the ECS tasks service principal (ecs-tasks.amazonaws.com) to assume the role.
This is a common configuration error where developers confuse the hosting environment (EC2) with the service executing the tasks (ECS).

Key Concept

ECS Task IAM Roles and Service Trust Policies
Rate this question