EKS now supports up to 10 OIDC providers per cluster!

Hi, it's Shii! Today I found a piece of news that's a bit low-key but genuinely great for anyone running Kubernetes, so let me share it!

AWS What's New aws.amazon.com

What was announced?

AWS's What's New page announced that Amazon EKS now supports associating multiple external OIDC (OpenID Connect) identity providers with a single cluster. You can now connect up to 10 providers, which gives you a lot more flexibility in how you authenticate users and workloads to your cluster.

The context here is that many organizations already use different identity providers for different populations, like employees, contractors, and CI/CD systems. With this update, you can associate each of those providers directly with your cluster, so you no longer need to consolidate everyone into a single provider or run a separate intermediary identity broker.

Each provider is configured and managed independently, so each population can authenticate through its own provider and its own identity mapping, which is a nice touch. On top of that, your existing IAM authentication keeps working alongside every provider you configure.

Setup works the same way as before: you can add each provider through the AWS Management Console, or through the AssociateIdentityProviderConfig API via the AWS CLI and SDKs. This capability comes at no additional cost and is available in every AWS Region where Amazon EKS is available.

The story so far

Looking at the EKS User Guide, the number of OIDC providers you can associate with a cluster depends on its Kubernetes version. Clusters running a version earlier than Kubernetes 1.32 can still only associate one OIDC identity provider, just like before.

That meant organizations with multiple user populations had to either consolidate everyone into a single provider, or build and operate their own identity broker to sit in front of multiple providers. That's the kind of thing that quietly adds operational overhead over time.

What changes

Once your cluster runs Kubernetes 1.32 or later, you can associate up to 10 OIDC providers directly. Employees can keep using their internal IdP, contractors can use a different one, and CI/CD systems can use yet another, all while authenticating with the provider they're already used to.

The biggest win here is that you no longer need to build and run a separate identity broker, or migrate everyone onto one shared provider. Since your existing IAM authentication keeps working the whole time, you can add external OIDC providers incrementally without disrupting what's already in place.

Dive Deep

Let's go a bit deeper into the setup details.

• Limits and version requirements: The 10-provider limit only applies to clusters on Kubernetes 1.32 or later. Clusters on earlier versions are still capped at one provider.
• Configuration size limit: The combined size of all associated OIDC provider configurations must stay under 12 KB.
• Uniqueness constraints: The issuer URL and name must be unique across all providers on a cluster, and you can't associate the same provider twice.
• Associating is a cluster update: Associating a provider is treated as a cluster update, so the cluster enters an UPDATING state. It can take several minutes to fully apply, and you can track progress with the DescribeUpdate API.

The User Guide also lists best practices for running multiple providers.

• Set a usernamePrefix and groupsPrefix for each provider so usernames and group names from different providers don't collide (or alternatively, make sure the claims themselves are unique per provider if you skip prefixes)
• Use requiredClaims to specify claims that must be present in the ID token, so your cluster only accepts tokens you've explicitly authorized
• Limit the claims your identity provider issues in tokens to the minimum needed, to reduce exposure if a token is ever compromised

You can also set this up through eksctl, using a YAML file like this.

identityProviders:
  - name: my-provider
    type: oidc
    issuerUrl: https://example.com
    clientId: kubernetes
    usernameClaim: email
    usernamePrefix: my-username-prefix
    groupsClaim: my-claim
    groupsPrefix: my-groups-prefix

eksctl associate identityprovider -f associate-identity-provider.yaml

On the security side, you can restrict who's allowed to associate which OIDC providers using an IAM policy on the eks:AssociateIdentityProviderConfig action. The docs even show an example using the eks:issuerUrl and eks:clientId condition keys to deny any provider that isn't explicitly allowed.

A few things to keep in mind: IAM authentication can't be disabled, since it's still required for nodes to join the cluster, and the cluster itself must still be created by an IAM principal rather than an OIDC-authenticated user. Users authenticated through an OIDC provider also can't sign in to the AWS Management Console; viewing Kubernetes resources in the console still requires signing in with an AWS account.

Wrap-up

• Amazon EKS now supports up to 10 external OIDC identity providers per cluster (on Kubernetes 1.32+; earlier versions stay capped at one)
• Different user populations, like employees, contractors, and CI/CD systems, can now use their own identity providers directly, without consolidation or an identity broker
• Existing IAM authentication keeps working alongside every provider, and setup is available through the AWS Management Console or the AssociateIdentityProviderConfig API (including eksctl)
• It's available at no extra cost in every Region where EKS runs

If your team has multiple user populations and has been wrestling with running an identity broker, this update is worth a look!