How to use AWS IAM ROLES for service accounts (IRSA)

IAM roles (Identity Access Management)

In Kubernetes, role-based access control is a key method for securing your cluster. If you’re running your 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 is that all modules running on a Kubernetes node share the same set of permissions, which can cause a least-privilege violation.

What is IRSA ( IAM roles for service account) ?

IAM Roles for Service Accounts (IRSA) is an AWS feature that allows you to leverage IAM roles at the pod level by combining OpenID Connect (OIDC) identity providers with Kubernetes service account annotations.

How it works

You can attach IAM roles to your Kubernetes PODs without using third-party software such as kube2iam or kiam. This is due to AWS IAM and Kubernetes Service Account integration following his IAM role (IRSA) approach for service accounts.

Benefits

Using IRSA in your Kubernetes POD has several advantages.

• Detailed limits (per cluster, per namespace, etc.).
• More flexible than other tools.
• One less point of failure (perhaps fewer).
• Less resource consumption.
• more pods per node.
• Latency can be reduced by up to 50 ms.
• Prevent credential caching issues.
• Better Audit.
• Easy to set up
• Full support provided by the aws.

How to setup

There are several setting methods, but I will introduce how to do it with a shell script.

In the following script we will create:

• Create an AWS OpenID Connect provider.
• Associate the OIDC provider with the EKS OIDC URL.
• Attach the IAM policy.
• Create a Kubernetes service account.
• Create a yaml file.
• We will run one kubernetes job.

Now we can run the following script:

$ ./filename.sh  -n  ${name of service account}  -c  ${cluster name}

#!/bin/bash
 
# Using getopts function
 
while getopts n:c: option
do
    case "${option}"
        in
        n)name=${OPTARG};;
        c)cluster=${OPTARG};;
       
    esac
done
 
 
 export policyname=$(  aws iam list-policies --query 'Policies[?PolicyName==`AmazonS3ReadOnlyAccess`].Arn' --output text)
 
# Retrieve open id connect issuer url
aws eks describe-cluster --name $cluster  --query cluster.identity.oidc.issuer --output text
 
 
# Create your IAM OIDC identity provider for your cluster
eksctl utils associate-iam-oidc-provider --cluster $cluster  --approve
 
 
# Now create I am role bound to a service account with read only access to s3
eksctl create iamserviceaccount \
    --name $name \
 

 --namespace default \
    --cluster $cluster \
    --attach-policy-arn $policyname \
    --approve \
    --override-existing-serviceaccounts
 
cat <<EoF> job-s3.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: eks-iam-test-s3
spec:
  template:
    metadata:
      labels:
        app: eks-iam-test-s3
    spec:
      serviceAccountName: $name
      containers:
      - name: eks-iam-test
        image: amazon/aws-cli:latest
        args: ["s3", "ls"]
      restartPolicy: Never
 
EoF
 
kubectl apply -f ./job-s3.yaml
 
kubectl get job -l app=eks-iam-test-s3
kubectl logs -l app=eks-iam-test-s3

By using the IAM Roles for Service Accounts feature, you no longer need to grant elevated permissions to a node’s IAM role to allow Pods on that node to call AWS APIs. IAM permissions can be assigned to a service account, and only pods using that service account can access those permissions. This feature also eliminates the need for third-party solutions such as kiam and kube2iam.

Committed to Delivering the best

Thousands of AWS and CNCF-certified Kubernetes solution partners have unique expertise and focus areas. Our focus is on best practices in security, automation, and excellence in Cloud-based operations.

Please reach out to us if you have any questions.