fix(eks): allow access policies on AccessEntryType.EC2 access entries

[krantboy]

Issue # (if applicable)

Closes #37496.

Reason for this change

AccessEntry rejected accessPolicies on AccessEntryType.EC2 entries at synth time, even though the EKS API accepts them.

validateAccessPoliciesForRestrictedTypes grouped EC2 with HYBRID_LINUX and HYPERPOD_LINUX:

const restrictedTypes = [AccessEntryType.EC2, AccessEntryType.HYBRID_LINUX, AccessEntryType.HYPERPOD_LINUX];

That guard runs from both the AccessEntry constructor and addAccessPolicies(), so either path threw Access entry type 'EC2' cannot have access policies attached.

Attaching AmazonEKSAutoNodePolicy to an EC2 type entry is the documented way to grant an EKS Auto Mode node class access to the cluster — see Create node class access entry, which creates the entry with --type EC2 and then associates that policy. The equivalent CfnAccessEntry (Type: "EC2" with AccessPolicies) deploys fine, so the L2 was strictly more restrictive than the resource underneath it and users had to drop to L1 to express it.

aws-eks-v2's README already documented exactly this call:

cluster.grantAccess('nodeAccess', nodeRole.roleArn, [
  eks.AccessPolicy.fromAccessPolicyName('AmazonEKSAutoNodePolicy', {
    accessScopeType: eks.AccessScopeType.CLUSTER,
  }),
], { accessEntryType: eks.AccessEntryType.EC2 });

directly above a note saying EC2 cannot have policies. That example throws at synth today. README blocks are compiled by Rosetta but never executed, so nothing caught the contradiction.

Description of changes

• Remove AccessEntryType.EC2 from restrictedTypes in aws-eks and aws-eks-v2. HYBRID_LINUX and HYPERPOD_LINUX keep their guard — this PR makes no claim about those.
• Correct the EC2 enum JSDoc and the README notes in both modules, which asserted the opposite of the new behaviour.

No feature flag. This relaxes a synth-time guard that rejected input CloudFormation would have accepted, so no app that synthesizes today can change behaviour — per CONTRIBUTING, a flag is required for the opposite direction (newly rejecting input that used to work).

Two decisions worth a maintainer's opinion:

1. The integ test uses AmazonEKSAutoNodePolicy because it is the documented real-world pairing, on the existing non-Auto-Mode cluster in that test. AmazonEKSViewPolicy would exercise the same code path with less dependence on Auto Mode specifics if you would prefer that.
2. I did not add an EC2 entry to the aws-eks-v2 integ test, since its own comments state EC2 requires an Auto Mode cluster. That file gets a comment correction only, no resource change and no snapshot impact.

Describe any new or updated permissions being added

None. No IAM policy is generated or changed by CDK here — this only stops CDK from rejecting an AccessPolicies value the user supplies, which is then passed through to AWS::EKS::AccessEntry unchanged.

Description of how you validated changes

Unit tests in both modules — EC2 moved from the two throws-lists into the two allows-lists, so it is now asserted to accept policies both at construction and via addAccessPolicies(). 56 tests pass across aws-eks/test/access-entry.test.ts and aws-eks-v2/test/access-entry.test.ts.

I confirmed the tests are load-bearing rather than vacuous: re-adding EC2 to restrictedTypes fails exactly 3 of them (creates a new AccessEntry for AccessEntryType EC2, allows EC2 type with access policies, allows adding policies to EC2 type via addAccessPolicies()).

Integ test: added an EC2 type entry carrying AmazonEKSAutoNodePolicy to integ.eks-grant-access-with-type.ts. The snapshot diff is the two intended resources:

[+] AWS::IAM::Role EC2AutoNodeRoleC9A6A37A
[+] AWS::EKS::AccessEntry EC2AccessWithPolicyD4A5AB73

Please note: I regenerated the snapshot with yarn integ --dry-run --update-on-failed and have not deployed to a live EKS cluster, so this is not verified end-to-end against the service. Happy for a maintainer to run it.

The snapshot also carries unrelated churn from main having moved since it was last regenerated: cloud assembly schema 53 → 54 (main already has a 53/54 mix), the creationStack → acknowledged-rules metadata change, and re-bundled Lambda handler asset hashes. I checked each file — the nested templates differ only by S3Key, and nothing behavioural changed.

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

[maintainer-for-aws]

Automated review

A maintainer will still review this — treat the notes below as a starting point.

This PR fixes a bug (issue #37496) where the EKS L2 rejected AccessEntryType.EC2 access entries that carry access policies, even though the underlying AWS::EKS::AccessEntry accepts Type: "EC2" with AccessPolicies (e.g. AmazonEKSAutoNodePolicy for Auto Mode node roles). The fix removes EC2 from the restrictedTypes array in validateAccessPoliciesForRestrictedTypes, applied symmetrically in both the aws-eks and aws-eks-v2 modules, and aligns the enum JSDoc, READMEs, unit tests, and an integ test to the documented service behavior.

The change is well-scoped and correct: it relaxes a synth-time validation only, so any program that previously synthesized still produces an identical template, and no public API shape changes. Unit tests cover both the constructor and addAccessPolicies() paths in each module, and the integ template renders the intended Type: EC2 + AmazonEKSAutoNodePolicy resource. One consistency gap remains — the public GrantAccessOptions.accessEntryType JSDoc in both cluster.ts files still claims EC2 cannot have policies, contradicting the shipped behavior.

🔴 0 blocking · 🟡 0 recommended · ⚪ 0 optional

---

Generated automatically. React 👍 or 👎 to tell us whether this review helped, so we can improve these reviews.