Skip to content
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

Closed
1 task done
t0gre opened this issue Mar 31, 2020 · 8 comments · Fixed by #22279
Closed
1 task done

allowAllOutbound on autoscaling groups should include ipv6 #7094

t0gre opened this issue Mar 31, 2020 · 8 comments · Fixed by #22279
Labels
@aws-cdk/aws-ec2 Related to Amazon Elastic Compute Cloud breaking-change This issue requires a breaking change to remediate. effort/small Small work item – less than a day of effort feature-request A feature should be added or improved. p1

Comments

@t0gre
Copy link

t0gre commented Mar 31, 2020

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 may be able to implement this feature request

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

@t0gre t0gre added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Mar 31, 2020
@SomayaB SomayaB added the @aws-cdk/aws-autoscaling Related to Amazon EC2 Auto Scaling label Mar 31, 2020
@NetaNir
Copy link
Contributor

NetaNir commented Apr 19, 2020

@tomgreenwood1 sounds reasonable, want to pick it up? I'll happy to review!

@NetaNir NetaNir added effort/small Small work item – less than a day of effort and removed feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Apr 19, 2020
@t0gre
Copy link
Author

t0gre commented May 6, 2020

I've started a pull request here #7827 the only thing is it's failing because I haven't written a test.. Not sure what an appropriate test for this would be tbh, but then testing isn't my strong point @NetaNir do you have any suggestions?

@SomayaB SomayaB added the in-progress This issue is being actively worked on. label May 11, 2020
@SomayaB SomayaB added the feature-request A feature should be added or improved. label Jun 22, 2020
@NetaNir
Copy link
Contributor

NetaNir commented Jul 1, 2020

H @tomgreenwood1 !

Thank you for submitting the PR, I have added a comment about possible tests.

@tomeldar
Copy link

tomeldar commented Jun 3, 2021

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:
Cannot add an "all traffic" egress rule in this way; set allowAllOutbound=true on the SecurityGroup instead.

If I set allowAllOutbound to true, then trying to add an IPV6 egress is ignored. I get the following warning:
Ignoring Egress rule since 'allowAllOutbound' is set to true; To add customize rules, set allowAllOutbound=false on the SecurityGroup

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,
Tom

@NetaNir
Copy link
Contributor

NetaNir commented Jun 3, 2021

@tomeldar
Check this comment out: #9017 (comment)

If I recall correctly, since EC2 allows ipv4 traffic by default, you should be able to set allowAllOutbound=false and add the Ipv6 rule and that will give you Ipv4 and Ipv6.

Let me know if it works. In any case this is not an ideal customer experience we need to fix it

@tomeldar
Copy link

tomeldar commented Jun 3, 2021

@NetaNir
Unfortunately that does not work. The following code generates the following egress rule (with no IPV4 egress allowed):

const securityGroup = new ec2.SecurityGroup(this, 'SecurityGroup', {
  vpc,
  allowAllOutbound: false
});

securityGroup.addEgressRule(ec2.Peer.anyIpv6(), ec2.Port.allTraffic(), 'IPV6 Egress');

image

@NetaNir NetaNir added breaking-change This issue requires a breaking change to remediate. and removed in-progress This issue is being actively worked on. labels Jun 7, 2021
@NetaNir NetaNir removed their assignment Jun 21, 2021
@peterwoodworth peterwoodworth added @aws-cdk/aws-ec2 Related to Amazon Elastic Compute Cloud and removed @aws-cdk/aws-autoscaling Related to Amazon EC2 Auto Scaling labels Mar 14, 2022
@peterwoodworth
Copy link
Contributor

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"
      }
    ]);

@mergify mergify bot closed this as completed in #22279 Sep 29, 2022
mergify bot pushed a commit that referenced this issue Sep 29, 2022
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*
@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

arewa pushed a commit to arewa/aws-cdk that referenced this issue Oct 8, 2022
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*
homakk pushed a commit to homakk/aws-cdk that referenced this issue Dec 1, 2022
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*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-ec2 Related to Amazon Elastic Compute Cloud breaking-change This issue requires a breaking change to remediate. effort/small Small work item – less than a day of effort feature-request A feature should be added or improved. p1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants