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

The integration test has since been deployed against a live EKS cluster through the automated integration test workflow, and passed.

Note on the postCliContext removal: the integ test pinned two Lambda feature flags unrelated to this fix (createNewPoliciesWithAddToRolePolicy, useCdkManagedLogGroup), both set opposite to their recommendedValue, so it was exercising legacy behaviour. Removing them lets the test synthesize on current defaults. It is isolated in its own commit, and the effect is confined to the test's own nested stacks: the provider inline policies fold back into the default policies and CDK-managed log groups are added. No library code changes.

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 in both the aws-eks and aws-eks-v2 modules where constructing an AccessEntry with AccessEntryType.EC2 and a non-empty accessPolicies list threw a synth-time validation error, even though the EKS API accepts the combination. The fix narrows the internal validateAccessPoliciesForRestrictedTypes guard by dropping EC2 from restrictedTypes (keeping HYBRID_LINUX and HYPERPOD_LINUX guarded), and brings the enum JSDoc, README notes, unit tests, and a new integ test case into line — correctly aligning the L2 construct with the documented EKS Auto Mode workflow of attaching AmazonEKSAutoNodePolicy to an EC2-type entry.

The change itself is small, well-scoped, symmetric across the two modules, and backed by AWS documentation; the API surface, synthesized template behavior, and documentation are all consistent and correct. One point is worth attention: an unrelated feature-flag block was removed from the integ test's App, which drives most of the snapshot churn and should either be restored or justified so the fix diff stays reviewable.

🔴 0 blocking · 🟡 1 recommended · ⚪ 0 optional

Files with findings (1)

File	Findings
packages/@aws-cdk-testing/framework-integ/test/aws-eks/test/integ.eks-grant-access-with-type.ts	🟡 1

---

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

[krantboy]

Addressed the automated review note: updated the GrantAccessOptions.accessEntryType JSDoc in both aws-eks and aws-eks-v2 so it no longer says EC2 access entries can't have policies.

[github-actions]

⚠️ Experimental Feature: This security report is currently in experimental phase. Results may include false positives and the rules are being actively refined.
This security report is NOT a review blocker. Please try merge from main to avoid findings unrelated to the PR.
To suppress a specific rule, see Suppressing Rules.

---

	Tests	Passed ✅	Skipped	Failed
Security Guardian Results	72 ran	72 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.
This security report is NOT a review blocker. Please try merge from main to avoid findings unrelated to the PR.
To suppress a specific rule, see Suppressing Rules.

---

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

Test	Result
No test annotations available

• View Security Guardian Results with resolved templates

[kumvprat]

Thanks @krantboy for the contribution. It closes the p1 (#37496) by removing AccessEntryType.EC2 from restrictedTypes in validateAccessPoliciesForRestrictedTypes in both aws-eks and aws-eks-v2, so EC2 access entries can now carry access policies while HYBRID_LINUX/HYPERPOD_LINUX keep their guard.

The integ tests passed through our automated integration test workflow so deployment should be fine with this new feature.

I have added an inline comment on the integration tests, can you have a look ? Apart from that the PR changes look ready to be merged.

Merge notes: the branch is behind main, so please rebase and regenerate the snapshot.

[kumvprat]

On the specific feature flag toggles below :

const app = new App({
  postCliContext: {
    '@aws-cdk/aws-lambda:createNewPoliciesWithAddToRolePolicy': true,
    '@aws-cdk/aws-lambda:useCdkManagedLogGroup': false,
  },
});

Can you check if these are the default values of these feature flags now ? If so we can remove these overloads and check again if the integration tests pass

[krantboy]

Checked both, and neither is at its default:

• useCdkManagedLogGroup is pinned false while recommendedValue is true. Removing it adds two managed log groups.
• createNewPoliciesWithAddToRolePolicy is pinned true while recommendedValue is false. Removing it restructures the provider IAM policies.

They're stale, but dropping either changes what the test synthesizes, so I've left them as they are.

Also rebased on main. The snapshot verifies unchanged against current main, so there was nothing to regenerate. The force-push reset the workflow approvals, so CI will need a nudge from you to run.

[kumvprat]

They're stale, but dropping either changes what the test synthesizes, so I've left them as they are.

If these are not the specific requirements to make this feature work, can we remove the overrides and re-synth the test ? We can run the integration test automation post that to test the functionality

Approved the previous CI runs.

[krantboy]

Removed both overrides as requested and re-synthed. The test now runs on defaults.

Note the force-push reset the workflow approvals again, and the integ deployment needs additional approvals to release the deployment-integ-test environment.

[maintainer-for-aws]

See the review summary comment for the overview; the notes below are inline.

[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]

Merge Queue Status

• ✅ Entered queue — 2026-10-06 08:07 UTC · Rule: default-squash · triggered by rule automatic merge
• ✅ Checks passed · in-place
• ✅ Merged — 2026-10-06 10:56 UTC · at e507e07dcc2404845413e0a73c784bec0207aab3 · squash

This pull request spent 2 hours 48 minutes 36 seconds in the queue, including 1 hour 1 minute 57 seconds running CI.

Required conditions to merge

• github-review-approved [🛡 GitHub branch protection]
  • fix(eks): allow access policies on AccessEntryType.EC2 access entries #38782
• any of [🛡 GitHub branch protection]:
  • check-success = validate-pr
  • check-neutral = validate-pr
  • check-skipped = validate-pr
• any of [🛡 GitHub branch protection]:
  • check-success = build
  • check-neutral = build
  • check-skipped = build

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