By using AWS re:Post, you agree to the Terms of Use
/Trying to share an S3 bucket across accounts using 'aws:PrincipalOrgPaths', how to debug?/

Trying to share an S3 bucket across accounts using 'aws:PrincipalOrgPaths', how to debug?


We have several AWS accounts, all arranged into a tree in Organizations:

o-ABCDEF / r-1234 / ou-XXXX / ou-YYYY / ou-ZZZZ / ou-<actual_accounts>

The intermediate X->Y->Z OUs are just there for, well, organizational purposes. The "actual accounts" correspond to projects and customers and stuff with a need for isolated resources, billing, yadda yadda.

There's also an "actual account" OU at the same level as the ZZZZ branch. This actual account (call it Central Account) is where we put a lot of our central internal resources: EKS running websites, S3 buckets holding gobs of data, etc.

In the interests of making new accounts a little easier to stand up (along with Account Factory out of the Control Tower service), we wanted to be able to have EC2 instances in the various "actual accounts" download some stuff from one of the S3 buckets in that Central Account. There's an example given in AWS documentation about using aws:PrincipalOrgPaths as a condition for a bucket policy, so following that example, I came up with

"Version": "2012-10-17",
"Statement": [
        "Sid": "meaningful human reminder goes here",
        "Effect": "Allow",
        "Principal": "*",
        "Action": [
            "s3:a_few_other_Get_and_List_entries but no Put or Delete"
        "Resource": [
        "Condition": {
            "ForAnyValue:StringLike": {
                "aws:PrincipalOrgPaths": [ "o-ABCDEF/r-1234/*/ou-ZZZZ/*" ]

That's the entire bucket policy. "Block all public access" is on. ACLs are disabled.

The path in Organizations does have an intermediate wildcard because the AWS documentation had explicitly mentioned it. I had originally written the intermediate OUs in there and it didn't make a difference. The trailing wildcard was always present. This SO question mentions that the PrincipalOrgPaths takes an array even when you're only listing a single entry, but that the AWS Console editor removes the square brackets in such cases. I've tried it with square brackets and one entry, as well as listing the same path multiple times just so that the square brackets would be preserved; made no difference.

Organizations has "Service control policies" enabled, and its FullAWSAccess (AWS managed policy) attached. I'm not entirely certain if that matters or not.

Trying to access s3://name-of-bucket/special-prefix/from an EC2 instance in one of the other accounts in the OU tree gives only Access Denied errors. I've turned on server logging for the bucket, and the log entries showing my test attempts give the bucket name, originating instance role, the 403 response, etc, but obviously don't mention what Organization OU is involved.

I'm not sure what's wrong with the policy, or if there's something else I need to change, or if there's a way to see what test S3 is applying that's failing instead of succeeding. This should be doable with just Organizations, right?

1 Answers

I don't see anything wrong syntactically, though I am dubious about the multiple wildcards. If you have not tried IAM policy simulator, then I suggest testing with that. You can include a resource policy to help you trouble shoot, see Also, although Amazon S3 bucket policies will take spaces in the Sid, I suggest camel case as a general habit because there are policy statements that won't except spaces in Sids.

answered 20 days ago
  • Thank you for answering! The multiple wildcards (actually, the entire syntax block) is based off this AWS blog post: Specifically, the section "Example: Grant S3 bucket access to all principals in an OU in your organization". Although they didn't mention the square bracket thing, so I've wondered if the rules have changed since that was posted...

    The actual SID uses underscores, but camel case is probably more conventional. I'll tweak that up next time I'm there. :-)

    And thank you for pointing us at the IAM policy simulator. Hadn't seen that before, I'll go fool around and see what happens with it. (I'd really love some kind of insight into which policies/rules get examined in what order -- Organizations, S3 buckets, IAM, etc -- to find out exactly what test is failing.)

  • Well, the IAM simulator shows green as long as I'm simulating a user/role with AdministratorAccess. :-( Listing the bucket's ARN for the S3 GetObject, ListBucket, etc actions, and checking the "include resource policy" checkbox, merely shows a "Cannot get the resource policy. Reason: The specified resource was not found" error. I've added GetBucketPolicy to the bucket policy, with no difference. (Trying to add a second statement to the policy's Statement array yields no syntax errors, but suddenly claims that I don't have PutBucketPolicy permissions and won't save the policy. I have administrator access, so...?)

    So everything works as long as it's done by an IAM admin, but the S3 bucket itself isn't taking effect. Simulating another user, or an EC2 instance policy, fails for that reason.

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