Kubernetes IAM Roles for Service Accounts (IRSA)

The architectural intersection of Kubernetes orchestration and Amazon Web Services (AWS) Identity and Access Management (IAM) creates a complex security challenge: how to grant fine-grained, secure access to cloud resources for containerized workloads without compromising the security posture of the entire cluster. IAM Roles for Service Accounts (IRSA) serves as the definitive solution to this problem. By leveraging the OpenID Connect (OIDC) identity provider, IRSA allows Kubernetes service accounts to assume specific AWS IAM roles. This mechanism shifts the security paradigm away from static, long-term credentials—which are prone to leakage and difficult to rotate—toward a dynamic, identity-based authentication model. In a standard Kubernetes environment, pods often inherit the permissions of the worker node (the EC2 instance profile), leading to a "broad-brush" approach to security where every pod on a node shares the same permissions. IRSA dismantles this monolithic structure, enabling a zero-trust architecture where permissions are scoped precisely to the functional requirements of a specific service.

The Architecture of IRSA and the Identity Paradigm

IAM Roles for Service Accounts fundamentally changes how applications in a Pod's containers interact with AWS services. Under traditional models, developers might use the AWS SDK or AWS CLI by manually injecting access keys into secrets or relying on the Amazon EC2 Instance Metadata Service (IMDS). However, IRSA provides a native way to manage these credentials. Instead of distributing static keys, the system associates an IAM role directly with a Kubernetes service account.

The core benefit of this approach is the implementation of the principle of least privilege. By scoping IAM permissions to a specific service account, the administrator ensures that only the Pods explicitly configured to use that service account can access the associated AWS resources. This eliminates the operational overhead and security risks associated with third-party legacy solutions such as kiam or kube2iam. Furthermore, IRSA provides critical credential isolation. When access to the Amazon EC2 Instance Metadata Service (IMDS) is restricted, containers can no longer "hop" to the node's identity; they are strictly limited to retrieving credentials for the IAM role associated with their specific service account. This creates a hard boundary between the infrastructure's identity and the application's identity.

Deployment Strategies via irsa-manager

For organizations seeking to streamline the complexity of IRSA, the irsa-manager tool provides a high-level abstraction layer. This manager allows for the rapid setup of IAM Roles for Service Accounts across both Amazon EKS and non-EKS (self-hosted) Kubernetes clusters. The primary utility of irsa-manager is its ability to consolidate the fragmented process of creating IAM roles, attaching policies, and configuring service accounts into a single, declarative Custom Resource (CR).

To utilize irsa-manager, several environmental prerequisites must be met. A running Kubernetes cluster is mandatory, as is the presence of Helm on the local machine for deployment. Most critically, the operator must possess AWS user credentials with sufficient permissions to allow the manager to call necessary AWS APIs. Without these high-level permissions, the manager cannot automate the lifecycle of the IAM roles it is designed to govern.

Technical Implementation of irsa-manager

The installation of irsa-manager follows a standardized Helm-based workflow. This ensures that the manager is deployed consistently across different environments.

The process begins with adding the official repository and updating the local cache:

helm repo add kkb0318 https://kkb0318.github.io/irsa-manager

helm repo update

Once the repository is configured, the manager is installed into a dedicated namespace to ensure isolation:

helm install irsa-manager kkb0318/irsa-manager -n irsa-manager-system --create-namespace

After the Helm chart is deployed, the manager requires AWS credentials to operate. This is achieved by creating a Kubernetes secret in the irsa-manager-system namespace. This secret provides the manager with the identity it needs to act on behalf of the cluster administrator to provision IAM resources.

kubectl create secret generic aws-secret -n irsa-manager-system \ --from-literal=aws-access-key-id=<your-access-key-id> \ --from-literal=aws-secret-access-key=<your-secret-access-key> \ --from-literal=aws-session-token=<your-aws-session-token> # Optional \ --from-literal=aws-region=<your-region> \ --from-literal=aws-role-arn=<your-role-arn> # Optional: Set this if you want to switch roles

Orchestrating IRSA via Custom Resources

The power of irsa-manager lies in the IRSA Custom Resource. This allows users to define the entire security chain in a single YAML file. For example, if a user needs a service account in both the kube-system and default namespaces to have full access to Amazon S3, they can utilize the following configuration:

yaml apiVersion: irsa-manager.kkb0318.github.io/v1alpha1 kind: IRSA metadata: name: irsa-sample namespace: irsa-manager-system spec: cleanup: true serviceAccount: name: irsa1-sa namespaces: - kube-system - default iamRole: name: irsa1-role iamPolicies: - AmazonS3FullAccess

In this configuration, the irsa-manager handles the backend complexity of creating the irsa1-role in AWS, attaching the AmazonS3FullAccess policy to that role, and creating the irsa1-sa ServiceAccount in the specified namespaces. The cleanup: true flag ensures that when the custom resource is deleted, the associated AWS resources are also purged, preventing "cloud sprawl" and orphan IAM roles.

Manual IRSA Configuration and Trust Policies

While irsa-manager provides automation, understanding the manual process is essential for auditing and advanced configuration. Manual setup requires a deep understanding of trust relationships and OIDC providers.

