Examkin

Soru

Zorluk: Çok zorAWS Key Management Service (KMS) and Data Encryption

An application container runs on Amazon Elastic Container Service (Amazon ECS) in AWS Account B (444455556666444455556666). The application must send messages to an encrypted Amazon Simple Queue Service (Amazon SQS) queue in AWS Account A (111122223333111122223333). The SQS queue is encrypted using an AWS KMS customer managed key (CMK) also located in Account A. The queue policy in Account A is configured to allow the ECS task role from Account B to perform `sqs:SendMessage` actions.

To enable the encryption flow, an administrator attached an IAM policy to the ECS task execution role in Account B, permitting `kms:GenerateDataKey` and `kms:Decrypt` on the KMS key ARN in Account A. However, the ECS task container logs show `KMS.AccessDeniedException` errors when the application attempts to publish messages.

Which combination of actions will resolve this issue? (Select TWO.)

  1. In Account A, update the KMS key policy to grant the Account B root principal (`arn:aws:iam::444455556666:root`) permissions to perform `kms:GenerateDataKey` and `kms:Decrypt` actions.Cevap
  2. In Account B, attach the IAM policy containing the KMS permissions to the ECS task role instead of the ECS task execution role.Cevap
  3. C
    In Account A, modify the SQS queue policy to grant the SQS service principal (`sqs.amazonaws.com`) permissions to perform `kms:GenerateDataKey` and `kms:Decrypt` actions on the KMS key.
  4. D
    In Account B, update the ECS task definition to enable container credential propagation from the host EC2 instance profile.
  5. E
    In Account B, use the AWS CLI to create an AWS KMS grant that delegates `kms:GenerateDataKey` permissions from Account A's KMS key to the SQS queue.

Cevap

To resolve the issue, the KMS key policy in Account A must be updated to trust Account B's root principal, and the IAM policy in Account B must be attached to the ECS task role instead of the ECS task execution role.
For cross-account resource access using KMS, the resource-owning account (Account A) must delegate authorization to the caller's account (Account B) within the KMS key policy. This is achieved by adding Account B's root principal as an allowed entity for key usage. Furthermore, the application code inside the ECS container relies on the ECS task role for permissions, not the task execution role. Attaching the IAM policy to the task role gives the application container the necessary permissions to call KMS and SQS.

Adım Adım Çözüm

1
Identify the credential context of the application container.
The application container running inside the ECS task uses the ECS task role, not the task execution role (which is only used by the ECS container agent).
This determines that the KMS policy must be moved from the task execution role to the task role.
2
Reassign the IAM policy granting KMS actions to the ECS task role in Account B.
The task role now possesses the permissions to call KMS endpoints.
Allows the containerized application to request KMS actions.
3
Analyze cross-account KMS evaluation logic.
For an IAM role in Account B to access a KMS key in Account A, the key policy in Account A must explicitly trust Account B (either the specific role or the root principal of Account B).
Without this delegation in the resource policy, local IAM policies in Account B have no authority.
4
Modify the KMS key policy in Account A to trust Account B's root principal (`arn:aws:iam::444455556666:root`) for the `kms:GenerateDataKey` and `kms:Decrypt` actions.
The trust path is established, allowing local IAM policies in Account B to successfully authorize the ECS task role.
Completes the cross-account authorization chain.

Anahtar Kavram

Cross-account AWS KMS key access delegation and ECS IAM role distinction.
Bu soruyu puanla

Konular

AWS Key Management Service (KMS) and Data Encryption

Bu konudan daha fazla soru