AWS IAM: EKS Pod Identity vs OpenID Connect Comparison

AWS Identity and Access Management (IAM) is a service offered by Amazon Web Services (AWS) that provides a secure way to control access to AWS resources. IAM allows you to manage users, groups, and roles that can access and interact with your AWS infrastructure. Before we get started, lets do a quick overview of AWS IAM, or you can skip to the good stuff by clicking Implementing AWS EKS Pod Identity on the table of contents.

What is AWS Identity and Access Management?

Let’s go over some AWS terminology. AWS Identity and Access Management (AWS IAM)  provides centralized identity management and access control for AWS resources. AWS IAM focuses on Role Based Access Control (RBAC), which allows you to create and manage AWS users, groups, and roles, and assign permissions to them.

Users are individuals who interact with AWS resources. They can be either humans or services that require access to your AWS environment. Users are identified by unique credentials, such as usernames and passwords, MFA and other forms of authentication. Regardless, all connected entities are establishing some sort of session which includes temporary access keys.

Groups are collections of users. They allow you to manage permissions for multiple users collectively. By assigning permissions to groups, you can grant or revoke access to a set of users simultaneously.

Roles, on the other hand, are similar to users but are not associated with a specific individual, however as best practice it is recommended to define the purpose of a role to a specific function/service. Roles are assumed by entities such as users or applications. They define the permissions an application or service can have while interacting with your AWS resources.

However, managing Identity and Access Management (IAM) permissions within Amazon Web Services’ Elastic Kubernetes Service (EKS) can be akin to navigating a labyrinth. In this article, we’ll will compare AWS EKS Pod Identity methodology to the OIDC from a practical viewpoint, as in what it actually takes to get started.But first, let's make clear what are AWS Identity and Access Management, AWS EKS POD Identity and OIDC.

What is AWS IRSA and why do you need it?

Regardless of the method of authentication, Kubernetes on AWS or any other service for that matter requires some form of recognition of the entity that uses them in order to assign it the correct permissions. In EKS specifically, the form of permission allocation is done by IAM roles for service accounts (IRSA), which creates a correlation, basically an abstraction, between the Kubernetes native terminology of “service accounts” and the AWS identity management center and its “IAM entities”. This connection allows an EKS administrator to assign IAM roles and permissions to Kubernetes native service identities.

As organizations embrace the scalability and flexibility offered by EKS for their containerized applications, the intricacies of IAM permissions often emerge as a significant challenge, in part due to AWS’s often clunky implementation of IAM roles for service accounts (IRSA), which requires setting up an OpenID Connect (OIDC) identity provider.

These moving components can cause a headache when it comes to implementing them in DevOps best practices such as DRY (Don’t Repeat Yourself), IaC (Infrastructure as Code), Code Reusability and Generic Templating.

Challenges of OpenID Connect (OIDC) identity provider

OpenID Connect (OIDC) is an open standard for user authentication and authorization. It allows web and mobile applications to verify the identity of the end-user based on their credentials. OIDC can be used as an identity provider for EKS clusters, allowing you to authenticate and authorize users to access Kubernetes resources.

However, as mentioned using OIDC as an identity provider introduces some challenges, the most obvious of which is the maintenance of yet another cloud resource such as the identity provider.

In attempts to remove some of the challenges that come with implementing IRSA and the complexity of OIDC, as aforementioned, one might think if there is a simpler way of creating this Kubernetes to IAM abstraction layer of permissions. Luckily, AWS has heard the complaints of many customers and issued a new method of providing permissions on Kubernetes using AWS IAM terminology, called “Pod Identities”.

What is AWS EKS Pod identity?

Amazon EKS Pod Identities, introduced at last year's AWS re:Invent conference has provided an interesting new way to help manage Kubernetes permissions. This feature enhances container orchestration by streamlining the process of managing access to resources.AWS EKS Pod Identity, an evolution from “IRSA”, simplifies IAM permission management for EKS clusters by removing OIDC limitations, shifting to a unified trust policy (pods.eks.amazonaws.com), supporting STS session tags for granular access control, and separating AWS and Kubernetes API concerns, meaning, for example, that you can use a single IAM role in multiple clusters.

Implementing AWS EKS Pod Identity

In the following section, we’ll implement Pod Identity from scratch on a simple vanilla EKS cluster. We’ll use common tools and practices on order to provide basic AWS IAM credentials to a basic Kubernetes native service account. Using this method, we’ll achieve this with some common tools and the least possible effort.

NOTE: The code examples for the below guide are available in our GitHub Repository.

Getting Started — Requirements

Before moving on to evaluation, we need the basic components that allow for the usage of this feature:

• An EKS Cluster, with an AWS Profile that has permissions for Read/Write into it.

• An IAM Role we’d Like to give to our Pods, Such as:

