fix(eks-v2-alpha): use custom security group from kubectlProviderOptions

[jasdeepbhalla]

Issue # (if applicable)

Closes #36653.

Reason for this change

Despite specifying a securityGroup in kubectlProviderOptions, the EKS Cluster's security group was being applied to the Kubectl Handler (Lambda) instead of the intended custom security group. This prevented users from using custom security groups for the kubectl provider, which is important for network security configurations, especially when using private subnets and proxy configurations.

Description of changes

Changes made:

1. cluster.ts (line 1293): Added securityGroup: this._kubectlProviderOptions?.securityGroup to the KubectlProvider constructor call. This ensures the security group specified in kubectlProviderOptions is passed through to the KubectlProvider construct.

2. kubectl-provider.ts (lines 155-161): Updated the security groups logic to:

   • First check if props.securityGroup is provided and use it when available
   • Fall back to props.cluster.clusterSecurityGroup when no custom security group is specified
   • This maintains backward compatibility while fixing the bug

Why these changes address the issue:

The root cause was that the securityGroup property from kubectlProviderOptions was never being passed to the KubectlProvider constructor, and the provider always defaulted to using the cluster's security group. By explicitly passing the security group and updating the provider's logic to prefer the custom security group, we now respect the user's configuration.

Design decisions:

• Maintained backward compatibility: When no custom security group is provided, the behavior remains unchanged (uses cluster security group)
• The validation logic follows the pattern: custom security group takes precedence, then falls back to cluster security group
• Security groups are only applied when privateSubnets are specified, which is the expected behavior for VPC-enabled Lambda functions

Describe any new or updated permissions being added

No new or updated IAM permissions are required. This change only affects which security group is attached to the existing Kubectl Handler Lambda function. The Lambda function's IAM role and permissions remain unchanged.

Description of how you validated changes

Unit tests added:

1. kubectl provider uses custom security group when provided in kubectlProviderOptions: Verifies that when a custom security group is specified in kubectlProviderOptions.securityGroup, it is correctly applied to the Lambda function's VPC configuration instead of the cluster security group.

2. kubectl provider falls back to cluster security group when custom security group is not provided: Ensures backward compatibility by verifying that when no custom security group is provided but privateSubnets are specified, the cluster security group is used as before.

Both tests use the existing test infrastructure (testFixture, Template.fromStack) and follow the same patterns as the existing security group test. The tests verify the Lambda function's VpcConfig.SecurityGroupIds property contains the expected security group reference.

Manual validation:

• Verified the code changes match the proposed solution in the GitHub issue
• Confirmed no linter errors are introduced
• Ensured the logic handles all edge cases (with/without custom security group, with/without private subnets)

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

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

[aws-cdk-automation]

(This review is outdated)

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

[github-actions]

⚠️ Experimental Feature: This security report is currently in experimental phase. Results may include false positives and the rules are being actively refined.
Please try merge from main to avoid findings unrelated to the PR.

---

	Tests	Passed ✅	Skipped	Failed
Security Guardian Results	48 ran	48 passed

Test	Result
No test annotations available

• View Security Guardian Results

[github-actions]

⚠️ Experimental Feature: This security report is currently in experimental phase. Results may include false positives and the rules are being actively refined.
Please try merge from main to avoid findings unrelated to the PR.

---

	Tests	Passed ✅	Skipped	Failed
Security Guardian Results with resolved templates	48 ran	48 passed

Test	Result
No test annotations available

• View Security Guardian Results with resolved templates

[letsgomeow]

Hi @jasdeepbhalla, thanks for working on this! I'm actually facing this issue in my project right now and need a fix rather urgently.
I noticed the tests are failing here. I've investigated the issue and have a fix with passing tests ready locally.
If you're busy or stuck, would you mind if I pushed my changes or opened a follow-up PR to speed things up? I'd love to help get this merged.

[jasdeepbhalla]

@letsgomeow Thanks for reaching out. I was just working on this. Pushed a change to fix the test issue.

If it doesnt get resolved, feel free to push commits to this branch to fix it :)

[letsgomeow]

I've prepared a fix for the tests. Please check the PR here: jasdeepbhalla#1
Could you please take a look? @jasdeepbhalla

[jasdeepbhalla]

@letsgomeow Updated the PR with your suggestions, let me know if this looks good?

[letsgomeow]

@jasdeepbhalla

Thanks for incorporating the tests!
I realized the test names I provided were inaccurate (they were duplicates). Could you please update them to the following ?

1. 'kubectl provider uses the explicitly provided security group for the handler lambda'
2. 'kubectl provider uses the cluster security group for the handler lambda when no SG is provided'

[jasdeepbhalla]

@letsgomeow Updated the tests. Good Catch :)

[letsgomeow]

@jasdeepbhalla

It looks like the CI is failing. As indicated in the error message, could you please run integ-runner --update-on-failed locally and push the updated results?
Also, there seems to be a warning regarding Git LFS. Could you please make sure you have it set up and then push again?

@aws-cdk/aws-eks-v2-alpha: Error: Some tests failed!
@aws-cdk/aws-eks-v2-alpha: To re-run failed tests run: integ-runner --update-on-failed
@aws-cdk/aws-eks-v2-alpha:     at run (/codebuild/output/src1476625588/src/actions-runner/_work/aws-cdk/aws-cdk/node_modules/@aws-cdk/integ-runner/lib/index.js:10653:13)
@aws-cdk/aws-eks-v2-alpha:     at async main (/codebuild/output/src1476625588/src/actions-runner/_work/aws-cdk/aws-cdk/node_modules/@aws-cdk/integ-runner/lib/index.js:10559:5)

[aws-cdk-automation]

(This review is outdated)

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

[jasdeepbhalla]

I’m not sure what I’m missing here. I deleted the old snapshot, rewrote the integration test, and generated a new snapshot, but I’m still running into the same pointer error. Any ideas on what I might be doing wrong?