Question

Difficulty: HardSecrets Management and Parameter Store

An enterprise manages its application secrets in a dedicated security AWS account (Account A). A containerized microservice deployed on Amazon ECS Fargate in a production AWS account (Account B) needs access to a third-party payment provider's API key. This API key must be automatically rotated every 30 days using a custom rotation lifecycle, and the microservice must retrieve the plaintext key at runtime via the AWS SDK. Which configuration should the developer implement to meet these requirements securely?

  1. Store the API key in AWS Secrets Manager in Account A. Attach a resource-based policy to the secret that grants retrieve permissions to the ECS Task Role in Account B. Configure AWS Secrets Manager to automatically rotate the secret every 30 days using a custom AWS Lambda function in Account A.Answer
  2. B
    Store the API key as a SecureString parameter in Systems Manager Parameter Store in Account A. Attach a resource-based policy to the parameter that grants read permissions to the ECS Task Role in Account B, and configure Systems Manager to perform automatic rotation using a custom AWS Lambda function.
  3. C
    Store the API key in AWS Secrets Manager in Account A. Attach a resource-based policy to the secret that grants retrieve permissions to the ECS Task Execution Role in Account B. Configure AWS Secrets Manager to automatically rotate the secret every 30 days using a custom AWS Lambda function in Account A.
  4. D
    Store the API key in Systems Manager Parameter Store as a SecureString parameter in Account B. Hardcode the AWS Access Key ID and Secret Access Key of an IAM user from Account A in the Fargate container environment variables, and configure a cron job within the container to rotate the parameter.

Answer

Store the API key in AWS Secrets Manager in Account A, allow access to the ECS Task Role in Account B using a resource-based policy, and configure automatic rotation using an AWS Lambda function in Account A.
The correct solution stores the API key in AWS Secrets Manager in Account A because it natively supports resource-based policies for direct cross-account access and provides automatic rotation using AWS Lambda. The permissions must be granted to the ECS Task Role in Account B since the application retrieves the secret at runtime using the AWS SDK.

Step-by-Step Solution

1
Determine the service to use for secret storage and rotation.
AWS Secrets Manager is selected because it natively supports automatic rotation via custom Lambda functions and allows resource-based policies for simple cross-account access.
Systems Manager Parameter Store does not support resource-based policies or built-in automatic rotation.
2
Select the correct IAM role for the Fargate task.
The ECS Task Role is selected.
The application code retrieves the secret at runtime using the AWS SDK, which relies on permissions associated with the Task Role. The Task Execution Role is only used by the container agent during container startup.
3
Configure the cross-account access policy.
A resource-based IAM policy is attached to the secret in Account A, granting 'secretsmanager:GetSecretValue' permissions to the ECS Task Role ARN in Account B.
This configuration allows the Task Role in Account B to directly fetch the secret from Account A without assuming another role.
4
Set up the rotation window and target.
A custom Lambda function in Account A is linked to the secret to handle the API key rotation lifecycle every 30 days.
AWS Secrets Manager handles the scheduling and triggers the Lambda function to coordinate the secret update with the third-party provider.

Key Concept

Distinguishing between AWS Secrets Manager and Systems Manager Parameter Store for secret rotation and cross-account access, while correctly applying ECS Task Roles for runtime application permissions.
Rate this question