-
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
allowAllOutbound on autoscaling groups should include ipv6 #7094
Comments
@tomgreenwood1 sounds reasonable, want to pick it up? I'll happy to review! |
H @tomgreenwood1 ! Thank you for submitting the PR, I have added a comment about possible tests. |
Hi @NetaNir, I've ran into this issue and checked out the closed PR, seeing that it will be pushed to v2 of the CDK. I understand that changing the default will cause issues, but there is seemingly no workaround. If I set allowAllOutbound to false, I can only add IPV6 egress and not IPV4. I get prompted with the following error: If I set allowAllOutbound to true, then trying to add an IPV6 egress is ignored. I get the following warning: From what I've attempted and read, there is no way to add both IPV4 and IPV6 egress on all traffic. Please correct me if I am wrong. Is there any way to get this working with the CDK? Thank you, |
@tomeldar If I recall correctly, since EC2 allows ipv4 traffic by default, you should be able to set Let me know if it works. In any case this is not an ideal customer experience we need to fix it |
@NetaNir
|
Workaround with escape hatches: const sg = new SecurityGroup(this, 'SG', {
vpc: Vpc.fromLookup(this, 'TestVpc', { vpcName: 'TestVpc'}),
// allowAllOutbound: false
});
const cfnSg = sg.node.defaultChild as CfnSecurityGroup;
cfnSg.addPropertyOverride('SecurityGroupEgress',
[
{
"CidrIpv6": "::/0",
"Description": "from ::/0:ALL TRAFFIC",
"IpProtocol": "-1"
},
{
"CidrIp": "0.0.0.0/0",
"Description": "Allow all outbound traffic by default",
"IpProtocol": "-1"
}
]); |
This PR fixes an issue where it was impossible to add ipv6 egress rules without an escape hatch. The SecurityGroup construct will now track ipv6 and ipv4 separately. This matches the default behavior of CloudFormation and the underlying EC2 API. By default when you create a SecurityGroup (either via CFN or console) it will create an allow all ipv4 rule. If you later add a more specific rule CloudFormation will remove the ipv4 allow all rule. Since the default behavior is to _not_ add an allow all for ipv6, the SecurityGroup construct will also not add it by default. There is an edge case that this does break, but I'm not sure if it is a valid case. Previously it would have been possible to do the following (only allow all ipv6 outbound). But we don't want to allow that for the same reason we don't allow it for ipv4 (it will be overwritten by more restrictive rules). ```ts const sg = new SecurityGroup(this, 'Sg', { allowAllOutbound: false, }); sg.addEgressRule(Peer.anyIpv6(), Port.allTraffic()); ``` fixes #7094 ---- ### All Submissions: * [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
This PR fixes an issue where it was impossible to add ipv6 egress rules without an escape hatch. The SecurityGroup construct will now track ipv6 and ipv4 separately. This matches the default behavior of CloudFormation and the underlying EC2 API. By default when you create a SecurityGroup (either via CFN or console) it will create an allow all ipv4 rule. If you later add a more specific rule CloudFormation will remove the ipv4 allow all rule. Since the default behavior is to _not_ add an allow all for ipv6, the SecurityGroup construct will also not add it by default. There is an edge case that this does break, but I'm not sure if it is a valid case. Previously it would have been possible to do the following (only allow all ipv6 outbound). But we don't want to allow that for the same reason we don't allow it for ipv4 (it will be overwritten by more restrictive rules). ```ts const sg = new SecurityGroup(this, 'Sg', { allowAllOutbound: false, }); sg.addEgressRule(Peer.anyIpv6(), Port.allTraffic()); ``` fixes aws#7094 ---- ### All Submissions: * [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This PR fixes an issue where it was impossible to add ipv6 egress rules without an escape hatch. The SecurityGroup construct will now track ipv6 and ipv4 separately. This matches the default behavior of CloudFormation and the underlying EC2 API. By default when you create a SecurityGroup (either via CFN or console) it will create an allow all ipv4 rule. If you later add a more specific rule CloudFormation will remove the ipv4 allow all rule. Since the default behavior is to _not_ add an allow all for ipv6, the SecurityGroup construct will also not add it by default. There is an edge case that this does break, but I'm not sure if it is a valid case. Previously it would have been possible to do the following (only allow all ipv6 outbound). But we don't want to allow that for the same reason we don't allow it for ipv4 (it will be overwritten by more restrictive rules). ```ts const sg = new SecurityGroup(this, 'Sg', { allowAllOutbound: false, }); sg.addEgressRule(Peer.anyIpv6(), Port.allTraffic()); ``` fixes aws#7094 ---- ### All Submissions: * [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [ ] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
For autoscaling groups, a new security group is always created. There's a setting called allowAllOutbound, which configures that that security group to allow all ipv4 traffic out. However, it actually doesn't let ALL outbound traffic out, because it doesn't let ipv6 traffic out.
Use Case
I need to be able to ping things on ipv6 from inside ecs containers, which are run on an autoscaling group.
Proposed Solution
Add ::/0 to the list of allowed outbound connections for the allowAllOutbound.
Other
I'd be very happy to have a go at this if you can point me to which module it's configured in. Seems unlikely it would break anything.
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: