Cannot Access S3 Access Point Cross-Account with Role

0

I am trying to set up cross-account access with a role from Account A (one with role to assume) to Account B (one with S3 bucket and access point). I can access both the bucket and the access point cross-account with a user. I can access the bucket cross-account with a role, but I cannot access the S3 access point cross-account with a role. I have reconfirmed the policies many times and even tried to explicitly grant the role access instead of delegating access to Account A to provide that access (which works for the S3 Bucket, but not for the S3 Access Point. I think this is a bug.

Here is the AssumeRole trust policy which I know works cause I can assume it and access the bucket with it:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::***AccountA***:user/user.name"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Here is the Access Point policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::***AccountA***:role/TestRole",
                    "arn:aws:iam::***AccountA***:root",
                    "arn:aws:sts::***AccountA***:assumed-role/TestRole/session-testrole"
                ]
            },
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:us-west-2:***AccountB***:accesspoint/monitoring/object/error-reports/*",
                "arn:aws:s3:us-west-2:***AccountB***:accesspoint/monitoring/object/health-checks/*"
            ]
        }
    ]
}

For the bucket, I only need the Principal of "arn:aws:iam::***AccountA***:root" but I am showing it with the additional principals cause it still doesn't work.

Here is the bucket policy which again works fine if accessing cross-account with a user instead of a role (I would not have such an open policy normally, but opened it up more for testing):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccess",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::testaccesspoint***/*",
            "Condition": {
                "StringEquals": {
                    "s3:DataAccessPointAccount": "***AccountB***"
                }
            }
        }
    ]
}

Here is the Access Denied message in CloudTrail (bucket access succeeds to a similarly configured bucket, it is only the access point that fails and only for cross-account roles and not for users):

{
  "eventVersion": "1.09",
  "userIdentity": {
    "type": "AWSAccount",
    "principalId": "AROA*****34RK2I:session-testrole",
    "accountId": "***AccountA***"
  },
  "eventTime": "2023-10-27T08:40:40Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "GetObject",
  "awsRegion": "us-west-2",
  "sourceIPAddress": "##.##.##.##",
  "userAgent": "[aws-cli/1.29.62 md/Botocore#1.31.62 ua/2.0 os/linux#5.15.90.1-microsoft-standard-WSL2 md/arch#x86_64 lang/python#3.8.10 md/pyimpl#CPython cfg/retry-mode#legacy botocore/1.31.62]",
  "errorCode": "AccessDenied",
  "errorMessage": "Access Denied",
  "requestParameters": {
    "bucketName": "testaccesspoint***",
    "Host": "monitoring-x74pp1mjp***m3gusw2a-s3alias.s3.us-west-2.amazonaws.com",
    "key": "health-checks/1_1643823007.json"
  },
  "responseElements": null,
  "additionalEventData": {
    "SignatureVersion": "SigV4",
    "CipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
    "bytesTransferredIn": 0,
    "AuthenticationMethod": "AuthHeader",
    "x-amz-id-2": "8/C7m9qpsbR+v0iomUgIK/Mq4DrfIJHqwRPzYCiAxYvwjIM1kXSJelGJ7gMiDkTEYAEWXYmYKCI=",
    "bytesTransferredOut": 243
  },
  "requestID": "NA6BK48D5197GEXT",
  "eventID": "98e32249-2c11-483b-ba5a-77372d3dea82",
  "readOnly": true,
  "resources": [
    {
      "type": "AWS::S3::Object",
      "ARN": "arn:aws:s3:::testaccesspoint***/health-checks/1_1643823007.json"
    },
    {
      "accountId": "***AccountB***",
      "type": "AWS::S3::Bucket",
      "ARN": "arn:aws:s3:::testaccesspoint***"
    },
    {
      "accountId": "***AccountB***",
      "type": "AWS::S3::AccessPoint",
      "ARN": "arn:aws:s3:us-west-2:***AccountB***:accesspoint/monitoring"
    }
  ],
  "eventType": "AwsApiCall",
  "managementEvent": false,
  "recipientAccountId": "***AccountB***",
  "sharedEventID": "bf1c2541-ec66-4fb7-9b0d-4ed03006f3e8",
  "eventCategory": "Data",
  "tlsDetails": {
    "tlsVersion": "TLSv1.2",
    "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
    "clientProvidedHostHeader": "monitoring-x74pp1mjp********m3gusw2a-s3alias.s3.us-west-2.amazonaws.com"
  }
}
  • What are the access permissions attached to the role? Are those different than what is attached to the IAM user?

  • No, they are the same or were the same, now they are even more permissive.

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Action": "s3:GetObject",
                "Effect": "Allow",
                "Resource": [
                    "arn:aws:s3:us-west-2:***AccountB***:accesspoint/*",
                    "arn:aws:s3:us-west-2:***AccountB***:accesspoint/monitoring/*",
                    "arn:aws:s3:us-west-2:***AccountB***:accesspoint/monitoring/object/*"
                ],
                "Sid": ""
            }
        ]
    }
    

    Before it was just arn:aws:s3:us-west-2:***AccountB***:accesspoint/*. Policy works fine for user, but not for role when using an access point.

2 Answers
1

Hello, I hope you are well. If I have understood well, apparently your question is the same addressed on following link:

https://repost.aws/knowledge-center/cross-account-access-s3

Please, let me know in case this is accurate to your question or if you already have read the content shared.

Regards.

profile pictureAWS
answered 6 months ago
  • This is not the answer to my question. In my question I explained that I can get cross-account access working with a user and a role for an S3 bucket. This is what is addressed in the article you reference and I can get that working no problem. The issue is specifically with S3 Access Points (not the bucket). I can connect to them cross-account with a user, but not with a role.

0

Hello,

Greeting from AWS!

I understand that you are receiving Access denied error while attempting to access cross account s3 bucket through access points using an IAM role.

To begin with, I have replicated this issue in my lab environment with the below policies and I was able to make a successful request:

Account A:

Account A IAM user policy:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
         "Action": "sts:AssumeRole",
         "Resource": "arn:aws:iam::ACCOUNT-B:role/RoleName”
    }
}

Note: Here, please replace the IAM ARN with your Account B role ARN.

========================================

Account B:

Account B IAM role Trust policy:

{
	"Version": "2012-10-17",
	"Statement": [
	{
		"Effect": "Allow",
		"Principal": {
			"AWS": "arn:aws:iam::ACCOUNTA-ID:root"
		},
		"Action": "sts:AssumeRole",
		"Condition": {}
	}
]
}

——————

Account B IAM Role Policy:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Action": "s3:ListAllMyBuckets",
        "Resource": "*"
    },
    {
        "Effect": "Allow",
        "Action": [
            "s3:ListBucket",
            "s3:GetBucketLocation"
        ],
        "Resource": "arn:aws:s3:::BucketName”
    },
    {
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
            "s3:PutObject",
            "s3:DeleteObject"
        ],
        "Resource": "arn:aws:s3:::BucketName/*”
    }
]
}

————————

S3 Bucket Policy:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Principal": {
            "AWS": "*"
        },
        "Action": "s3:GetObject",
        "Resource": [
            "arn:aws:s3:::BucketName",
            "arn:aws:s3:::BucketName/*"
        ],
        "Condition": {
            "StringEquals": {
                "s3:DataAccessPointAccount": "123456789012"
            }
        }
    }
]
}

———————

Access Point policy:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::123456789012:role/RoleName”
        },
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:us-east-1:123456789012:accesspoint/my-access-point/object/*"
    }
]
}

[+] https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points-usage-examples.html#get-object-ap
[+] https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points-policies.html
[+] Assume Role - https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html#switch-cli-tutorial_cross-account-with-roles

That said, if incase the issue still persists, I request you to open a support case for further troubleshooting.

AWS
SUPPORT ENGINEER
Sania_K
answered 6 months ago
  • Sania,

    Thanks for your reply, but this is a workaround to my issue. I already have numerous workarounds. What I would like is for AWS to acknowledge that this is a bug and that it is on a backlog somewhere to be fixed. If I have an EC2 Instance, Lambda function, or SSO user, they should not have to assume a role in another account to access a bucket cross-account. This is confirmed by the fact that it works with a user and not with a role and with a bucket, but not with an access point. It would be tedious to have to re-program my applications or teach my SSO users to assume a role in Account B just to access an access point there. The better workaround would be to create an access point in account A they could use, but this is still just a workaround. I have already submitted a support case, but they are telling me they cannot investigate since they don't have access to both accounts. I have told them to give me a user or role ARN and I will set up policy to allow them to access the access point so they can troubleshoot. I have not heard back yet. If you can replicate this on your end (the failure and not the workaround), it would be helpful if you could provide those details to support. I would send you the case number if I saw a way to message your privately.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions