---
next_cursor: eyJzY29yZSI6MCwic2VxIjoxOTgzLCJzaW5jZSI6bnVsbCwidG9vbCI6ImVrc2N0bCIsInYiOjF9
has_more: false
next: https://sincecutoff.com/v1/changes.md?tool=eksctl&score=0&cursor=eyJzY29yZSI6MCwic2VxIjoxOTgzLCJzaW5jZSI6bnVsbCwidG9vbCI6ImVrc2N0bCIsInYiOjF9
items: 5
---
# sincecutoff.com changes: eksctl

## eksctl create iamserviceaccount accepts wildcard subject patterns (eksctl, 2026-02-06)
Published 2026-10-19
- slug: eksctl-create-iamserviceaccount-accepts-wildcard-subject-patterns-643ca1d539b0
- score: 0.98

How to use it:

When multiple service accounts share a naming pattern, run `eksctl create iamserviceaccount` with `--subject-pattern="app-*"`; this makes the trust policy use `StringLike`. Use the narrowest pattern needed, since `*` allows any service account in the namespace to assume the role.

Examples:

```
eksctl create iamserviceaccount --cluster=<clusterName> --name=<serviceAccountName> --namespace=<serviceAccountNamespace> --attach-policy-arn=<policyARN> --subject-pattern="app-*"
```

```
eksctl create iamserviceaccount --config-file=<path>
```

```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
iam:
  withOIDC: true
  serviceAccounts:
    - metadata:
        name: <serviceAccountName>
        namespace: <serviceAccountNamespace>
      attachPolicyARNs:
        - <policyARN>
      subjectPattern: "app-*"
```

- why_it_matters: Configure an IAM role trust policy for service accounts whose names share a pattern.
- sources: <https://github.com/eksctl-io/eksctl/releases/tag/v0.222.0>, <https://github.com/eksctl-io/eksctl/pull/8629>, <https://github.com/eksctl-io/eksctl/blob/v0.222.0/userdocs/src/usage/iamserviceaccounts.md>
- gotchas: "Version: v0.222.0"; "--cluster (required): EKS cluster name."; "--name (required): Service account name; example uses `app-base`."; "--namespace: Service account namespace; defaults to `default`."; "--attach-policy-arn: Policy ARN to attach; can be specified multiple times. The wildcard example supplies one."; "--subject-pattern: Wildcard pattern for trusted service account subjects; uses the `StringLike` condition instead of `StringEquals`."; "subjectPattern: Config-file property for the service account subject wildcard pattern."; "iam.withOIDC (required): Set `true` when managing IAM service accounts through the config file."; "iam.serviceAccounts (required): Config-file list of service accounts to manage."; "metadata.name (required): Service account name in the config entry."; "metadata.namespace: Namespace in the config entry; if unset, `default` is used."; "attachPolicyARNs: List of policy ARNs to attach in the config entry."; "Prerequisite: IRSA requires Kubernetes 1.13 or above."; "Prerequisite: The cluster's IAM OIDC provider must be associated; the docs provide `eksctl utils associate-iam-oidc-provider --cluster=<clusterName>` to enable it."; "Wildcard patterns are used with `--subject-pattern`."; "A broad pattern like `*` allows any service account in the namespace to assume the IAM role."

## eksctl create/update pod identity associations accept --policy (eksctl, 2026-02-14)
Published 2026-10-19
- slug: eksctl-create-update-pod-identity-associations-accept-policy-98d07f0db30b
- score: 0.95

How to use it:

When creating or updating a pod identity association with an additional policy, pass it with `--policy` and disable session tags. The policy adds restrictions beyond the IAM policies attached to the role.

Examples:

```
eksctl create podidentityassociation --cluster <cluster> --namespace <namespace> --service-account-name <service-account> --policy '<policy-document>' --disable-session-tags
```

```
eksctl update podidentityassociation --cluster <cluster> --namespace <namespace> --service-account-name <service-account> --policy '<policy-document>' --disable-session-tags
```

