[gustavodiaz7722]

Problem

Creating an IPv6 cluster fails. Nodes launch and join the cluster, but never become
ready, so the managed nodegroup stays in CREATING until eksctl gives up after 30
minutes:

Error: failed to create cluster "it-ipv6-..."
exceeded max wait time for StackCreateComplete waiter

aws-node is in CrashLoopBackOff. ipamd on the node says exactly why:

Initialization failure: checking to exclude configured subnet, error:
  failed to get VPC subnets: AllocENI: unable to describe subnets:
  api error UnauthorizedOperation: You are not authorized to perform this
  operation. User: .../eksctl-...-addon-vpc-cni-Role1-... is not authorized
  to perform: ec2:DescribeSubnets because no identity-based policy allows
  the ec2:DescribeSubnets action

The CNI logs Subnet discovery enabled true and calls ec2:DescribeSubnets during
initialisation. It is on by default, so the call is not optional. The CNI also raises
its own MissingIAMPermissions warning event, pointing at
the upstream IAM policy docs.

makeIPv6VPCCNIPolicyDocument does not grant that action.

Why only IPv6

The IPv4 path attaches the AWS-managed AmazonEKS_CNI_Policy, which already includes
ec2:DescribeSubnets. The IPv6 path uses this hand-written inline policy instead, so
the permission has to be granted explicitly.

Why this started without an eksctl change

The ipv6 integration suite has been failing since 2026-07-30 with no corresponding
commit. Nothing in eksctl changed; the VPC CNI addon version advanced to one that
performs subnet discovery, and the missing permission became load-bearing.

This is why the failure was so hard to place. The symptom surfaces well above the
cause:

• CloudFormation reports only ManagedNodeGroup CREATE_FAILED "Resource creation cancelled", and only because eksctl initiates the delete. CFN itself never fails.
• describe-nodegroup reports health.issues: [] throughout, because from EKS's point
  of view the instances launched correctly.
• The instances are InService/Healthy in the ASG and nodeadm completes cleanly.
• Quotas, leaked resources and the launch template are all fine.

Fix

Add ec2:DescribeSubnets to the IPv6 VPC CNI policy.

Testing

Verified end to end against a real IPv6 cluster, reproducing with the released
v0.229.0 binary, so this affects a shipped version and not just main.

Before, with the policy as-is on main:

NAME             READY   STATUS             RESTARTS
aws-node-hkppv   1/2     CrashLoopBackOff   7
aws-node-kzbz9   1/2     CrashLoopBackOff   7
coredns-...      0/1     Pending            0

NAME                  STATUS
ip-192-168-29-60...   NotReady
ip-192-168-37-119..   NotReady

nodegroup mng-1: status=CREATING health.issues=[]

Adding ec2:DescribeSubnets to the live role, changing nothing else:

aws-node-hkppv   2/2   Running
aws-node-kzbz9   2/2   Running
coredns-...      1/1   Running

ip-192-168-29-60...   Ready
ip-192-168-37-119..   Ready

nodegroup mng-1: status=ACTIVE

The unit test for the IPv6 IRSA policy is extended to assert DescribeSubnets is
present, so the permission cannot be dropped again silently.

Note for reviewers

Worth sanity-checking the IPv6 policy against the upstream CNI IAM doc more broadly
while we are here, in case subnet discovery is not the only capability that has been
added since this list was written. I only added what I could demonstrate is required.

[github-actions]

Hello gustavodiaz7722 👋 Thank you for opening a Pull Request in eksctl project. The team will review the Pull Request and aim to respond within 1-10 business days. Meanwhile, please read about the Contribution and Code of Conduct guidelines here. You can find out more information about eksctl on our website