fix(eks): kubectlProvider should use the AmazonEC2ContainerRegistryPullOnly managed policy

[pahud]

Issue

Closes #35244

Problem Statement

The current KubectlProvider implementation uses the AmazonEC2ContainerRegistryReadOnly managed policy for ECR access, which has two key limitations:

1. Too broad: Includes unnecessary permissions like ecr:ListImages that kubectl doesn't require
2. Too narrow: Missing the ecr:BatchImportUpstreamImage action required for ECR pull-through cache functionality

This prevents users from leveraging ECR pull-through caches when installing Helm charts from ECR repositories via the CDK.

Solution

Replace AmazonEC2ContainerRegistryReadOnly with AmazonEC2ContainerRegistryPullOnly in the KubectlProvider's IAM role. The AmazonEC2ContainerRegistryPullOnly policy:

• Provides the exact permissions needed for container image pulling
• Includes support for ecr:BatchImportUpstreamImage enabling pull-through cache functionality
• Follows the principle of least privilege by removing unnecessary permissions

Changes Made

• Updated kubectl-provider.ts to use AmazonEC2ContainerRegistryPullOnly instead of AmazonEC2ContainerRegistryReadOnly
• Regenerated integration test snapshots to reflect the policy change across all affected EKS test cases

Impact

• Enables ECR pull-through cache support for Helm chart installations via kubectl
• Improves security posture by applying principle of least privilege
• Maintains backward compatibility - all existing functionality continues to work
• No breaking changes - this is a drop-in replacement with enhanced capabilities

Testing

• All existing integration tests pass with updated snapshots
• The change affects multiple EKS integration test scenarios including ALB controller, custom addons, and various node group
configurations
• Verified that the new policy provides all necessary permissions for kubectl operations

References

• AmazonEC2ContainerRegistryPullOnly Policy Documentation
• AmazonEC2ContainerRegistryReadOnly Policy Documentation

---

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.

[kumvprat]

Is it required to set : '@aws-cdk/aws-lambda:useCdkManagedLogGroup': false,

Since the integ test stacks deploy as new stacks, we should leave it at default value to test out that change in behaviour holds with the default feature flag values.

[kumvprat]

For feature flag : '@aws-cdk/aws-lambda:createNewPoliciesWithAddToRolePolicy' the default value seems to be false
Setting it explicitly shouldn't be needed

[pahud]

Thanks. All removed.

[kumvprat]

Same as above
For feature flag : '@aws-cdk/aws-lambda:createNewPoliciesWithAddToRolePolicy' the default value seems to be false
Setting it explicitly shouldn't be needed

[pahud]

Thanks. All removed.

[aws-cdk-automation]

(This review is outdated)

[pahud]

Exemption request

Mostly calling out that no integ test changes are needed as the change is in a policy being used, not the exact functionality of the module.

[pahud]

Clarification Request

please clarify why snapshots update is still required

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

[mergify]

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]

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).

[github-actions]

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.