Following my earlier article on Demystifying Federated Identity Management (FIM) and Its Clever Use in EKS, this piece dives deeper into how AWS IRSA leverage FIM inside EKS.

EKS and about IRSA: EKS is a managed Kubernetes service offered by Amazon Web Services (AWS) that simplifies the deployment, management, and scaling of containerised applications using Kubernetes. Whereas IRSA is a feature in EKS that allows kubernetes pods to securely assume IAM role to access AWS resources.

Imagine a scenario where you are running an application inside a pod, and that application needs to access an S3 bucket to list some resources. Providing long-term/permanent credentials to application to access AWS resources wouldn’t be prudent approach. Short term credentials, with limited access to particular s3 bucket — no easy way to achieve that.

What if we can assume a role( having restrained permission) directly from a pod? BUT dont overlook the fact that we can’t assume a role unless we are already authenticated with AWS.

IRSA comes to solve exactly that, which functions on top of Federated identity management — in a very cunning way. Let me walk us through each step of how the pod initiates and authenticated requests to assume an IAM role.

But before we get into too much details, let me give you a refresher of how does identity and authentication works in kubernetes.

Background: Kubernetes Service Accounts

Kubernetes has this concept of Service Account, which is a kind of non-human entity, that provides a distinct identity in a kubernetes cluster. Pods, system components and other entities can get access to kubernetes’s api by getting access to Service Account Credentials (service account token).

With Service Account, pod gets an identity which is limited to kubernetes cluster. Kubernetes OIDC server generates a JWT token for service account, which then gets mounted inside a pod at /var/run/secrets/kubernetes.io/serviceaccount/ .
Pod uses this token to authenticate while calling the kube-api-server.

Now that we understand how Service Accounts work in Kubernetes, let’s see how IRSA extends this mechanism into AWS IAM.

Enter IRSA (IAM Roles for Service Accounts):

IRSA extend this concept by using some magic of Identity Federation to let the pod use the same service_account token to assume AWS IAM role and access AWS resources. Using IRSA in EKS is quite simple, annotate the Service Account with the IAM role ARN, the service account wants to use.

after this step, the pods get the service account token, mounted at

/var/run/secrets/eks.amazonaws.com/serviceaccount/

Lets assume that we are deploying our application in kubernetes called “best-app”. if we navigate to the /var/run/secrets/eks.amazonaws.com/serviceaccount path inside a best-app pod, we would find a token file, containing a JWT token — when decoded, looks similar to this

{
  "aud": [
    "sts.amazonaws.com"
  ],
  "exp": 1234567890,
  "iat": 1234567890,
  "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E",
  "jti": "best-app_jti_uuid",
  "kubernetes.io": {
    "namespace": "dummy-namespace",
    "node": {
      "name": "dummy-node-name.compute.internal",
      "uid": "dummy_node_uid"
    },
    "pod": {
      "name": "best-app",
      "uid": "best-app_uid"
    },
    "serviceaccount": {
      "name": "best-app-service-account",
      "uid": "best-app_service_account_uid"
    }
  },
  "nbf": 1234567890,
  "sub": "system:serviceaccount:dummy-namespace:best-app-service-account"
}

this is an OIDC JWT token issued by EKS OIDC server to the service account associated with best-app pod.

the best-app pod uses that token while calling the https://sts.amazonaws.com to assume a role with permission to access S3 bucket. Who issued that token? and how AWS STS trust this token.

Lets walkthrough each step of how the trust establishes.
the best-app pod uses that token while calling the https://sts.amazonaws.com to assume a role with permission to access S3 bucket. Who issued that token? and how AWS STS trust this token.

Step: 1: EKS OIDC Provider Setup

when you create an eks cluster, AWS automatically provisions an OIDC issuer endpoint for your cluster. looks similiar to

https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E

This OIDC endpoint is hosted by your eks (which is essentially your cluster Idp) — exposes some metadata at /.well-known/openid-configuration we will see later down the road why it is needed.

Step: 2: Establish trust in AWS IAM

