-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security Group for VPC Endpoint does not have any Ingress rules. #4937
Comments
The default rule created for VPC endpoints did not have any ingress rules meaning that the VPC endpoints were totally inaccessible. This made them completely useless. This commit add a default ingress rule that allows all IPv4 and IPv6 traffic to the port of the service. fixes aws#4937
I am sorry that it was not documented well enough that endpoints come without default security rules, and that it cost you a lot of time. I'm not sure I'd consider it a bug, but I'm open to changing this so that it works out of the box. |
@rix0rrr Thank you for considering this. Allowing ingress as I do #4938 I think would be the expected behavior. Most users will not need to lock down VPC Endpoints and those that do can define their own security group and pass to the VPC endpoint during creation. I don't agree with the addition of the Setting the connection as suggested is unnecessary and runs the risk of messing with a user specified security group. |
The default rule created for VPC endpoints did not have any ingress rules meaning that the VPC endpoints were totally inaccessible. This made them completely useless. This commit add a default ingress rule that allows all IPv4 and IPv6 traffic to the port of the service. fixes aws#4937
That all depends on what the endpoint/interface is being used for, if you’re seeking to allow calls into the VPC by something else, unprompted then you're correct. That is if you’re hosting a service within a VPC and want to allow calls into it, then you’re absolutely right that the default security group of no ingress, all egress is unusable. However, if all your interface/endpoint is used for is to call other AWS services, the default Security Group does work. Security Groups are stateful, see: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html#VPC_Security_Comparison?tag=affiliate-income-20 this means that even if ingress is disallowed, so long as the ingress is just return traffic, it’s automatically approved regardless of rules. This means should your endpoint be used to call out into S3 and the like, the return response will be allowed so long as egress traffic is allowed. So, the state of allowing ingress traffic all depends on what the endpoint is going to be used for. |
The default rule created for VPC endpoints did not have any ingress rules meaning that the VPC endpoints were totally inaccessible. This made them completely useless. Add `open` property to control security group ingress. Default is true which means allow all IPv4 and IPv6 traffic to the service port. fixes aws#4937
Automatically allow ingress to VPC endpoints by default, from traffic originating in the VPC. This fixes the 99% case where interface endpoints are used to allow ISOLATED instances to access AWS services, out of the box. People that need more control over the security policy rules can specify `open: false` to disable this behavior and use the `.connections` object for fine-grained access control. Fixes #4937
I lost almost 2 days trying to figure out why a VPC Endpoint for Secrets Manager I created was totally unreachable.
It turns out that the default security group created for the endpoint does not have any ingress rules. Making the vpce totally unless.
Reproduction Steps
Environment
Workaround
The workaround is to create the endpoint and then use:
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: