AWS IAM Roles For Kubernetes Service Accounts (IRSA)

In the world of Kubernetes and AWS, managing access to AWS resources from your Kubernetes cluster can be tricky. That’s where AWS IAM Roles for Service Accounts (IRSA) comes in — a feature that helps bridge the gap between Kubernetes and AWS, providing a secure and efficient way to grant AWS permissions to your Kubernetes workloads.
This article explains what IRSA is, why it’s important and how to configure it in your Amazon EKS cluster.

Understanding AWS IAM Roles for Service Accounts

Traditionally, to give Kubernetes pods access to AWS resources, you would attach an IAM role to the EC2 instances in your cluster. However, this approach has limitations:

1. All pods on a node share the same IAM role.
2. Pods might have more permissions than necessary, violating the principle of least privilege.

Another solution involves creating IAM users, generating access keys, and mounting these keys to your pods. While this offers more granular control, it also presents challenges:

• It’s not Kubernetes-native, potentially complicating deployments and management.
• It requires careful code maintenance to ensure secure mounting of credentials.
• Managing short-lived credentials can be challenging. (For more details on this, refer to this article .)

IRSA solves these problems by allowing you to associate an IAM role with a Kubernetes service account. This means:

- You can have fine-grained access control at the pod level.
- Different pods on the same node can have different IAM roles.
- You can manage AWS permissions using native Kubernetes concepts.

How IRSA Works

IRSA leverages OpenID Connect (OIDC) for authentication. Here’s a simplified flow on how it works:

1. You set up the OIDC provider for the EKS cluster in AWS IAM.
2. You create an IAM role with necessary permissions and configure its trust relationship to allow assumption by the Kubernetes service account.
3. You create a Kubernetes service account and annotate it with the IAM role ARN.
4. You create a pod specification that uses this service account.
5. Kubernetes creates the pod and injects the service account’s JWT token into it.
6. The pod starts, and an application within it needs to access an AWS resource.
7. The application calls the AWS STS service, providing the JWT token.
8. AWS STS verifies the token with the OIDC provider and checks it against the IAM role’s trust policy.
9. If valid, AWS STS returns temporary AWS credentials to the pod.
10. The application uses these temporary credentials to access AWS resources as permitted by the IAM role.
11. The credentials expire after a short period, and the process repeats from step 7 when new credentials are needed.

Setting Up IRSA

Let’s go through the steps to set up IRSA in your EKS cluster:

1 — Set up an OIDC provider for your EKS cluster

This step is crucial and often overlooked. You need to create an IAM OIDC identity provider that corresponds to your EKS cluster’s OIDC issuer URL.

Get the OIDC issuer URL

  export OIDC_ISSUER=$(aws eks describe-cluster --name <your-cluster-name> --query "cluster.identity.oidc.issuer" --output text) 

Or you can retrieve from the EKS console

Then create the IAM OIDC identity provider :

     aws iam create-open-id-connect-provider \  
        --url $OIDC_ISSUER \  
        --client-id-list sts.amazonaws.com \

2 — Create an IAM role

Now, create an IAM role that your Kubernetes service account will assume. The trust policy should look like, save it to a file trust-policy.json

    {  
        "Version": "2012-10-17",  
        "Statement": [  
            {  
                "Effect": "Allow",  
                "Principal": {  
                    "Federated": "<open-id-connect-provider>"  
                },  
                "Action": "sts:AssumeRoleWithWebIdentity",  
                "Condition": {  
                    "StringEquals": {  
                        "oidc.eks.<aws-region>.amazonaws.com/id/<openid-connect-id>:sub": "system:serviceaccount:<namespace>:<service-account>",  
                        "oidc.eks.<aws-region>.amazonaws.com/id/<openid-connect-id>:aud": "sts.amazonaws.com"  
                    }  
                }  
            }  
        ]  
    }

    "StringEquals": {  
                        "oidc.eks.<aws-region>.amazonaws.com/id/<openid-connect-id>:sub": "system:serviceaccount:<namespace>:<service-account-name>",  
                        "oidc.eks.<aws-region>.amazonaws.com/id/<openid-connect-id>:aud": "sts.amazonaws.com"  
                    }

Now create the role and specify the trust policy above:

    aws iam create-role -role-name <role-name> -assume-role-policy-document file://trust-policy.json

And then attach the necessary policies you want to IAM role to have, for example here we want to have a Read Only access to all s3 buckets in the account using the AWS managed policy arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

    aws iam attach-role-policy -role-name <role-name> -policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

3 — Create a Kubernetes service account

Create a service account in your Kubernetes cluster and annotate it with the IAM role ARN you created previously in step 2 — .

    apiVersion: v1  
    kind: ServiceAccount  
    metadata:  
      name: my-service-account  
      namespace: default  
      annotations:  
        eks.amazonaws.com/role-arn: <role-arn>

4 — Use the service account in your pod

Finally, use this service account in your pod specification:

    apiVersion: v1  
    kind: Pod  
    metadata:  
      name: my-pod  
    spec:  
      serviceAccountName: <service-account-name>  
      containers:  
      - name: my-container  
        image: my-image

5 — Verifying the Setup

To verify that IRSA is working correctly:

1. Deploy a pod using the service account you created.

  kubectl apply pod.yaml

2. Exec into the pod and use the AWS CLI to try accessing the resources you’ve granted permissions for.

    kubectl exec -it my-pod -n default -- aws s3 ls

6 — Use Terraform

You can use this module to create the IRSA role properly and attach the policies you need to them.

terraform-aws-iam/modules/iam-role-for-service-accounts-eks

Conclusion

AWS IAM Roles for Service Accounts provide a powerful way to manage AWS permissions for your Kubernetes workloads. By following the steps outlined in this guide, you can set up IRSA in your EKS cluster and enjoy more granular, secure access control. Remember, the key to a successful IRSA setup lies in properly configuring the OIDC provider and creating well-defined IAM roles and Kubernetes service accounts.

AWS IAM Roles For Kubernetes Service Accounts(IRSA) was originally published in AWSMorocco on Medium, where people are continuing the conversation by highlighting and responding to this story.