Question

Difficulty: Very hardIdentity and Access Management (IAM)

A company is designing a secure architecture to allow a third-party vendor's application, running in AWS Account B (222222222222222222222222), to write diagnostic logs to an Amazon S3 bucket in the company's AWS Account A (111111111111111111111111). The S3 bucket in Account A is encrypted using an AWS KMS customer managed key. The solution must ensure that the vendor cannot access other resources in Account A, does not use long-term AWS credentials, is protected against the confused deputy problem, and follows the principle of least privilege. Which TWO configurations must a solutions architect implement to meet these requirements?

  1. Create an IAM role in Account A with a trust policy that allows the principal `arn:aws:iam::222222222222:root` to perform `sts:AssumeRole`, and include a condition for `sts:ExternalId` matching a unique vendor-provided identifier.Answer
  2. Attach a permissions policy to the IAM role in Account A that grants `s3:PutObject` permissions on the S3 bucket and `kms:GenerateDataKey` permissions on the KMS key, and configure the KMS key policy to allow the IAM role to use the key.Answer
  3. C
    Create a dedicated IAM user in Account A, attach the required S3 and KMS permissions, and save the access keys as a String parameter type in Systems Manager Parameter Store for the vendor to retrieve.
  4. D
    Use the AWS account root user of Account A to generate a pre-signed S3 URL with an extended expiration, and configure the vendor application to upload diagnostic logs directly using this URL.
  5. E
    Modify the S3 bucket policy in Account A to allow write access directly to the vendor's IAM role, and rely on automatic KMS key rotation to automatically update key access permissions.

Answer

The solutions architect must create an IAM role in Account A that trusts Account B with an external ID condition, and attach a policy allowing write access to the S3 bucket and permission to generate data keys from the KMS key.
To secure cross-account access without long-term credentials, a solutions architect should configure the third party to assume an IAM role in the resource-owning account. Trusting the root principal of Account B allows IAM administrators in Account B to delegate this role to their local resources, while the external ID prevents the confused deputy vulnerability. The assumed role must also possess write permissions for S3 and permissions to generate data keys for the KMS customer managed key to perform SSE-KMS encryption.

Step-by-Step Solution

1
Establish the cross-account trust relationship.
An IAM role in Account A is created, allowing Account B to assume it under the condition that a specific external ID is supplied.
This eliminates the need for long-term credentials and addresses the confused deputy problem.
2
Configure permissions for writing encrypted S3 data.
The IAM role permissions policy is configured with S3 write access and KMS data key generation permissions.
Writing to a bucket encrypted with a customer managed KMS key requires both S3 and KMS permissions.
3
Update resource-based key policies.
The KMS key policy is updated to explicitly trust the IAM role in Account A.
KMS customer managed keys require explicit key policy permissions to allow IAM identities to execute cryptographic operations.

Key Concept

Implementing secure cross-account delegation using IAM roles, trust policies with external IDs, and resource permissions for KMS-encrypted S3 buckets.
Estimated Time:3m 0s
Rate this question