Question

Difficulty: HardIAM Policies and Roles

A developer is implementing an AWS Lambda function in AWS Account 111111111111111111111111 (Account A) that must write messages to an Amazon SQS queue in AWS Account 222222222222222222222222 (Account B). The security team requires using temporary security credentials via IAM role assumption for cross-account access. The Lambda function is configured with an execution role named `LambdaExecutionRole` in Account A.

The developer attempts to set up an IAM role in Account B named `QueueWriterRole` with the following trust policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

Which of the following actions are required to successfully and securely establish this cross-account access? (Select TWO.)

  1. Modify the trust policy of `QueueWriterRole` in Account B to replace `lambda.amazonaws.com` with `"AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole"` in the `Principal` element.Answer
  2. Attach an identity-based policy to `LambdaExecutionRole` in Account A that allows the `sts:AssumeRole` action on the Amazon Resource Name (ARN) of `QueueWriterRole` in Account B.Answer
  3. C
    Modify the trust policy of `QueueWriterRole` in Account B to replace the `Action` value of `"sts:AssumeRole"` with `"sqs:SendMessage"`.
  4. D
    Attach a resource policy to the Amazon SQS queue in Account B that allows the service principal `lambda.amazonaws.com` to perform the `sts:AssumeRole` action.
  5. E
    Store the long-term Access Key ID and Secret Access Key of an IAM user from Account B in the Lambda environment variables, and use them to initialize the Amazon SQS client in the function code.

Answer

To establish cross-account access securely, the trust policy of the IAM role in the destination account must be updated to trust the source role's ARN, and the execution role in the source account must have an identity-based policy allowing it to perform the assume role action on the destination role.
Cross-account delegation requires configuration on both sides. First, the destination role's trust policy in Account B must define who is trusted to assume it. This is done by modifying the principal element to target the specific execution role ARN of the Lambda function. Second, the execution role in Account A must be granted permission to perform the `sts:AssumeRole` action on the destination role's ARN.

Step-by-Step Solution

1
Inspect the initial trust policy on the role in the destination account (Account B) and identify the principal misconfiguration.
The current trust policy uses the service principal `lambda.amazonaws.com`. This configuration only allows the AWS Lambda service within the same account to assume the role directly, not a specific role from a different AWS account.
Correcting the trust relationship is necessary because cross-account trust requires specifying the specific AWS account or IAM principal in the trust policy.
2
Modify the trust policy of the target role in Account B to trust the specific IAM role in Account A.
The `Principal` element is changed to `"AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole"`.
This establishes that the role in Account B trusts the execution role of the Lambda function in Account A.
3
Grant the execution role in Account A the permission to perform `sts:AssumeRole` on the target role in Account B.
An identity-based policy with the `sts:AssumeRole` action and the target role's ARN as the resource is attached to `LambdaExecutionRole` in Account A.
Even if the target role trusts the source role, the source role must explicitly be granted permission to perform the assume-role operation.

Key Concept

Cross-account IAM role delegation requires two-way permission configuration: a trust policy on the target role trusting the source principal, and an identity-based permission policy on the source principal allowing the assume-role action.
Rate this question