• A Kubernetes Workload, connected to a Kubernetes Service Account. You do not need direct access to Kubernetes if you have a deployment mechanism in place, such as ArgoCD or any API abstraction layer.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-service-account
  ...

‍

A Hands-on Comparison

In the following section, we will compare the two methodologies from a practical viewpoint, as in what it actually takes to get started. The main components are the Service Account, the Trust Policy, and the Authentication Mechanism behind it all. The following will provide examples of provisioning these resources through IaC using YAML, IAM Policy Syntax and Terraform respectively.

The IRSA Method:

The Pod-Identity Method:

Side-By-Side Comparison

• The Service Account

apiVersion: v1
kind: ServiceAccount
metadata:
 annotations:
   eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
 name: my-service-account

The service account stays the same in the two methodologies. It annotates a reference to an AWS IAM role.

Note: IRSA allows cross-account roles, but currently Pod-Identity does not support it.

• The Trust Policy

In IRSA, we had to explicitly provide the hard-coded value of the OIDC provider inside the trust policy.

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Allow",
     "Principal": {
       "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.region-code.amazonaws.com/id/EXAMPLE"
     },
     "Action": "sts:AssumeRoleWithWebIdentity",
     "Condition": {
       "StringEquals": {
         "oidc.eks.region-code.amazonaws.com/id/EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
         "oidc.eks.region-code.amazonaws.com/id/EXAMPLE:aud": "sts.amazonaws.com"
       }
     }
   }
 ]
}

However, the following is the main improvement in Pod-Identity. All we have to provide is a unified trust policy that allows an IAM to be used by an EKS cluster in general, which means ANY EKS cluster (in the same account).

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
     "Effect": "Allow",
     "Principal": {
       "Service": "pods.eks.amazonaws.com"
     },
     "Action": [
       "sts:AssumeRole",
       "sts:TagSession"
     ]
   }
 ]
}

The Authentication Mechanism

As we’ve previously noted, the mechanism behind the scenes is different. In IRSA, the external OIDC provider for IAM we create in AWS is the authority for allocating credentials between different Kubernetes service Roles. In the following example in Terraform, we assume that we have previously created an EKS cluster, and use its issuer certificate in order to authorize an OpenID Provider (OIDC), which we provide as an input to a Role we’d like to use in the cluster.

data "tls_certificate" "example" {
 url = aws_eks_cluster.example.identity[0].oidc[0].issuer
}


resource "aws_iam_openid_connect_provider" "example" {
 client_id_list  = ["sts.amazonaws.com"]
 thumbprint_list = [data.tls_certificate.example.certificates[0].sha1_fingerprint]
 url             = data.tls_certificate.example.url
}


data "aws_iam_policy_document" "example_assume_role_policy" {
 statement {
   actions = ["sts:AssumeRoleWithWebIdentity"]
   effect  = "Allow"


   condition {
     test     = "StringEquals"
     variable = "${replace(aws_iam_openid_connect_provider.example.url, "https://", "")}:sub"
     values   = ["system:serviceaccount:kube-system:aws-node"]
   }


   principals {
     identifiers = [aws_iam_openid_connect_provider.example.arn]
     type        = "Federated"
   }
 }
}

In the Pod-Identity method, because the components we use are managed by AWS, there are two major additions to the resource pool, but a reduction in what we called “hard-coded” resources:

resource "aws_eks_addon" "pod-identity-agent" {
 cluster_name             = aws_eks_cluster.example.name
 addon_name               = "eks-pod-identity-agent"
 addon_version            = "v1.0.0-eksbuild.1"
 resolve_conflicts        = "OVERWRITE"
}


resource "aws_eks_pod_identity_association" "example" {
 cluster_name    = aws_eks_cluster.example.name
 namespace       = "example"
 service_account = "example-sa"
 role_arn        = aws_iam_role.example.arn
}

The Bottom Line

‍

The thing to note apart from Reusability and Ease of Setup, is that the Pod-Identity plugin for EKS automatically deploys a DaemonSet to each node in the EKS cluster. Each of these “agents” is essentially a central mechanism for authentication all pods in its node using AWS IAM API. This allows for a major advantage in Scalability, as described in the AWS documentation.

Pod-Identity Reduces load by having the EKS Auth service assume temporary credentials for EKS Pod Identity, lowering the load to once per node instead of duplicating it for each pod.

For further reading I suggest looking through the AWS Documentation. Here are some links to get you started with Pod-Identities:

• Pod Identity Association Terraform Resource
• AWS Feature Blog
  ‍

Amitai G is a freelance DevOps consultant with an extensive background in DevOps practices and Kubernetes' ongoing maintenance and operations. As the author of the @elementtech.dev Medium channel, he specializes in writing articles that provide engineers with a deeper understanding and best practice guidance across the various aspects of the Cloud Native landscape.