Lesson 07 — IAM Roles for Service Accounts (IRSA)

Learning Objectives

By the end of this lesson, you will be able to:

Understand what IAM Roles for Service Accounts (IRSA) is
Explain why IRSA is required in Amazon EKS
Understand how IRSA works
Learn the relationship between Kubernetes Service Accounts and AWS IAM Roles
Understand the role of OIDC and AWS STS
Identify common IRSA security risks
Apply enterprise best practices for workload identity

Why This Matters

Applications running inside Kubernetes often need to access AWS services.

Examples include:

Amazon S3
Amazon DynamoDB
Amazon SQS
Amazon SNS
AWS Secrets Manager
Amazon ECR
AWS KMS
Amazon CloudWatch

The question is:

How can a Pod securely access AWS services without storing AWS Access Keys inside the container?

Historically, developers embedded AWS credentials inside:

Source code
Docker images
Environment variables
Configuration files

This created serious security risks.

Amazon EKS solves this problem using IAM Roles for Service Accounts (IRSA).

What is IRSA?

IAM Roles for Service Accounts (IRSA) is an Amazon EKS feature that allows Kubernetes workloads to securely assume AWS IAM Roles.

Instead of storing AWS credentials inside Pods, workloads receive temporary AWS credentials automatically.

Application

↓

Service Account

↓

IAM Role

↓

Temporary Credentials

↓

AWS Service

This provides secure, cloud-native authentication.

Traditional Authentication (Not Recommended)

Older Kubernetes deployments often stored AWS credentials directly inside applications.

Application

↓

AWS Access Key

↓

AWS Secret Key

↓

Amazon S3

Problems include:

Hardcoded credentials
Credential theft
Difficult rotation
Shared secrets
Compliance issues

This approach should never be used in production.

Modern Authentication with IRSA

IRSA removes the need for static AWS credentials.

Application

↓

Service Account

↓

OIDC Provider

↓

AWS STS

↓

Temporary Credentials

↓

Amazon S3

No AWS Access Keys are stored inside the container.

Why IRSA is Important

IRSA provides several security benefits.

Without IRSA:

Static credentials
Difficult credential rotation
Shared AWS accounts
Weak auditing
High attack surface

With IRSA:

Temporary credentials
Automatic credential rotation
Fine-grained permissions
Better auditing
Least privilege access

Components of IRSA

IRSA relies on several AWS and Kubernetes components.

Amazon EKS

↓

OIDC Provider

↓

IAM Role

↓

Service Account

↓

AWS STS

↓

AWS Service

Each component contributes to secure workload authentication.

How IRSA Works

Authentication process:

Pod Starts

↓

Uses Service Account

↓

OIDC Token Generated

↓

AWS STS Validates Token

↓

IAM Role Assumed

↓

Temporary Credentials Issued

↓

Application Calls AWS APIs

This entire process is automatic and transparent to the application.

Step-by-Step IRSA Workflow

Step 1

Developer deploys an application.

↓

Step 2

Application uses a Kubernetes Service Account.

↓

Step 3

The Service Account is associated with an AWS IAM Role.

↓

Step 4

Amazon EKS issues an OIDC token.

↓

Step 5

AWS STS validates the token.

↓

Step 6

STS issues temporary AWS credentials.

↓

Step 7

Application accesses AWS securely.

OpenID Connect (OIDC)

IRSA depends on OpenID Connect (OIDC).

Amazon EKS creates an OIDC identity provider for every cluster.

Amazon EKS

↓

OIDC Provider

↓

AWS IAM Trust

The IAM Role trusts identities issued by this OIDC provider.

Without OIDC, IRSA cannot function.

AWS Security Token Service (STS)

AWS STS issues temporary AWS credentials after validating the workload identity.

OIDC Token

↓

AWS STS

↓

Temporary Credentials

↓

AWS Service

Temporary credentials:

Automatically expire
Cannot be reused indefinitely
Improve security
Reduce credential theft

IAM Trust Relationship

Every IAM Role used by IRSA includes a trust policy.

IAM Role

↓

Trust Policy

↓

OIDC Provider

↓

Specific Service Account

Only authorised Service Accounts can assume the IAM Role.

IRSA Architecture

                    Amazon EKS Cluster

              ┌────────────────────────────┐
              │        Application Pod      │
              │                             │
              │  Service Account            │
              └──────────────┬──────────────┘
                             │
                             ▼
                     OIDC Authentication
                             │
                             ▼
                        AWS STS
                             │
                             ▼
                       IAM Role
                             │
                             ▼
               Amazon S3 / DynamoDB / SQS

Applications authenticate without requiring embedded AWS credentials.

Enterprise Example

An image processing application uploads photographs to Amazon S3.

Architecture:

Image Processing Pod

↓

Service Account

↓

IAM Role

↓

AWS STS

↓

Temporary Credentials

↓

Amazon S3

IAM permissions:

Upload images
Read images
List bucket contents

Denied permissions:

Delete bucket
Manage IAM
Launch EC2
Modify networking

The application receives only the permissions it needs.

IRSA with AWS Secrets Manager

