IRSA Manager allows you to easily set up IAM Roles for Service Accounts (IRSA) on both EKS and non-EKS Kubernetes clusters.
IRSA (IAM Roles for Service Accounts) allows Kubernetes service accounts to assume AWS IAM roles. This is particularly useful for providing Kubernetes workloads with the necessary AWS permissions in a secure manner.
For detailed guidelines on how irsa-manager works, please refer to the blog post.
Before you begin, ensure you have the following:
AWS user credentials with appropriate permissions.
Follow these steps to set up IRSA on your cluster:
Create a secret for irsa-manager to access AWS:
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
Add the irsa-manager Helm repository and install irsa-manager:
helm repo add kkb0318 https://kkb0318.github.io/irsa-manager
helm repo update
helm install irsa-manager kkb0318/irsa-manager -n irsa-manager-system --create-namespace
If you're using self-hosted Kubernetes, follow this setup:
If you're using EKS, follow this setup:
You can set up IRSA for any Kubernetes ServiceAccount by configuring the necessary IAM roles and policies.
While you can use the provided IRSA custom resources, it is also possible to set up IRSA manually by configuring the iamRole
, iamPolicies
, and ServiceAccount
directly.
The following example shows how irsa-manager sets up the irsa1-sa
ServiceAccount in the kube-system
and default
namespaces with the AmazonS3FullAccess policy using IRSA custom resources:
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
This configuration simplifies the setup process by combining the creation of the IAM role, policies, and service account into a single custom resource.
Alternatively, you can configure IRSA manually without using the IRSA custom resources by following these steps:
{
"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>"
}
}
}
]
}
apiVersion: v1
kind: ServiceAccount
metadata:
name: <name>
namespace: <namespace>
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::<account-id>:role/<role name>
To verify the above example and ensure the IRSA works correctly, you can check the following job. There is a Kubernetes job that will put one file into the S3 bucket, confirming that the Pod can assume the role to get S3 write permission:
cd validation
sh s3-echoer.sh
You can find the reference in the Reference file.
This project is licensed under the MIT License - see the LICENSE file for details.
In creating this OSS project, I referred to several sources and would like to express my gratitude for their valuable information and insights.
The necessity of this project was realized through discussions in the following issue:
Additionally, the implementation was guided by the following repositories: