CloudFront, `"aws:PrincipalAccount"`, and `s3:GetObject`

[KevinHock]

Hi AWS Folks,

I currently see a bucket policy that has trusts an account ID of "cloudfront", similar to some public examples [1]

I wanted to ask: will the "aws:PrincipalAccount" condition key will be set to "cloudfront"? E.g., if your identity perimeter RCP were to be put in place.

(Or if I should instead rely on the "aws:PrincipalIsAWSService" check.)

[1]
Searcharn:aws:iam::cloudfront:user/ in https://aws.amazon.com/blogs/modernizing-with-aws/how-to-build-an-automated-c-code-documentation-generator-using-aws-devops/ and https://www.kevinslin.com/notes/f2542b0c-5cbd-49b9-84d8-151ccab99dea/

[liwadman]

Hey Kevin,

Just acking your issue. The team is mostly on-site at re:inforce and travelling this week and we will back with you shortly.

[KevinHock]

Hi Liam ❤ , thank you!

[liwadman]

Hey Kevin, sorry to keep you waiting. We had to do a little research and testing for this.

The short version is you would use aws:PrincipalArn with the value of the OAI to create a data perimeter exception for an OAI to access your S3 bucket.

I can understand this is not ideal, and for a better experience we would recommend migrating to the newer cloudfront primitive for this iff possible, the "Origin Access Control" (OAC): https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-cloudfront-introduces-origin-access-control-oac/

We've written this down in the writeup for the repo on this page: https://github.com/aws-samples/data-perimeter-policy-examples/tree/main/resource_control_policies .

Thank you for raising this issue!

[KevinHock]

No worries, thank you, Liam, and happy Friday! 😉