2.1: Registering EKS OIDC Server in IAM
in this scenario, AWS STS is an SP(service provider) which need to trust the external Idp provider, we create this trust in AWS IAM by registering EKS OIDC Server as trusted Identity Provider in IAM.

aws iam create-open-id-connect-provider \\
--url <https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E> \\
--client-id-list [sts.amazonaws.com](<http://sts.amazonaws.com/>) \\
--thumbprint-list <thumbprint>

it will allow STS to trust any JWT token signed by the CA having the provided thumbprint, where the issuer is

https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E](<https://oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E>)  and the client/aud will be sts.amaznaws.com

and the client/aud will be sts.amaznaws.com

2.2- Creating a Trust Policy in IAM role

You define a trust policy that restricts which Kubernetes Service Accounts can assume the role. Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<account-id>:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/EXAMPLE..."
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-west-2.amazonaws.com/id/EXAMPLE...:sub": "system:serviceaccount:my-namespace:best-app-serviceaccount"
        }
      }
    }
  ]
}

Step 3: Pod Uses Projected ServiceAccount Token

pod uses the token projected at

/var/run/secrets/eks.amazonaws.com/serviceaccount/token

Step 4: Pod Makes STS AssumeRoleWithWebIdentity Call

pod using the AWS SDK initiates the request to STS, which looks something like this

aws sts assume-role-with-web-identity \
 — role-arn arn:aws:iam::123456789012:role/BestAppRole \
 — role-session-name best-app-session \
 — web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token \
 — duration-seconds 3600

Step 5: STS Validates the OIDC Token

STS validates that the OIDC token is issued by the trusted IDP(step 2) and checks the integrity of the token by verifying its signature using a public key exposed at <OIDC_URL/keys>

https://oidc.eks.ap-southeast-1.amazonaws.com/id/3C093DFA14C1920DF318FFCC16EB8450/keys

Step 6: STS returns the temporary Credentials

STS return a response, which looks similiar to

{
 “Credentials”: {
 “AccessKeyId”: “ASIA….”,
 “SecretAccessKey”: “wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY”,
 “SessionToken”: “IQoJb3JpZ2luX2VjE…”,
 “Expiration”: “2025–09–25T20:45:07Z”
 },
 “AssumedRoleUser”: {
 “AssumedRoleId”: “ARO123EXAMPLE:best-app-session”,
 “Arn”: “arn:aws:sts::123456789012:assumed-role/BestAppRole/best-app-session”
 }
}

The entire flow looks like this

this illustration summarizes the entire end-to-end flow we discussed in this article. it may seem overwhelming at first, but as you start to get a grasp of the concept. It will start to make sense and becomes a reference point for you in future.

IRSA is widely adopted today and enables the team to architect a robust solution while designing system on EKS and AWS. It enables the kubernetes entities to leverage the fine-grained access control provided by AWS IAM role, streamlining secure access to AWS resources.

In this article, we introduced IRSA, explained its foundations in Federated Identity Management, and traced the request flow between EKS and AWS.

Now that you have learned about the inner workings, I am leaving a question for you. How would you replicate IRSA in a self-hosted Kubernetes cluster running on AWS? Can you enable to pods inside your self-hosted kubernetes cluster to assume IAM role?

Let me know what solution you come up with, I hope it helped you get a good grasp of FIM and related concepts. Feel free to gift your feedbacks and suggestions.

Chances are you’ve already encountered Single Sign-On (SSO), OAuth, OIDC, or JWT in your work.

These days, the ecosystem of tutorials and playbooks has become so rampant that one often only needs to follow a quick 5–7 step guide to achieve a task. The rise of LLM-based chat agents has further exacerbated this trend. Whether or not this is a bad thing is debatable, but one thing is certain: engineers are now less focused on truly understanding the technology and more focused on simply moving the ticket from ‘in-progress’ to ‘done.’.

While having the superpower of search engine and now intelligent chat engines help quickly move the tickets but they also make us susceptible to overlooking the remarkable technology and architectural thinking behind the tools we use

