Amazon EKS: IAM Roles for Service Accounts (IRSA)

In Kubernetes, Role-Based Access Control is a key method for making your cluster secure. If you are running the cluster on AWS Elastic Kubernetes Service (EKS), Identity and Access Management (IAM) also allows you to assign permissions to EC2 instances (Kubernetes nodes) to restrict access to resources. The problem here is that all pods running on the Kubernetes node share the same set of permissions and this can cause a violation of the least privilege principle. So how to figure it out?

Kubernetes Security - EKS IRSA - 4


Although there are some tools like kiam or kube2iam developed by the community, this post will explain what IAM Roles for Service Accounts (IRSA) is and how to enable it on your EKS cluster.


What is IRSA?

IAM Roles for Service Accounts (IRSA) is a feature of AWS which allows you to make use of IAM roles at the pod level by combining an OpenID Connect (OIDC) identity provider and Kubernetes service account annotations.


Kubernetes Security - EKS IRSA_1

Image source: https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/



Enabling IRSA on the EKS cluster

Before starting the setup, check your EKS cluster version. IRSA is available on Amazon EKS versions 1.14 or later. To use this feature, you need to update your existing cluster to version 1.14 or later.

Example Scenario: Let’s assume we need to list IAM groups in our pods and we have the following configuration:

apiVersion: v1

kind: Pod

metadata:

  name: eks-irsa-test

  namespace: blogpost-demo

spec:

  containers:

  - name: eks-irsa-test

    image: amazon/aws-cli:latest

    command: ["sleep"]

    args: ["3600"]

  restartPolicy: Never


Save this configuration as pods-irsa.yaml and apply:

Kubernetes Security - EKS IRSA - 2

The pod runs a container of the image amazon/aws-cli:latest with the command "sleep 3600" which allows the container to run at least 3600 seconds so that we can get into the shell in the container and run aws cli commands.

Before moving on to how we enable IRSA, let’s first check if the current pods can list IAM groups.

Kubernetes Security - EKS IRSA - 3


Step 1: Create an IAM OIDC identity provider for your cluster

EKS clusters have an OpenID Connect issuer URL associated with them. To use IAM roles for service accounts, an IAM OIDC provider must exist for the cluster. Use the command below to create your OIDC identity provider for your cluster. Be sure that you are using eksctl version 0.32.0 or later.

eksctl utils associate-iam-oidc-provider --cluster eu-test --approve

Kubernetes Security - EKS IRSA - 6


Step 2: Create a Kubernetes service account and setup IAM role

We need an IAM role with a specified policy attached and a Kubernetes service account annotated with that IAM role. Use the following command to do all these steps at once.

eksctl create iamserviceaccount \

               --name list-iam-groups \

               --namespace blogpost-demo \

               --cluster eu-test \

               --attach-policy-arn arn:aws:iam::aws:policy/IAMReadOnlyAccess \

               --approve


Kubernetes Security - EKS IRSA - 5



Step 3: Setup pods

Now we have the service account and the IAM role. Let's configure the pod spec to use the service account.

Edit pods-irsa.yaml as below:

apiVersion: v1

kind: Pod

metadata:

  name: eks-irsa-test

  namespace: blogpost-demo

spec:

  serviceAccountName: list-iam-groups

  containers:

  - name: eks-irsa-test

    image: amazon/aws-cli:latest

    command: ["sleep"]

    args: ["3600"]

  restartPolicy: Never


and apply again:

Kubernetes Security - EKS IRSA - 2


The resulting pods should list IAM groups:

Kubernetes Security - EKS IRSA - 7


We hope this post helps you make your EKS clusters more secure and use Kubernetes service accounts effectively on AWS.

We also offer a Kubernetes Security Audit; if you’d like to hear more about it, please take a look at our Kubernetes Security Audit page.

Leave a Comment