- why_it_matters: Create or update a pod identity association with an additional policy.
- sources: <https://github.com/eksctl-io/eksctl/releases/tag/v0.223.0>, <https://github.com/eksctl-io/eksctl/pull/8674>, <https://github.com/eksctl-io/eksctl/blob/v0.223.0/pkg/ctl/create/pod_identity_association.go>, <https://github.com/eksctl-io/eksctl/blob/v0.223.0/pkg/ctl/update/pod_identity_association.go>, <https://docs.aws.amazon.com/eks/latest/eksctl/pod-identity-associations.html>
- gotchas: "Version: v0.223.0"; "--cluster <cluster> (required): Name of the target cluster."; "--namespace <namespace> (required): Namespace of the service account or association."; "--service-account-name <service-account> (required): Name of the service account for the association."; "--policy <policy-document>: Optional policy adding restrictions beyond the IAM policies attached to the role. The docs do not specify the CLI document format."; "--disable-session-tags: Disable EKS Pod Identity session tags; required when passing `--policy`."; "Prerequisite: The `eks-pod-identity-agent` add-on must be installed on the cluster before creating an association; EKS Auto Mode clusters have it pre-installed."

## eksctl supports control plane component configuration (eksctl, 2026-08-14)
Published 2026-10-19
- slug: eksctl-supports-control-plane-component-configuration-f0a3c7a19ca9
- score: 0.98

How to use it:

When creating an EKS cluster with selected control plane settings, set the corresponding optional component fields in the ClusterConfig file; omitted fields use EKS defaults. To update an existing cluster, set at least one component field and run the update command; only components present in the file are updated.

Examples:

```
eksctl create cluster -f control-plane-component-config.yaml
```

```
eksctl utils update-control-plane-component-config -f control-plane-component-config.yaml
```

- why_it_matters: Create or update an EKS cluster with selected kube-apiserver, kube-scheduler, or kube-controller-manager settings.
- sources: <https://github.com/eksctl-io/eksctl/releases/tag/v0.230.0>, <https://github.com/eksctl-io/eksctl/pull/8821>, <https://eksctl.io/usage/control-plane-component-config/>
- gotchas: "Version: v0.230.0"; "-f control-plane-component-config.yaml (required): Path to the ClusterConfig file. Required for the update command."; "kubeAPIServerConfig: Optional kube-apiserver configuration. Documented sub-keys: eventTTL (event retention duration) and serviceNodePortRange, with required minPort and maxPort port numbers. These component fields are independently optional, not documented as mutually exclusive."; "kubeSchedulerConfig: Optional kube-scheduler configuration. Documented sub-key nodeResourcesFit.scoringStrategy: type accepts LeastAllocated or MostAllocated; resources is a list of resources considered, each with a relative weight. These component fields are independently optional, not documented as mutually exclusive."; "kubeControllerManagerConfig: Optional kube-controller-manager configuration. Documented sub-key horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod (duration string; configurable only on provisioned control plane scaling tiers, fixed at default on Standard tier), and podGCControllerConfig.terminatedPodGCThreshold (threshold; configurable only on provisioned control plane scaling tiers, fixed at default on Standard tier). These component fields are independently optional, not documented as mutually exclusive."; "Each component field is optional; EKS applies its default for omitted fields when creating a cluster."; "Updating an existing cluster requires a config file with at least one of `kubeAPIServerConfig`, `kubeSchedulerConfig`, or `kubeControllerManagerConfig`."; "Only components present in the update file are updated; omitted components are left unchanged."; "Docs conflict: The current official documentation includes podGCControllerConfig.terminatedPodGCThreshold, absent from the supplied v0.230.0 release-note evidence; it also says Standard tier fixes this setting at the default. Do not treat this as evidence that the v0.230.0 feature supported that key."

## eksctl cluster creation can place control plane ENIs only in private subnets (eksctl, 2026-10-02)
Published 2026-10-19
- slug: eksctl-cluster-creation-can-place-control-plane-enis-only-in-private-subnets-a0213c52e511
- score: 0.97

How to use it:

When creating a cluster whose control plane ENIs must use private subnets, set `vpc.controlPlaneOnPrivateSubnets: true` in the config and run `eksctl create cluster -f config.yaml`. Public subnets remain available for other cluster resources.

Examples:

```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: cluster
  region: us-west-2
availabilityZones:
  - us-west-2a
  - us-west-2b
vpc:
  controlPlaneOnPrivateSubnets: true

# Save as config.yaml, then run:
eksctl create cluster -f config.yaml
```

