EKS Now Takes Ten OIDC Providers, and Prefixes Stop Being Cosmetic

Executive summary

Amazon EKS can now associate up to 10 OIDC identity providers with a single cluster. The previous limit was one, and that single number shaped a great many cluster designs: teams that needed employees, contractors and pipelines to authenticate from different directories either consolidated them into one provider, ran a token broker in front of the cluster, or split the workload across clusters. All three were workarounds for a limit, not designs anyone chose.

It is available at no additional cost in every Region where EKS runs, and it is configured through the same AssociateIdentityProviderConfig API as before. Three things the announcement does not mention change how you should plan it:

• It requires Kubernetes 1.32 or later. Below that the limit is still exactly one. This turns out to matter less than it first appears, and the reason is worth reading.
• All ten providers share one 12 KB configuration budget. Not 12 KB each — 12 KB combined, which averages 1,228.8 bytes per provider if you use all ten.
• The username prefix stops being decoration. With one provider, prefixes prevented clashes with built-in Kubernetes names. With ten, they are the only thing stopping two directories from minting the same Kubernetes identity.

That last point is the one to take away. This is a feature that quietly promotes a field most people have never set from a cosmetic detail to a security boundary.

What changed

The user guide states the new limit and its condition in one place:

The number of OIDC identity providers you can associate with a cluster depends on the cluster's Kubernetes version. On clusters running Kubernetes version 1.32 or later, you can associate up to 10 OIDC identity providers. The combined size of all OIDC provider configurations must be less than 12 KB. On clusters running a version earlier than 1.32, you can associate only one OIDC identity provider.

Alongside the raised limit, two uniqueness rules apply and one new documentation section appears:

• The issuer URL and the name must both be unique across every provider on the cluster. You cannot associate the same provider twice, which rules out the pattern of registering one issuer several times with different claim mappings.
• A "Best practices for multiple identity providers" section now exists in the user guide, covering prefixes, required claims, and limiting the claims each token carries. Its presence is the clearest signal of where AWS expects this to go wrong.

What has not changed is just as important. IAM authentication cannot be disabled — the guide is explicit that it is still required for nodes to join a cluster. OIDC providers are added alongside IAM, never in place of it, so a cluster with ten providers has eleven ways in.

Architecture

Nothing moves on a network diagram here. What moves is the shape of the cluster's trust, and it moves from a tree into a list.

With one OIDC provider, a cluster had a single external root of trust. Every non-IAM identity on that cluster descended from one directory, which meant one place where accounts were created and one place where they were deprovisioned. The identity model matched an org chart: there was a top.

With ten, the cluster has ten peer roots of trust, and they are not ranked. When a request arrives, the API server tries each configured authenticator in turn until one accepts the token. There is no notion of a primary provider, no fallback order you control, and no field that records which provider vouched for a request once it has been accepted. What survives into authorization is a string: the Kubernetes username, and the group list.

That is the architectural consequence worth sitting with. Authorization on a Kubernetes cluster is string matching. A RoleBinding names a user or a group by literal text. It has no way to express "this user, but only when the corporate directory said so" — because by the time RBAC runs, the provider is gone and only the name remains.

So with one provider, the namespace of usernames had one author, and collisions were impossible by construction. With ten, the namespace has ten authors who have never spoken to each other, and the only thing keeping them apart is the prefix each one was configured with. The feature does not create that risk so much as it makes the prefix field load-bearing for the first time.

The second structural change is that the cluster now depends on ten external endpoints instead of one. The control plane fetches signing keys from each issuer URL, which must be publicly reachable — EKS does not support issuers with self-signed certificates — and on clusters using customer-routed control plane egress, every issuer must be reachable through the egress path you configure. Ten providers means ten availability dependencies for authentication, each one owned by somebody else.

The version floor, and why it is smaller than it sounds

"Kubernetes 1.32 or later" reads like a gate that will keep most estates out. Checked against the EKS release calendar, it excludes exactly one version anybody can still be running.