In this article, I will walk you through the simple yet brilliant concepts behind federated identity management. By the end, you should be able to clearly distinguish its features and find your way out of the quagmire of vague explanations around SSO and FIM

A textbook definition of FIM is
“Federated Identity Management (FIM) allows users to access multiple systems and applications across different organizations or domains using a single set of credentials”

At first, this definition may sound confusing, but once you get the hang of it, it starts to make sense.

Lets start with SSO

What is Single Sign-On (SSO)

Chances are, you’ve encountered SSO when logging into your organisation’s internal apps via a central portal. SSO is a paradigm that lets you seamlessly access multiple applications under a “SINGLE” organisation without needing to re-authenticate or maintain separate credentials for each one. It leverages protocols like OIDC and SAML to enable frictionless authentication.

What is Federated Identity Management (FIM)?

What exactly does FIM do? Explaining identity federation in simple terms isn’t easy, so first I’ll introduce two basic terms we’ll use throughout this article

Identity Provider (IdP) — An IdP is an entity/service that creates and manages user identities and authenticates users to other applications that rely on it. For example, Okta, Authelia, or Google can act as an IdP

Service Provider/ Relying Party : A service provider (SP/RP) is an entity that provides services to a user. it could be a SaaS application, a web service provider or a partner organisation. For example, Medium website (when it prompts the user to login via any social website).

Federated Identity Management uses many of the same protocols, but it introduces a paradigm that enables authentication across organisations. In essence, FIM establishes trust (a federation) between an IdP and an SP, so a user can authenticate once and then access resources across both domains without logging in again.

When two domains are federated, a user can authenticate to one domain and then access resources in the other domain without having to perform a separate login process.

Lets Understand it With the help of a Scenario:

Imagine an employee at Company A who logs in once each morning through the Company B’s SSO provider (say Keycloak, Authelia, etc.) to access all internal portals and applications. Now image a Company A has recently onboarded a SaaS application from Company B for its employees. While the SaaS offers its own signup mechanism, but, it would be extremly inconvenient for, say, 1000 users to create an account for that tool.

So? Could there be a way that Company A’s employees login once with Company B’s IdP and “automagically” get access to the SaaS tool?

Federated identity management exactly solves that by establishing trust between Organisation A and Organisation B.

In this case, Company A acts as an Identity provider (IdP) and the Company B’s SaaS act as (SP/RP) service provider. As part of the their trust agreement, Company A’s IdP registers the Company B’s application as a trusted client. This way, when a user needs access to SaaS, the SP can redirect the user to Company A’s Idp portal for authentication. The SP then uses the IdP’s published JWKS (JSON Web Key Set) to verify the authenticity of the token issued by IdP.

As Part of the Standard, the IdP also exposes a “discovery document” (usually at an endpoint like https://idp.example.com/.well-known/openid-configuration This is the JSON document containing the IdP’s public configuration, such as URL of the authorisation server, token endpoints and the location of its JWKS keys.

this is a sample json document returned by this endpoint contains

{
"issuer": "https://login.companyA.com",
"authorization_endpoint": "https://login.companyA.com/oauth2/authorize",
"token_endpoint": "https://login.companyA.com/oauth2/token",
"jwks_uri": "https://login.companyA.com/.well-known/jwks.json",
...
}

• The SP fetches this JWKS URL and caches the keys.

This process proves to the RP:

Any id_token signed with one of these keys truly came from Company A’s IdP.

The entire end to end flow looks like

Federated Identity Management is widely adopted today, and chances are you’re already using it without realising it. One clever implementation is in AWS EKS with IRSA (IAM Roles for Service Accounts).

In this writeup, we learned about the subtle difference b/w SSO and FIM and briefly peeked into the working of how the underlying protocol actually works. Now, the next time, you click on “Signin with Google” button on a website, you’ll know what is happening behind the scenes.

I hope it helped you get a good hang of the concept. In the next article, we will discuss the intricacies and specifics about EKS’s use of FIM — specifically how the trust establishes b/w the two entities such that a pod gets access to the allowed AWS resources. Until then stay tuned and feel free to share your feedback.