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

fix(elbv2): unable to deploy template with IPv4 load balancer when denyAllIgwTraffic set #29956

Merged
merged 6 commits into from
May 17, 2024

Conversation

Michae1CC
Copy link
Contributor

@Michae1CC Michae1CC commented Apr 25, 2024

Issue # (if applicable)

Closes #30247 .

Reason for this change

Integ test for NLB attributes (integ.nlb-attributes.ts) fails to deploy due to an error. The error occurs when denyAllIgwTraffic is explicitly set for load balancers with Ipv4 addressing, the ipv6.deny_all_igw_traffic attribute is set.

Description of changes

  • Remove the denyAllIgwTraffic setting from integ.nlb-attribute.ts
  • Instead, set denyAllIgwTraffic in integ.nlb.dualstack.internal.ts.
  • Raise an error during synthesis if denyAllIgwTraffic is set on a load balancer that does not use dual stack addressing.

Description of how you validated changes

  • Added new unit tests for different combinations of denyAllIgwTraffic and ipAddressType
  • Updated existing integration test

Checklist


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@github-actions github-actions bot added p2 beginning-contributor [Pilot] contributed between 0-2 PRs to the CDK labels Apr 25, 2024
@aws-cdk-automation aws-cdk-automation requested a review from a team April 25, 2024 01:56
@Michae1CC Michae1CC force-pushed the denyAllIgwTraffic-ipv4-lb-fix branch from 5e4292f to 89cc140 Compare April 25, 2024 01:57
Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

@Michae1CC Michae1CC changed the title Handle denyAllIgwTraffic for Ipv4 Load Balancers fix: handle denyAllIgwTraffic for Ipv4 Load Balancers Apr 25, 2024
@Michae1CC Michae1CC marked this pull request as draft April 25, 2024 02:07
@aws-cdk-automation aws-cdk-automation dismissed their stale review April 25, 2024 11:09

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

@Michae1CC Michae1CC force-pushed the denyAllIgwTraffic-ipv4-lb-fix branch from 14467eb to 291c665 Compare April 25, 2024 11:20
@Michae1CC Michae1CC marked this pull request as ready for review April 25, 2024 11:31
Copy link
Contributor

@nmussy nmussy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your change is affecting unrelated configurations, I would double check your condition and what you're expecting it do accomplish

I would also like to see additional unit tests, a combination of the following possibilities. I'm not sure what's the expected behavior for some of them, and coverage is always good:

  • denyAllIgwTraffic: undefined/denyAllIgwTraffic: false/denyAllIgwTraffic: true
  • ipAddressType: undefined/ipAddressType: IpAddressType.IPV4/ipAddressType: IpAddressType.DUALSTACK

Would you also be able to add additional integration tests to make sure that denyAllIgwTraffic: false and ipAddressType: IpAddressType.DUALSTACK is being deployed correctly?

@@ -488,6 +484,21 @@ describe('tests', () => {
}).toThrow('Load balancer name: "my load balancer" must contain only alphanumeric characters or hyphens.');
});