The manual process consists of three primary phases:

1. Create the IAM Role:
   An IAM role must be created with a specific trust policy. This policy defines who is allowed to assume the role. In the context of IRSA, the trust policy must allow the sts:AssumeRoleWithWebIdentity action, federated via the cluster's OIDC provider.

The trust policy structure is as follows:

json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<account-id>:oidc-provider/s3-<region>.amazonaws.com/<S3 bucket name>" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "s3-<region>.amazonaws.com/<S3 bucket name>:sub": "system:serviceaccount:<namespace>:<name>" } } } ] }

This policy ensures that only the specific service account in the specific namespace can assume the role, creating a tight security loop.

2. Attach IAM Policies:
   Once the role is created, the administrator must attach the necessary permissions. For instance, if the workload requires S3 access, the AmazonS3FullAccess policy is attached to the role.

3. Annotate the Kubernetes ServiceAccount:
   The final step is to link the Kubernetes identity to the AWS identity. This is done by adding an annotation to the ServiceAccount metadata.

yaml apiVersion: v1 kind: ServiceAccount metadata: name: <name> namespace: <namespace> annotations: eks.amazonaws.com/role-arn: arn:aws:iam::<account-id>:role/<role name>

When a pod uses this service account, the AWS SDK detects the annotation and uses the OIDC token to assume the IAM role.

Comparison of Permission Requirements

The permissions required for the identity managing the IRSA setup differ based on whether the environment is EKS or self-hosted. These requirements ensure that the manager has exactly the permissions it needs to manipulate IAM and OIDC resources.

EKS Integration with Harness for Cross-Account Workflows

In complex enterprise environments, the EKS cluster may reside in a different AWS account than the resources it needs to access. This necessitates a cross-account integration strategy. Harness facilitates this by deploying a Kubernetes Delegate within the EKS cluster.

The Harness Kubernetes Delegate acts as the bridge between the Harness CI/CD platform and the EKS cluster. By leveraging IRSA, the Delegate can be configured to assume IAM roles across account boundaries. This allows for seamless CI/CD workflows where the Delegate manages workloads and interacts with AWS resources without requiring long-term static credentials to be stored within the Harness platform.

The workflow for this integration typically involves:

• Configuring the AWS CLI with access keys.
• Using eksctl to manage the EKS cluster.
• Defining IAM roles and policies specifically for cross-account access.
• Deploying the Harness Delegate, which then utilizes IRSA to securely authenticate and manage the deployed workloads.

Comparative Analysis of IRSA vs. Node-Level Permissions

The transition from node-level permissions to IRSA is a transition from shared identity to isolated identity.

• Shared Identity (Node Profile):
  In this model, every pod on a given worker node shares the same IAM role. If a single pod is compromised, the attacker gains access to all permissions assigned to that node. This creates a massive blast radius and violates the principle of least privilege.

• Isolated Identity (IRSA):
  With IRSA, permissions are mapped 1:1 (or 1:Many) between a ServiceAccount and an IAM Role. Pod A uses ServiceAccount A (S3 Read Only), and Pod B uses ServiceAccount B (DynamoDB Read/Write). If Pod A is compromised, the attacker only has S3 Read Only access. This significantly reduces the blast radius and enhances the overall security posture of the cluster.

Technical Summary of IRSA Componentry

The operational success of IRSA relies on the seamless integration of several distinct components.

• OIDC Identity Provider:
  The bridge that allows AWS to trust the tokens issued by the Kubernetes cluster.

• Kubernetes ServiceAccount:
  The internal identity within the cluster that acts as the primary identifier for pods.

• IAM Role:
  The AWS-side identity that contains the actual permissions (policies) required to perform tasks.

• Trust Policy:
  The gatekeeper that defines the conditions under which the OIDC provider can assume the IAM role.

• Pod Specification:
  The final link where the pod is told which service account to use, thereby triggering the entire IRSA chain.

Analysis of the IRSA Ecosystem

The implementation of IRSA represents a critical evolution in cloud-native security. By moving away from static credentials and node-shared identities, AWS and Kubernetes have created a framework that supports high-scale, secure, and auditable environments. The introduction of tools like irsa-manager further lowers the barrier to entry, allowing teams to move from manual, error-prone YAML configurations to a declarative, automated model.

The impact of this technology is most visible in the reduction of "credential rotation" fatigue. In traditional setups, rotating access keys across hundreds of microservices was a Herculean task. With IRSA, the rotation is handled by the AWS Security Token Service (STS) automatically via short-lived tokens. This not only improves security but also reduces operational overhead.

Furthermore, the ability to extend this to non-EKS clusters demonstrates the universality of the OIDC-based identity model. Whether running on a managed service or a self-hosted environment, the ability to map a Kubernetes identity to a cloud identity is the cornerstone of modern infrastructure security. The integration with higher-level orchestration tools like Harness shows that IRSA is not just a security feature, but a foundational building block for secure, automated CI/CD pipelines in the cloud.

Sources

1. irsa-manager GitHub
2. Harness Developer Documentation
3. AWS EKS User Guide