- why_it_matters: Create a cluster whose control plane cross-account ENIs must use private subnets while retaining public subnets for other cluster resources.
- before: For an existing cluster, `eksctl utils update-cluster-vpc-config` can change control plane subnets by calling the EKS API directly; this leaves the CloudFormation stack out of sync. The new setting applies only at cluster creation.
- sources: <https://github.com/eksctl-io/eksctl/releases/tag/v0.231.0>, <https://github.com/eksctl-io/eksctl/pull/8793>, <https://github.com/eksctl-io/eksctl/blob/v0.231.0/userdocs/src/usage/cluster-subnets-security-groups.md>, <https://github.com/eksctl-io/eksctl/blob/v0.231.0/userdocs/src/usage/creating-and-managing-clusters.md>
- gotchas: "Version: v0.231.0"; "vpc.controlPlaneOnPrivateSubnets: Set to `true` at cluster creation to pass only private subnets to the EKS API. Cannot be combined with `vpc.controlPlaneSubnetIDs`."; "eksctl create cluster -f <config.yaml> (required): Creates a cluster using the specified config file."; "Prerequisite: At least two private subnets across at least two availability zones are required."; "Prerequisite: Private subnets need a NAT gateway or relevant VPC endpoints so nodes can reach the API server."; "At least two private subnets across at least two availability zones are required."; "The field is rejected when combined with `vpc.controlPlaneSubnetIDs`."; "Public subnets are still created and used for NAT gateways, internet-facing load balancers, and any nodegroup that is not private; this setting does not make the cluster fully private."

## eksctl nodegroup config supports connectionTracking timeouts (eksctl, 2026-10-02)
Published 2026-10-19
- slug: eksctl-nodegroup-config-supports-connectiontracking-timeouts-0df55eef1a7b
- score: 0.96

How to use it:

For nodegroups running long-lived, mostly idle connections, set at least one timeout in `connectionTracking`; omitted fields retain EC2’s instance-type default. Configure it in the nodegroup config when creating the nodegroup.

Examples:

```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: <cluster-name>
  region: <region>
managedNodeGroups:
  - name: <nodegroup-name>
    instanceType: <nitro-instance-type>
    connectionTracking:
      tcpEstablishedTimeout: 432000
```

- why_it_matters: Configure EC2 connection tracking timeouts for nodegroups that run workloads with long-lived, mostly idle connections.
- before: The release note says this support lets users configure the timeouts in native nodegroup config without resorting to a hand-written launch template.
- sources: <https://github.com/eksctl-io/eksctl/releases/tag/v0.231.0>, <https://github.com/eksctl-io/eksctl/pull/8872>, <https://eksctl.io/usage/nodegroup-connection-tracking/>
- gotchas: "Version: v0.231.0"; "connectionTracking: Optional nodegroup block for connection tracking timeouts; if present, at least one timeout must be set."; "tcpEstablishedTimeout: Idle TCP established-connection timeout, in seconds; allowed range 60–432000."; "udpStreamTimeout: Idle UDP stream timeout, in seconds, for flows with more than one request-response transaction; allowed range 60–180."; "udpTimeout: Idle UDP timeout, in seconds, for flows with one direction of traffic or at most one request-response transaction; allowed range 30–60."; "Prerequisite: Every instance type the nodegroup can launch must be Nitro-based."; "Prerequisite: For pod interfaces to inherit the primary interface settings, VPC CNI must be v1.21.2 or v1.22.1, or later in those release lines; older versions apply the timeouts to node traffic only."; "At least one timeout must be set."; "Supported ranges are tcpEstablishedTimeout 60–432000 seconds, udpStreamTimeout 60–180 seconds, and udpTimeout 30–60 seconds."; "Timeouts left unset keep EC2's default for the instance type."

Next: https://sincecutoff.com/v1/changes.md?tool=eksctl&score=0&cursor=eyJzY29yZSI6MCwic2VxIjoxOTgzLCJzaW5jZSI6bnVsbCwidG9vbCI6ImVrc2N0bCIsInYiOjF9
Save `next_cursor`; next visit, pass it to get only what was published since.
<!-- end of page -->