Versions 1.36, 1.35 and 1.34 are in standard support today. Versions 1.33, 1.32 and 1.31 are in extended support. The feature covers five of those six, and the one it does not cover reaches the end of extended support on November 26, 2026 — three months from now — after which EKS auto-upgrades the control plane whether you plan it or not.

So the honest reading of the version floor is that it is a deadline you already had. If you are on 1.31, multiple OIDC providers is not the reason to upgrade; it is one more thing waiting for you when you do.

There is a cost dimension underneath this that is easy to miss. A version receives standard support for 14 months, then extended support for a further 12 months — a 26-month lifecycle. Extended support is not free, and the difference is not small: a control plane on standard support is $0.10 per cluster per hour, and one in extended support is $0.60 per cluster per hour. That is six times the standard rate. Three of the five versions that can run ten providers are already on the paid side of that line.

The 12 KB budget is shared, not per provider

This is the constraint most likely to be discovered late, because nothing about "up to 10 providers" suggests the tenth might not fit.

The limit is on the combined size of all provider configurations: less than 12 KB in total. Across ten providers that averages 1,228.8 bytes each. For a plain configuration — a name, an issuer URL, a client ID, a username claim and two prefixes — that is roomy. The field that eats it is requiredClaims.

Required claims are the mechanism AWS's own best practices recommend for restricting which tokens a provider is allowed to mint on your cluster: key-value pairs that must be present in the ID token for it to be accepted. Their size limits are generous. A key can be up to 63 characters and a value up to 253, so a single maximum-length claim is 316 bytes of content before any JSON overhead — roughly a quarter of one provider's average share of the budget.

In practice most required claims are far shorter than the maximum, so this is not a limit you hit with three providers and a couple of claims each. It is a limit you hit at the far end of the range the announcement advertises, doing precisely the thing the documentation recommends. Plan the configuration for ten providers before you build the first one, rather than discovering the ceiling on the ninth.

One documentation note worth recording, because it will cost somebody an afternoon: the API reference for requiredClaims says that for the maximum number of claims you can require, see Amazon EKS service quotas. The EKS quotas table in the AWS General Reference does not currently list a row for required claims per provider, nor one for identity provider configurations per cluster. The 12 KB combined ceiling in the user guide is the operative limit to design against.

Business value

The value here is almost entirely in workarounds that stop being necessary.

The clearest case is the third one. Splitting a cluster for identity reasons alone is expensive in a way that does not show up as a line item — it is a second thing to upgrade, a second set of add-ons to patch, a second place for configuration to drift. If that split was made because of the one-provider limit and for no other reason, that reason is now gone.

The case that deserves more caution is the first. Consolidating contractors into the corporate directory was a bad answer to this problem, but undoing it means an identity migration, not a configuration change. The feature makes the better design available; it does not make the move to it cheap.

Security considerations

This is the section that matters, and it comes down to one field.

Prefixes now separate directories, not just Kubernetes internals. The original purpose of usernamePrefix and groupsPrefix was to stop external names clashing with built-in ones — which is why the documentation forbids setting either to system: or any portion of that string. With ten providers, they do something else as well. AWS's own best practices state it plainly: setting a distinct prefix per provider, or using claims that are unique per provider, “makes sure that two providers can't produce the same Kubernetes username or group name”.

The inverse is the risk. Two providers that both disable prefixing — usernamePrefix set to - — and both use the same username claim can produce the same Kubernetes username from two different directories. Every RoleBinding naming that username then grants both. Nothing errors, nothing warns, and the audit log records the username rather than the directory that issued it.

The default prefix is the issuer URL, which is safe and ugly. If usernamePrefix is not set and the username claim is anything other than email, the prefix defaults to issuerurl#. That default is collision-safe by construction — issuer URLs are unique per provider — but it means your RoleBinding subjects read like https://login.example.com#a1b2c3d4, and they change if the issuer URL ever changes. Set a short deliberate prefix instead of accepting the default or disabling it.

Three more, briefly:

