[Feature] Allow restricting EKS control plane ENIs to private subnets on cluster creation

[guessi]

What feature/behavior/change do you want?

When eksctl creates a VPC for a cluster, it currently passes both the public and the private subnets to the EKS API as control plane subnets. As a result, the control plane's cross-account ENIs get placed in public subnets as well as private ones.

Public subnets in an eksctl-managed VPC exist to support NAT gateways and internet-facing load balancers — they should not be a factor in where the control plane's ENIs land. Users who want the control plane restricted to private subnets currently have no way to express that at cluster creation time.

The only existing workaround is running eksctl utils update-cluster-vpc-config after cluster creation, which calls the EKS API directly and leaves the cluster's CloudFormation stack out of sync with the actual subnet configuration — the stack still records the original (public + private) subnet set.

I'd like to propose a new field, e.g. vpc.controlPlaneOnPrivateSubnets, so that only the private subnets are passed to the EKS API at cluster creation time:

vpc:
  controlPlaneOnPrivateSubnets: true

Behavior:

• Public subnets are still created and continue to be used for NAT gateways and internet-facing load balancers — this does not make the cluster fully private, only the control plane subnet selection changes.
• Should apply to eksctl-created VPCs (IPv4 and IPv6, including fully-private clusters) as well as pre-existing/imported VPCs.
• Should be rejected when combined with vpc.controlPlaneSubnetIDs (mutually exclusive — explicit subnet IDs already give full control).
• Should be rejected when the configured private subnets don't cover at least two availability zones, since EKS requires at least two AZs for the control plane.
• Should not apply to Outposts clusters, since the control plane there is already private-only.
• eksctl utils update-cluster-vpc-config should reject the field (rather than silently ignoring it) and point users at vpc.controlPlaneSubnetIDs instead, since that command talks to the EKS API directly and can't keep the CloudFormation stack in sync.

Why do you want this feature?

Currently the only way to keep the control plane off public subnets is a post-creation eksctl utils update-cluster-vpc-config call, which:

1. Requires an extra manual step after every cluster creation.
2. Diverges the CloudFormation stack from the cluster's actual subnet configuration, which breaks stack-based drift detection/updates going forward.

Being able to declare this intent directly in the config file at creation time avoids both problems and makes the desired network posture reproducible from a single ClusterConfig.