Many applications retrieve secrets from AWS Secrets Manager.

Application

↓

IRSA

↓

IAM Role

↓

AWS Secrets Manager

↓

Database Password

The password never exists inside the application image.

IRSA with Amazon DynamoDB

Order Service

↓

IRSA

↓

IAM Role

↓

Amazon DynamoDB

The application receives temporary permissions to read and update only its required DynamoDB tables.

IRSA with Amazon SQS

Payment Service

↓

IRSA

↓

IAM Role

↓

Amazon SQS

Only queue operations required by the application are permitted.

Enterprise Identity Architecture

Application

↓

Service Account

↓

RBAC

↓

OIDC Provider

↓

AWS STS

↓

IAM Role

↓

AWS Service

Kubernetes RBAC controls access to Kubernetes resources.

IAM controls access to AWS resources.

Together they provide complete workload identity.

Common IRSA Security Risks

Cloud Security Engineers commonly identify:

Shared Service Accounts
Overprivileged IAM Roles
Wildcard IAM policies
Default Service Accounts
Missing OIDC validation
Excessive AWS permissions
Unused IAM Roles
Weak trust policies
Overprivileged RBAC
Long-lived credentials still present

Misconfigured IRSA can allow workloads to access resources beyond their intended scope.

Enterprise Monitoring

Security teams should monitor:

IAM Role assumptions
AWS STS activity
OIDC authentication events
Service Account changes
IAM policy updates
Trust policy modifications
Failed AssumeRole requests
Unusual AWS API calls
RBAC changes
Privilege escalation attempts

CloudTrail and GuardDuty provide valuable visibility into IRSA activity.

Enterprise Example

A global healthcare provider runs patient management applications on Amazon EKS.

Each workload has its own identity.

Patient API

↓

Service Account

↓

Patient IAM Role

↓

AWS Secrets Manager

↓

Database Credentials

----------------------------

Image Service

↓

Service Account

↓

Image IAM Role

↓

Amazon S3

↓

Medical Images

Every workload receives only the permissions required for its business function.

This architecture improves:

Security
Compliance
Auditing
Operational efficiency

Best Practices

As a Kubernetes Security Engineer:

Create dedicated Service Accounts for every workload.
Implement IRSA for all production applications.
Follow the Principle of Least Privilege.
Use narrowly scoped IAM policies.
Never store AWS Access Keys inside Pods.
Enable CloudTrail logging.
Monitor AWS STS activity.
Review IAM trust policies regularly.
Rotate application permissions as requirements change.
Remove unused IAM Roles and Service Accounts.

IRSA should be the standard method for granting AWS permissions to Kubernetes workloads.

Real-World Scenario

A media company stores AWS Access Keys inside a Docker image used by several applications.

The image is accidentally published to a public container registry.

An attacker extracts the credentials and:

Downloads confidential data from Amazon S3.
Launches EC2 instances.
Reads DynamoDB tables.
Deletes backups.

After migrating to IRSA:

No AWS credentials exist inside container images.
Temporary credentials expire automatically.
IAM Roles restrict access to specific AWS resources.
CloudTrail records every AssumeRole event.

The organisation significantly reduces its attack surface and improves compliance.

Key Takeaways

After completing this lesson, you should understand:

What IAM Roles for Service Accounts (IRSA) is
Why IRSA is important in Amazon EKS
How OIDC and AWS STS enable workload authentication
How Service Accounts integrate with IAM Roles
The benefits of temporary credentials
Common IRSA security risks
Enterprise best practices for workload identity

IRSA is one of the most important Amazon EKS security features because it eliminates long-lived AWS credentials while providing secure, auditable, and least-privilege access to AWS services.

Knowledge Check

Question 1

What is the primary purpose of IAM Roles for Service Accounts (IRSA)?

A. Increase Pod performance
B. Securely grant AWS permissions to Kubernetes workloads
C. Replace Kubernetes RBAC
D. Encrypt Kubernetes Secrets

Answer: B

Question 2

Which AWS service issues temporary credentials for IRSA?

A. Amazon S3
B. AWS Security Token Service (STS)
C. Amazon CloudWatch
D. Amazon Route 53

Answer: B

Question 3

Which Kubernetes object is associated with an IAM Role when using IRSA?

A. Namespace
B. Deployment
C. Service Account
D. ConfigMap

Answer: C

Question 4

Which protocol enables trust between Amazon EKS and AWS IAM for IRSA?

A. FTP
B. SMTP
C. OpenID Connect (OIDC)
D. SNMP

Answer: C

Question 5

Which of the following is considered an IRSA best practice?

A. Store AWS Access Keys inside Docker images.
B. Share one IAM Role across all applications.
C. Create dedicated Service Accounts with least-privilege IAM Roles.
D. Disable CloudTrail logging.

Answer: C

What’s Next?

In the next lesson, you will learn about Least Privilege Design, where you will explore how enterprise organisations minimise permissions across Kubernetes RBAC, AWS IAM, Service Accounts, and workloads to reduce the attack surface and prevent privilege escalation.

➡️ Next Lesson: Lesson 08 — Least Privilege Design