Lesson 04 — Service Accounts & IAM Roles for Service Accounts (IRSA)
Learning Objectives
Section titled “Learning Objectives”By the end of this lesson, you will be able to:
- Understand Kubernetes Service Accounts
- Differentiate User Accounts from Service Accounts
- Learn how Pods authenticate to the Kubernetes API
- Understand IAM Roles for Service Accounts (IRSA)
- Learn how Amazon EKS integrates with AWS IAM
- Identify common Service Account security risks
- Apply enterprise best practices for workload identity
Why This Matters
Section titled “Why This Matters”Applications running inside Kubernetes often need to communicate with:
- Kubernetes API Server
- Amazon S3
- Amazon DynamoDB
- Amazon SQS
- Amazon SNS
- AWS Secrets Manager
- Amazon ECR
- AWS KMS
The question is:
How should an application authenticate securely without storing AWS Access Keys inside the container?
Years ago, developers commonly stored AWS credentials inside:
- Source code
- Configuration files
- Environment variables
- Docker images
Today, this is considered a major security risk.
Modern Kubernetes environments solve this problem using:
- Kubernetes Service Accounts
- IAM Roles for Service Accounts (IRSA)
What is a Service Account?
Section titled “What is a Service Account?”A Service Account is a Kubernetes identity used by applications and Pods.
Unlike a human user, a Service Account is designed specifically for workloads running inside the cluster.
Examples include:
- Web applications
- APIs
- CI/CD pipelines
- Monitoring tools
- Security agents
- Operators
- Controllers
Every Pod can use a Service Account to authenticate to the Kubernetes API.
User Account vs Service Account
Section titled “User Account vs Service Account”| User Account | Service Account |
|---|---|
| Human identity | Application identity |
| Used by administrators | Used by Pods |
| AWS IAM / OIDC / Certificates | Kubernetes Service Account |
| Interactive login | Automatic authentication |
| Managed externally | Managed inside Kubernetes |
Think of a Service Account as the digital identity of a workload.
Service Account Architecture
Section titled “Service Account Architecture”Application Pod
↓
Service Account
↓
Authentication Token
↓
Kubernetes API ServerThe Pod automatically presents its Service Account identity whenever it communicates with the Kubernetes API.
Default Service Account
Section titled “Default Service Account”Every Namespace automatically includes a Service Account called:
defaultIf a Pod does not specify a Service Account, Kubernetes automatically assigns the default Service Account.
Namespace
├── default Service Account
↓
Pod
↓
Uses default identityUsing the default Service Account in production is generally discouraged.
Dedicated Service Accounts
Section titled “Dedicated Service Accounts”Enterprise applications typically use dedicated Service Accounts.
Example:
Namespace
├── payment-service
├── customer-service
├── inventory-service
└── monitoring-serviceEach application receives its own identity.
This improves:
- Security
- Auditing
- Permission management
- Least privilege implementation
How Service Accounts Work
Section titled “How Service Accounts Work”Authentication flow:
Application
↓
Service Account
↓
Token Mounted
↓
API Server
↓
AuthenticatedThe API Server verifies the Service Account token before processing requests.
Service Account Tokens
Section titled “Service Account Tokens”Modern Kubernetes automatically creates short-lived Service Account Tokens.
These tokens are:
- Automatically generated
- Automatically rotated
- Cryptographically signed
- Mounted inside the Pod
Unlike older Kubernetes versions, long-lived tokens are no longer recommended.
RBAC and Service Accounts
Section titled “RBAC and Service Accounts”Authentication identifies the Service Account.
RBAC determines what it can do.
Application
↓
Service Account
↓
RBAC
↓
Permissions
↓
API AccessWithout RBAC, a Service Account has very limited access.
Example
Section titled “Example”Payment API
↓
Payment Service Account
↓
RoleBinding
↓
Payment Role
↓
Read Secrets
Read ConfigMaps
Create Jobs
The application receives only the permissions defined by its Role.
Why Applications Need AWS Access
Section titled “Why Applications Need AWS Access”Applications often require access to AWS services.
Examples:
Application
↓
Amazon S3
↓
Store Images
--------------------
Application
↓
Secrets Manager
↓
Retrieve Password
--------------------
Application
↓
Amazon SQS
↓
Send MessagesThe challenge is granting AWS permissions securely.
Traditional Approach (Not Recommended)
Section titled “Traditional Approach (Not Recommended)”Older applications stored AWS credentials inside Pods.
Application
↓
AWS Access Key
↓
AWS Secret Key
↓
Amazon S3Problems:
- Hardcoded credentials
- Credential theft
- Difficult rotation
- Shared secrets
- High risk of compromise
This approach should never be used in production.
What is IRSA?
Section titled “What is IRSA?”IAM Roles for Service Accounts (IRSA) allows Kubernetes workloads to assume AWS IAM Roles without storing AWS credentials.
Instead of embedding access keys inside containers, Pods receive temporary credentials from AWS.
IRSA is the recommended authentication mechanism for Amazon EKS.
IRSA Architecture
Section titled “IRSA Architecture”Application Pod
↓
Service Account
↓
OIDC Provider
↓
AWS STS
↓
Temporary Credentials
↓
IAM Role
↓
Amazon S3No static AWS credentials are stored inside the container.
IRSA Authentication Flow
Section titled “IRSA Authentication Flow”Pod Starts
↓
Uses Service Account
↓
OIDC Token Generated
↓
AWS STS Validates Token
↓
IAM Role Assumed
↓
Temporary Credentials Issued
↓
Application Accesses AWSEverything happens automatically.
Components of IRSA
Section titled “Components of IRSA”IRSA relies on four major components.
Amazon EKS
↓
OIDC Provider
↓
IAM Role
↓
Kubernetes Service AccountTogether they establish a trusted relationship between Kubernetes and AWS IAM.
OIDC Provider
Section titled “OIDC Provider”Amazon EKS creates an OpenID Connect (OIDC) identity provider.
The OIDC provider allows AWS IAM to trust identities issued by the Kubernetes cluster.
Amazon EKS
↓
OIDC Provider
↓
AWS IAMWithout OIDC, IRSA cannot function.
AWS Security Token Service (STS)
Section titled “AWS Security Token Service (STS)”AWS STS issues temporary credentials after validating the Service Account identity.
Application
↓
OIDC Token
↓
AWS STS
↓
Temporary CredentialsBenefits include:
- Automatic expiration
- Reduced credential theft risk
- No long-lived access keys
- Improved auditing
Enterprise Example
Section titled “Enterprise Example”An image processing application uploads files to Amazon S3.
Architecture:
Image Processor
↓
Service Account
↓
IAM Role
↓
AWS STS
↓
Temporary Credentials
↓
Amazon S3Permissions:
- Upload objects
- Read objects
- No bucket deletion
- No IAM permissions
- No EC2 permissions
The application only receives the permissions required for its task.
IRSA Benefits
Section titled “IRSA Benefits”IRSA provides:
- No hardcoded AWS credentials
- Automatic credential rotation
- Temporary credentials
- Fine-grained IAM permissions
- Improved auditing
- Better compliance
- Least privilege access
- Secure workload identity
These benefits make IRSA the preferred identity solution for Amazon EKS.
Service Account Security Risks
Section titled “Service Account Security Risks”Cloud Security Engineers commonly identify:
- Using the default Service Account
- Overprivileged Service Accounts
- Shared Service Accounts across applications
- Long-lived tokens
- Wildcard RBAC permissions
- Pods with cluster-admin privileges
- Missing IAM restrictions
- Hardcoded AWS credentials
- Insecure token storage
- Unused Service Accounts
Compromised Service Accounts can allow attackers to move laterally within the cluster.
Enterprise Architecture
Section titled “Enterprise Architecture”Amazon EKS
├── Payment Namespace│ └── Payment Service Account│ └── Payment IAM Role│├── Customer Namespace│ └── Customer Service Account│ └── Customer IAM Role│├── Inventory Namespace│ └── Inventory Service Account│ └── Inventory IAM Role│└── Monitoring Namespace └── Monitoring Service Account └── CloudWatch IAM RoleEach workload has its own identity and permissions.
Monitoring Service Accounts
Section titled “Monitoring Service Accounts”Security teams should monitor:
- New Service Account creation
- Deleted Service Accounts
- Token usage
- IAM Role assumptions
- Failed STS requests
- Unusual AWS API calls
- Privilege escalation attempts
- RoleBinding changes
- ClusterRoleBinding changes
- Cross-namespace Service Account usage
Continuous monitoring helps detect compromised workloads.
Real-World Scenario
Section titled “Real-World Scenario”A development team stores AWS Access Keys inside a Docker image.
The image is accidentally pushed to a public container registry.
An attacker extracts the credentials and:
- Reads confidential data from Amazon S3.
- Launches EC2 instances for cryptocurrency mining.
- Enumerates IAM users and roles.
- Attempts privilege escalation.
If the application had used IRSA:
- No AWS credentials would have existed inside the image.
- Temporary credentials would have expired automatically.
- IAM permissions would have been tightly scoped.
- The attack impact would have been significantly reduced.
Best Practices
Section titled “Best Practices”As a Kubernetes Security Engineer:
- Create dedicated Service Accounts for every application.
- Never use the default Service Account in production.
- Implement IAM Roles for Service Accounts (IRSA).
- Follow the Principle of Least Privilege.
- Use temporary AWS credentials.
- Rotate Kubernetes tokens automatically.
- Monitor Service Account activity.
- Restrict RBAC permissions.
- Audit IAM Role usage regularly.
- Remove unused Service Accounts promptly.
Workload identity is just as important as user identity in a secure Kubernetes environment.
Key Takeaways
Section titled “Key Takeaways”After completing this lesson, you should understand:
- What Kubernetes Service Accounts are
- How workloads authenticate to the Kubernetes API
- How RBAC authorizes Service Accounts
- Why IAM Roles for Service Accounts (IRSA) are essential in Amazon EKS
- The role of OIDC and AWS STS
- Common Service Account security risks
- Enterprise best practices for workload identity
Service Accounts and IRSA provide a secure, scalable, and cloud-native approach to authenticating workloads without exposing long-lived AWS credentials.
Knowledge Check
Section titled “Knowledge Check”Question 1
Section titled “Question 1”What is the primary purpose of a Kubernetes Service Account?
- A. Authenticate human users
- B. Provide an identity for applications and Pods
- C. Create Worker Nodes
- D. Schedule Pods
Answer: B
Question 2
Section titled “Question 2”What Service Account is automatically assigned to a Pod if none is specified?
- A. admin
- B. system
- C. default
- D. cluster-admin
Answer: C
Question 3
Section titled “Question 3”What is the primary purpose of IAM Roles for Service Accounts (IRSA)?
- A. Improve Pod scheduling
- B. Securely grant AWS permissions to Kubernetes workloads without storing AWS credentials
- C. Replace Kubernetes RBAC
- D. Encrypt Kubernetes Secrets
Answer: B
Question 4
Section titled “Question 4”Which AWS service issues temporary credentials when using IRSA?
- A. Amazon EC2
- B. AWS Security Token Service (STS)
- C. Amazon CloudWatch
- D. Amazon Route 53
Answer: B
Question 5
Section titled “Question 5”Which of the following is considered an enterprise best practice?
- A. Use the default Service Account for all production workloads.
- B. Store AWS Access Keys inside Docker images.
- C. Create dedicated Service Accounts with least privilege IAM Roles.
- D. Share one IAM Role across every application.
Answer: C
What’s Next?
Section titled “What’s Next?”Learn how Kubernetes Secrets securely store and manage sensitive information such as passwords, API keys, certificates, and tokens, and understand enterprise best practices for protecting secrets in Amazon EKS.
➡️ Next Lesson: Lesson 05 — Kubernetes Secrets