StringEquals sourceVpc not working for S3 policy - amazon-web-services

Question

I have this policy rule in my S3 bucket called aws-coes:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AddPerm",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::aws-coes/*"
],
"Condition": {
"StringEquals": {
"aws:sourceVpc": "vpc-foo"
}
}
}
]
}
I was expecting that only the machines under my VPC "vpc-foo" could get the resources from my bucket, but no machine can get anything.
Did I do something wrong here?
Also I follow the steps of this post but nothing https://blog.adminfactory.net/allow-access-to-s3-bucket-only-from-ec2-instances.html

Answer 1

I once had a similar issue. The following comes into my mind:
The policy looks good. The s3:GetObject action does not need to reference the bucket as resource. A wildcard path pointing at objects is sufficient. The policy examples [1] in the docs clearly state that fact.
You must use the vpc id as value for the aws:sourceVpc condition. Just mentioning it to make sure that you are not using the VPC ARN accidentally. [2]
What is also interesting, is that people most likely use the aws:sourceVpc condition to restrict access (i.e. a deny policy) - not to whitelist traffic. This is most likely not a functional issue, but I want to mention it nonetheless. From a security perspective it is probably safer to restrict access to the S3 bucket (as described in the aws docs) and attaching an EC2 instance role which grants access to the S3 bucket. This way, all EC2 instances within a particular VPC are able to access an S3 bucket, but other (possibly malicious) network entities are not.
I would double check if the requests from your EC2 instance are really routed through the VPC endpoint. As mentioned by the docs [3], it is crucial for the traffic to originate from an AWS VPC endpoint. This is accomplished inside the VPC by routing the traffic over a dedicated route inside the AWS network instead of the Internet Gateway. Could you please double check that you added the VPC endpoint to your route table correctly? One way you could check this is to make a public S3 bucket and access it from the EC2 instance. Subsequently, attach a vpc endpoint policy which denies all S3 traffic. Then, try to access the S3 bucket from your EC2 instance again. If the second time, access is denied, you know that probably the VPC endpoint is used and traffic is routed correctly inside the VPC.
Depending on the size of your organization there might be other IAM controls in place which deny the access. This is probably not an issue, but it might be worth checking if your company uses AWS Organizations and has an SCP which denies access. Also check, if there is no explizit deny, e.g. for your EC2 instance role. Take a look at the IAM evaluation logic [4] for more information.
You did not mention in your question if you are using one single AWS account or if you are in a multi-account scenario, e.g. an S3 bucket in account A and a VPC in account B. Iff this is the case, please check out the docs in [5], since it changes the policy evaluation logic when context authority and bucket owner differ. Using the aws:sourceVpc condition cross-account is probably not even possible. [6]
I hope some of these points are helpful to track the issue down.
References
[1] https://docs.aws.amazon.com/AmazonS3/latest/dev/example-policies-s3.html#iam-policy-ex0
[2] https://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies-vpc-endpoint.html#example-bucket-policies-restrict-access-vpc
[3] https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpc
[4] https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow
[5] https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-auth-workflow-object-operation.html
[6] https://stackoverflow.com/a/52517646/10473469

Answer 2

FYI, internally in the EC2-->S3 networking stack there are certain edge cases where the SourceVPC header is not passed on requests to S3, in those cases you'll need to use a VPC endpoint condition instead.
Source (I used to do a lot of S3 support at AWS).