AWS Fine-Grained IAM Roles for Service Accounts

Adi Sapir, VP R&D, Alcide

Since we last posted our blog IAM Role Pod Delegation Checks on AWS Kubernetes Clusters, AWS made pods first class citizens in IAM introducing a new service called IRSA — IAM Roles for Service Accounts.

This service allows users to define IAM roles for the Kubernetes Service Accounts and replaces open source solutions such as kube2iam, kiam, and Zalando’s IAM controller.

The solution approach is a little different then the one intoduced by kiam and kube2iam. While kiam and kube2iam are running an agent that intercepts access to AWS on each node in the Kubernetes cluster, thus allowing cluster users to associate IAM roles to Pods by annotating the IAM role in the Pod definition (see below), IRSA takes a different angle.

By using the IRSA the user can associate the IAM role directly with Kubernetes service account, enabling the Pod service account to use both Cluster Roles and AWS IAM roles.

The AWS access token is placed in a Kubernetes secret.

The AWS access requires including some updates of the AWS SDK included in the application code. These code included in the AWS SDK uses environment variables that are automatically placed into the Pod configuration by a mutating Admission Controller provided by AWS.

Here is how the end deployment looks like after the modification done by the Admission Control:

Bottom Line

When an access to an AWS account is made the AWS SDK calls AWS STS (Security Token Service) and generates a temporary access token that is used for accessing the required resource.

The following link provides a detailed information related to the operation and use of AWS IRSA: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html