Question

Difficulty: MediumIAM Policies, Roles, and Service Control Policies (SCPs)

A SysOps administrator is troubleshooting an issue where an IAM user in a member account is unable to access an Amazon S3 bucket located in a different AWS account. The IAM user has an identity-based policy that grants full S3 permissions (s3:*) to the external bucket. The bucket policy in the destination account explicitly allows access from the IAM user's ARN. However, when the user attempts to list the bucket contents, they receive an Access Denied error. The member account is located within an Organizational Unit (OU) in AWS Organizations. The organization's root has the default FullAWSAccess Service Control Policy (SCP) attached. The OU containing the member account has a custom SCP attached with the following policy document:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"dynamodb:*"
],
"Resource": "*"
}
]
}

What is the root cause of this Access Denied error?

  1. A
    The IAM user lacks the iam:PassRole permission, which is required to authorize the cross-account delegation of S3 permissions.
  2. B
    The member account's VPC has an S3 Gateway Endpoint that is not associated with the subnet's route table, which blocks all S3 API calls.
  3. The custom SCP attached to the OU does not explicitly allow S3 actions, resulting in an implicit deny for all S3 operations originating from the member account.Answer
  4. D
    The destination S3 bucket is encrypted with the default AWS managed key (aws/s3), and the IAM user has not been granted explicit KMS decrypt permissions in their identity-based policy.

Answer

The custom Service Control Policy (SCP) attached to the Organizational Unit (OU) does not explicitly allow S3 actions, resulting in an implicit deny for all S3 operations originating from the member account.
For an AWS Organizations member account, permissions are filtered by Service Control Policies (SCPs). Even if an identity-based policy and a resource-based policy explicitly allow an action, it will be blocked if it is not explicitly allowed by SCPs at every level of the hierarchy. The custom SCP at the OU level allows only EC2 and DynamoDB actions, thereby implicitly denying S3 actions for all principals in the member account.

Step-by-Step Solution

1
Verify the IAM user's identity-based policy and the destination S3 bucket policy.
Both policies allow S3 access, confirming that local and resource-level permissions are correct.
To rule out misconfigurations in the standard identity-based and resource-based policies.
2
Examine the Service Control Policies (SCPs) applied to the member account's OU.
The OU has a custom SCP that allows only ec2:* and dynamodb:* actions.
To verify if organizational boundaries are restricting permissions.
3
Determine the effective S3 permissions based on the SCP evaluation logic.
Because S3 is not explicitly allowed in the custom SCP at the OU level, it is implicitly denied for all principals in the member account.
SCPs define the maximum allowed permissions; if an action is not allowed by at least one SCP at each level, it is implicitly denied.

Key Concept

In AWS Organizations, Service Control Policies (SCPs) act as filters that define the maximum permissions for member accounts. For an action to be allowed, it must be explicitly allowed at every level of the Organization hierarchy (Root, OU, and Account). Any action not explicitly allowed is implicitly denied.
Rate this question