• Use required claims as an admission filter. A provider you do not fully control can mint a token for anyone in its directory. requiredClaims is where you narrow that to the population you actually intended.
• Limit the claims each token carries. AWS's best practice is to configure the provider to issue only the claims the cluster needs, on the grounds that a smaller token exposes less if it is compromised.
• Control who can add a provider. The user guide supplies an IAM policy denying eks:AssociateIdentityProviderConfig, and a second that permits it only for a specific eks:issuerUrl and eks:clientId. With ten slots available rather than one, an allowlist condition on those keys is worth more than it used to be — the ninth provider on a cluster is far less likely to be noticed than the second.

Finally, OIDC-authenticated users appear in the cluster audit log only if control plane logging is enabled. Turning on authenticator logs before adding providers is the difference between being able to answer "which directory did this request come from" and not.

Cost considerations

The feature itself is free: AWS states it is available at no additional cost in all AWS Regions where Amazon EKS is available. There is no per-provider charge and no new resource to pay for.

The cost story is entirely in the version floor. The rates on the EKS pricing page are $0.10 per cluster per hour for standard Kubernetes version support and $0.60 per cluster per hour for extended support — the standard rate plus a $0.50 per cluster per hour surcharge. That surcharge is $4,380 per cluster per year, and on a fleet it is the number that decides upgrade timing.

Two directions that runs in:

• If this feature is what finally moves a 1.31 cluster forward, upgrading to a version in standard support removes the surcharge as a side effect. The saving is larger than anything the feature itself was going to deliver.
• If it tempts you to sit on 1.32 because it is "good enough", note that 1.32 has been in extended support since March 23, 2026 and reaches the end of it on March 23, 2027. Standing still on the minimum supported version to get a free feature costs $0.50 per cluster per hour for the privilege.

The genuine saving is elsewhere and is not on any rate card: a token broker retired, or a cluster that existed only to hold a second identity provider shut down. A duplicate control plane is $0.10 per cluster per hour before anything runs on it, and considerably more than that in the time spent keeping two of everything current.

Operational considerations

Associating a provider is a cluster update, not a configuration write. The documentation is explicit: the cluster enters the UPDATING state and the change can take several minutes to be fully applied to the cluster's API servers. Track it with DescribeUpdate rather than assuming the API's 200 response means the provider is live. Ten providers is ten cluster updates, sequenced, not one batch.

Three consequences follow from that:

• Provider changes belong in a change window. Anything that puts a cluster into UPDATING should be treated as such, even though this particular update is additive.
• Automate it, because ten of anything drifts. The API takes clientId, identityProviderConfigName and issuerUrl as required, with usernameClaim, usernamePrefix, groupsClaim, groupsPrefix and requiredClaims optional. Every one of those optional fields is a security decision, and optional fields set by hand across ten providers and several clusters will not stay consistent.
• Ten issuers is ten availability dependencies. Each must be publicly reachable for the control plane to fetch signing keys, and none of them are yours to page. On clusters using customer-routed control plane egress, confirm each issuer endpoint is reachable through your configured egress path before associating it.

Configuration is available through the console, eksctl and the AssociateIdentityProviderConfig API. The console path is under the cluster's Access tab; eksctl takes an identityProviders block in a cluster config file, which is the closer fit for anything you intend to reproduce.

Tradeoffs

Implementation guidance

1. Check the cluster's Kubernetes version first. Below 1.32 nothing here applies. If that is 1.31, note that its extended support ends November 26, 2026 and plan the upgrade for that reason rather than this one.
2. Decide the prefix scheme before associating anything. A short distinct prefix per provider — corp:, partner:, ci: — written down as a standard. Do not accept the issuerurl# default and never set - on more than one provider.
3. Do the same for groups. groupsPrefix has the same collision property as usernames and carries more authority, because groups are what most bindings actually name.
4. Never use system: or any part of it in either prefix. This is a documented prohibition, not a style preference.
5. Set requiredClaims on every provider, especially any you do not administer. Then total the configuration sizes against the 12 KB combined ceiling before you build the estate, not after.
6. Enable control plane authenticator logging before the first association, so there is a record of which identities authenticated from where.
7. Add an IAM guardrail on association. Use the documented condition keys eks:issuerUrl and eks:clientId to allowlist the providers you intend, so an eleventh cannot be quietly added.
8. Associate one provider at a time and watch DescribeUpdate. Each is a cluster update of several minutes; treat a batch as a sequence.
9. Test the collision case deliberately. Issue a token for the same username from two providers in a non-production cluster and confirm the two resolve to different Kubernetes usernames. This is the failure that has no error message.

