aws-samples / data-perimeter-policy-examples

Example policies demonstrating how to implement a data perimeter on AWS.
Other
114 stars 15 forks source link

Question about S3 access #15

Open mjubb opened 9 months ago

mjubb commented 9 months ago

Hi,

Apologies that this is more question than issue. In the VPC endpoint policies I can see that the policies allow AWS managed S3 buckets for operations (like patching/ssm/image builder) are explicitly allowed for GetObject actions. However, the SCP item EnforceResourcePerimeterAWSResourcesS3 looks like it does not allow AWS managed S3 buckets to be accessed without the resource-perimeter-exception tag being in place? Is this the case?

Or am I misunderstanding the EnforceResourcePerimeterAWSResourcesS3 SCP and it does allow access to AWS managed S3 buckets?

tatyatsk commented 9 months ago

Hello,

Thank you for posting the question!

Amazon S3 buckets that you mentioned are normally accessed using unauthenticated calls as these contain public data sets managed by AWS Services. Since requests to these buckets pass through your network, Amazon S3 VPC endpoint configured in your VPC need to allow the access (please see this Readme for more details). However, since SCPs apply only to your identities (e.g. IAM Roles), you don’t need to exclude this access pattern from your ResourceOrgId restriction in SCPs.

EnforceResourcePerimeterAWSResourcesS3 statement can be used to ensure that access is not denied to Amazon S3 resources owned by AWS services when those services use FAS to access them on your behalf. This access pattern applies when you access data via an AWS service and that service takes subsequent actions on your behalf by using your AWS Identity and Access Management (IAM) credentials. Two examples provided in the repo are AWS Data Exchange publishing and subscribing and AWS Service Catalog operations (please see this Readme for more details).

Please let us know if you have any additional questions.

mjubb commented 9 months ago

Thanks so much for the response, makes perfect sense that the AWS managed buckets are usually unauthenticated calls. That's helped my understanding a lot.

We've run into trouble with the arn:aws:s3:::ec2imagebuilder-managed-resources--prod/components/* bucket listed in the VPC endpoint policy. It's only worked for us if we add the "aws:PrincipalTag/resource-perimeter-exception": "true" exception to the instance profile/IAM role that is assigned to the EC2 Image Builder EC2. Otherwise we get a 403 exception when EC2 image builder components are pulled from the AWS managed bucket. Would prefer not to have to add an exemption but not sure what the best approach is.

Thanks again for your support, it's really appreciated!

Edit: I just realized it was your re:Inforce 2022 talk that was my intro to Data Perimeter - so double thanks!

tatyatsk commented 8 months ago

Hello,

Could you please confirm that the 403 error you are receiving is indeed for arn:aws:s3:::ec2imagebuilder-managed-resources--prod/components/*?

There are other reasons for why your operation might be failing:

  1. VPC endpoint for EC2 Image Builder also needs to allow access to AWS owned components. Please see imagebuilder_endpoint_policy.json
  2. If you implement ResourceOrgId restriction in your SCPs, then you will need an exception for AWS owned components there as well (this is not yet documented in the repo, pending internal review). Adding “aws:PrincipalTag/resource-perimeter-exception": "true" to the role is one option but it would mean that the role is excluded from ResourceOrgId for all actions, not only imagebuilder. Instead, you could list imagebuilder:GetComponent in NotAction of the "Sid":"EnforceResourcePerimeterAWSResources" in resource_perimeter_policy.json and then create another statement "Sid": "EnforceResourcePerimeterAWSResourcesImageBuilder" to Deny imagebuilder:GetComponent unless ResourceOrgId equals your organization id or the call is made by your specific role (using aws:PrincipalTag with a tag other than resource-perimeter-exception, aws:PrincipalArn, or aws:PrincipalAccount if you want to exclude the entire golden AMI build account). In this case, the role/s will be excluded from ResourceOrgId restriction for imagebuilder:GetComponent only. The solution will depend on your risk appetite.
  3. If you use AWS owned images to create image recipes, you would also need to exclude imagebuilder:GetImage on arn:aws:imagebuilder::aws:image/* in the VPC endpoint policy and SCP following the same approach as with imagebuilder:GetComponent.

We will update the repo with the above recommendation once our internal review process is complete.