- Newest
- Most votes
- Most comments
For the second policy, there would be an implicit deny, but I'm pretty sure the issue is it's merged with the IAM Permissions Policy I use to grant our IAM user access to the bucket, so once the allow there is matched it does not reach the deny when no IP or VPC is allowed in the bucket policy.
Putting the IP and VPC rules into the IAM Permissions Policy would make it very messy, so I think a deny for networks in the bucket policy is the only option.
Having two "not if exists" for different context keys in the one condition seems pretty bad for readability to me, but I believe the logic is always an implict and when different contexts are in a condition. Is there any way I could reformat this condition or the policy to make it easier for any of my colleagues who have to work on it later?
For the second policy you mentioned, there is allow access for a particular IP and VPC but there isn't a deny for the other IPs. Could that be the issue?
I think you may already know about this link. https://awspolicygen.s3.amazonaws.com/policygen.html. Experiment with this to see if you can restrict access without giving deny.
I think deny is probably the best way to restrict access because the condition matches all ips except the IP you specified and hence that ip is allowed to have access.
I have researched a bit on this. Check if this link helps. https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#vpc-endpoints-policies-s3. Please ignore if you already know this. Hope it helps.
Relevant content
- asked 2 years ago
- AWS OFFICIALUpdated 9 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
I completely agree with you about the readability aspect but deny is what we are left with. I can't think of an alternative. I am waiting for any expert who can make things easier here!