Best practices

• Treat usernamePrefix and groupsPrefix as security configuration. With one provider they prevented clashes with Kubernetes internals. With several they are the boundary between directories, and they are optional fields that default quietly.
• One provider per population, not per team. The ceiling is ten and the budget is shared; spending slots on organisational units rather than on genuinely distinct identity sources runs out fast and buys nothing RBAC groups could not.
• Write bindings against groups, not usernames. Prefixed group names carry the provider in the string, which keeps the source of an identity visible in the artefact that grants access.
• Keep IAM access entries as the break-glass path. IAM cannot be disabled and does not depend on an external issuer being reachable, which makes it the path that still works when a provider is down.
• Define providers in code. Five optional fields, ten providers and several clusters is exactly the shape of configuration that drifts when set by hand.
• Audit the provider list on a schedule. ListIdentityProviderConfigs against every cluster, compared with the list you expect. Ten permitted slots is nine places for something unexpected to sit unnoticed.
• Budget the configuration size up front. The 12 KB ceiling is combined, so the tenth provider is the one that fails, and it fails after nine are already in production.

Who should adopt, who should wait

Adopt now: anyone on 1.32 or later running a token broker, a federation proxy, or a second cluster purely to serve a second identity population. The workaround was always the compromise; this removes the constraint that forced it, and the operational saving is immediate.

Adopt carefully: teams with one provider today who want to add a second for contractors or pipelines. The feature is straightforward, but the prefix scheme has to be designed before the second provider exists rather than after. Adding a provider is easy; renaming every Kubernetes identity on a cluster afterwards is not.

Wait: anyone on 1.31 or earlier. The version floor is real, and the right response is an upgrade planned against the November 26, 2026 end-of-extended-support date, with this feature as a benefit of that upgrade rather than the justification for it.

Reconsider entirely: teams who consolidated contractors and partners into the corporate directory to fit the one-provider limit. That is now an avoidable risk rather than a necessary one — but unwinding it is an identity project, and it should be scoped as one.

Key takeaways

• EKS now associates up to 10 OIDC identity providers per cluster, at no additional cost in all AWS Regions where Amazon EKS is available.
• It requires Kubernetes 1.32 or later. Earlier versions are still limited to exactly one provider.
• The version floor excludes only 1.31 among versions still supported, and 1.31 reaches end of extended support on November 26, 2026.
• All configurations share a combined 12 KB budget — 1,228.8 bytes per provider on average across ten, with requiredClaims the field most likely to consume it.
• Prefixes are now a security boundary. AWS's own guidance is that distinct prefixes or per-provider claims are what stop two providers producing the same Kubernetes username or group.
• If usernamePrefix is unset and the username claim is not email, it defaults to issuerurl#. Setting it to - disables prefixing, which is the setting that permits collisions.
• IAM authentication cannot be disabled — it is still required for nodes to join — so ten providers means eleven authentication paths.
• Each association is a cluster update that enters UPDATING and takes several minutes; track it with DescribeUpdate.
• Extended support costs $0.60 per cluster per hour against $0.10 on standard — six times the rate, or $4,380 per cluster per year in surcharge.

Official AWS references

• Amazon EKS now supports multiple external OIDC identity providers per cluster — the announcement
• Grant users access to Kubernetes with an external OIDC provider — the ten-provider limit, the 12 KB budget, the version condition, and the best practices for multiple providers
• OidcIdentityProviderConfigRequest — required and optional fields, the issuerurl# prefix default, and the required-claim length limits
• AssociateIdentityProviderConfig — the API that performs the association and returns an update to track
• Understand the Kubernetes version lifecycle on EKS — the release calendar and the standard versus extended support windows
• Amazon EKS pricing — standard and extended Kubernetes version support rates