test('loadBalancerName unallowed: denyAllIgwTraffic set to false for Ipv4 adressing', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
test('loadBalancerName unallowed: denyAllIgwTraffic set to false for Ipv4 adressing', () => {
test('throw error for denyAllIgwTraffic set to false for Ipv4 adressing', () => {

@@ -250,7 +251,9 @@ export abstract class BaseLoadBalancer extends Resource {
this.setAttribute('load_balancing.cross_zone.enabled', baseProps.crossZoneEnabled === true ? 'true' : 'false');
}

if (baseProps.denyAllIgwTraffic !== undefined) {
if (additionalProps.ipAddressType === IpAddressType.IPV4 && baseProps.denyAllIgwTraffic === false) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ipAddressType is meant to be IpAddressType.IPV4 by default, and denyAllIgwTraffic is supposed to be false, I assume this condition is incorrect?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate the feedback! Apologies for the spiel

Yes, ipAddressType is meant to be IpAddressType.IPV4. As for denyAllIgwTraffic the docs mention "optional, default: false for internet-facing load balancers and true for internal load balancers". Looking at code though, denyAllIgwTraffic is never actually given a default value which is why we have this check for undefined here.

The denyAllIgwTraffic was created from this issue: #29520. Basically
denyAllIgwTraffic is supposed to set ipv6.deny_all_igw_traffic. However, having ipv6.deny_all_igw_traffic set (to either true or false) for any Ipv4 load balancer will cause a failed deployment. I'm starting to think the condition should actually be this:

Suggested change
if (additionalProps.ipAddressType === IpAddressType.IPV4 && baseProps.denyAllIgwTraffic === false) {
if (additionalProps.ipAddressType === IpAddressType.IPV4 && baseProps.denyAllIgwTraffic !== undefined) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at code though, denyAllIgwTraffic is never actually given a default value which is why we have this check for undefined here.

The CDK doesn't always set the default values, in fact most of the time CloudFormation does. This is the case here, although it's more complicated than just defaulted to false, see docs. The @default value needs to be updated to reflect this

Comment on lines -406 to -409
{
"Key": "ipv6.deny_all_igw_traffic",
"Value": "true"
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a scary change, I'm going to assume it's an unintended side effect. Given the integration was being deployed before your change, I assume the integ stack was being deployed successfully

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hehe, well that's the thing, I could not deploy the integration test before my change. The deployment failed with

Resource handler returned message: "Load balancer attribute key 'ipv6.deny_all_igw_traffic' is not supported on load balancers with IP address type 'ipv4'.

That's why I renamed the test to, in effect, remove the old test and replace with a template you can deploy (the name I use also aligns with the existing alb test). This particular integration test was added very recently. I can only think that who ever created it only synthesized the test and didn't try deploying.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@badmintoncryer Could we get some clarification on this? See #29521

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surely I haven't created a snapshot without deploying it...
I'll try it later. Please wait for a while.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nmussy @Michae1CC
I tried to deploy integ.nlb-attributes.ts but it cannot. I'm really sorry and I don't know how I could create snapshot files...

I have conducted deployment verification for internal ALBs and NLBs across several patterns.
The results are the same for both ALB and NLB.

ipAddressType denyAllIgwTraffic deployment result error message
IPV4 true failed Load balancer attribute key 'ipv6.deny_all_igw_traffic' is not supported on load balancers with IP address type 'ipv4'.
IPV4 false failed Load balancer attribute key 'ipv6.deny_all_igw_traffic' is not supported on load balancers with IP address type 'ipv4'.
DUAL_STACK true success
DUAL_STACK false failed Load balancer attribute key 'ipv6.deny_all_igw_traffic' cannot be modified for load balancers of type 'network'.

Based on these results, I propose the following amendments:

  1. If denyAllIgwTraffic is defined, return an error if ipAddressType is not DUAL_STACK.
  2. Revise the existing integ.nlb-attributes.ts to make it deployable:
  • Remove the denyAllIgwTraffic setting.
  • Instead, set denyAllIgwTraffic in integ.nlb.dualstack.internal.ts.

For item 2, it might be better to handle it as a separate issue.
If so, I will take responsibility for addressing it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Michae1CC My only suggestion is that the PR title should describe the content of the bug being resolved, rather than just mentioning the resolution of integration test errors.

Titles for feat and fix PRs end up in the change log. Think about what makes most sense for users reading the changelog while writing them.
- feat: describe the feature (not the action of creating the commit or PR, for example, avoid words like "added" or "changed")
- fix: describe the bug (not the solution)

Since I am unable to conduct community reviews, it would be best for the rest to be checked by @nmussy .

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, maybe something like integ test for NLB attributes failing to deploy due to setting denyAllIgwTraffic?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I apologize, I finally realized that this was actually a PR intended to resolve an integration test error. My English skills are limited and I made a significant misunderstanding. My suggestion to split the PR also made no sense. I'm sorry.

Without specifically mentioning the integration test, how about using the title:
'fix(elbv2): unable to deploy an IPv4 load balancer with denyAllIgwTraffic enabled'?
or considering it as the addition of a verification feature,
'feat(elbv2): verification of denyAllIgwTraffic for IPv4 Load Balancers'

However, I would appreciate it if you could consider nmussy opinion on this matter as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to apologize! And I agree, this PR's goal is not to fix an integration test, it's to prevent this pattern from being synthesized in the first place

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks both, updated the title

@nmussy
Copy link
Contributor

nmussy commented Apr 25, 2024

@Michae1CC I also left you a general comment in the review, in case you didn't see it: #29956 (review)

@Michae1CC
Copy link
Contributor Author

@Michae1CC I also left you a general comment in the review, in case you didn't see it: #29956 (review)

Yes, thanks again! I'll add more tests once we've aligned on the expected behaviour.

Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

This was referenced Apr 26, 2024
@aws-cdk-automation aws-cdk-automation dismissed their stale review April 27, 2024 00:29

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

@Michae1CC
Copy link
Contributor Author

Michae1CC commented Apr 27, 2024

Hey both, updated the integration tests and PR description. Let me know what you think.

@Michae1CC Michae1CC changed the title fix: handle denyAllIgwTraffic for Ipv4 Load Balancers fix: fail to deploy integ test for NLB attributes Apr 27, 2024
This was referenced Apr 29, 2024
@Michae1CC Michae1CC changed the title fix: fail to deploy integ test for NLB attributes fix(elbv2): unable to deploy template with IPv4 load balancer when denyAllIgwTraffic enabled May 1, 2024
@Michae1CC
Copy link
Contributor Author

Just curious as to what the new behavior will be post-PR?

This PR isn't changing much. The biggest change (in terms of functionality) will be that the deploy error you got will now occur during synthesis with a more descriptive message.

@Michae1CC
Copy link
Contributor Author

@moelasmar , let me know if anything else needs to change - thanks.

@moelasmar
Copy link
Contributor

thanks @Michae1CC for raising this PR and fix this issue. It looks good to me, I will create a github issue for this PR, and link it to this PR (just for tracking purposes). I need also to verify the integration test cases on my side before approving it.

@moelasmar moelasmar added the @aws-cdk/aws-elasticloadbalancingv2 Related to Amazon Elastic Load Balancing V2 label May 17, 2024
@github-actions github-actions bot added the bug This issue is a bug. label May 17, 2024
moelasmar
moelasmar previously approved these changes May 17, 2024
Copy link
Contributor

mergify bot commented May 17, 2024

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@aws-cdk-automation aws-cdk-automation removed the pr/needs-maintainer-review This PR needs a review from a Core Team Member label May 17, 2024
Copy link
Contributor

mergify bot commented May 17, 2024

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot dismissed moelasmar’s stale review May 17, 2024 01:48

Pull request has been modified.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: dc77a5c
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

Copy link
Contributor

mergify bot commented May 17, 2024

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@mergify mergify bot merged commit 42d424e into aws:main May 17, 2024
11 checks passed
atanaspam pushed a commit to atanaspam/aws-cdk that referenced this pull request Jun 3, 2024
…nyAllIgwTraffic set (aws#29956)

### Issue # (if applicable)

Closes aws#30247 .

### Reason for this change

Integ test for NLB attributes ([integ.nlb-attributes.ts](https://github.com/aws/aws-cdk/blob/4f1c94b27ef7f4ceccea0ff39625c0e8add31c9f/packages/%40aws-cdk-testing/framework-integ/test/aws-elasticloadbalancingv2/test/integ.nlb-attributes.ts)) fails to deploy due to an error. The error occurs when `denyAllIgwTraffic` is explicitly set for load balancers with Ipv4 addressing, the `ipv6.deny_all_igw_traffic` attribute is set.

### Description of changes

- Remove the denyAllIgwTraffic setting from integ.nlb-attribute.ts
- Instead, set denyAllIgwTraffic in integ.nlb.dualstack.internal.ts.
- Raise an error during synthesis if `denyAllIgwTraffic` is set on a load balancer that does not use dual stack addressing.

### Description of how you validated changes

- Added new unit tests for different combinations of `denyAllIgwTraffic` and `ipAddressType`
- Updated existing integration test

### Checklist
- [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)

----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@aws-cdk-automation
Copy link
Collaborator

Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one.

@aws aws locked as resolved and limited conversation to collaborators Jul 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
@aws-cdk/aws-elasticloadbalancingv2 Related to Amazon Elastic Load Balancing V2 beginning-contributor [Pilot] contributed between 0-2 PRs to the CDK bug This issue is a bug. p2
Projects
None yet
6 participants