# IAM Permissions Not Working in EKS? Here's How to Fix It (With IRSA)


You have a working Amazon EKS cluster and deployed pods. Now, your pods need secure, fine-grained access to AWS services like S3, DynamoDB, or Secrets Manager, but:

*   You don't want to hardcode AWS credentials in pods.
    
*   You want to follow AWS best practices using IAM roles for Kubernetes service accounts (IRSA).
    

![](https://cdn.hashnode.com/uploads/covers/6338fc85e594fa4ba3b90a69/b243a616-3c5b-430d-a1e3-eebb275eeddf.png align="center")

**Solution: Use IRSA (IAM Roles for Service Accounts):**

With IRSA, each pod uses a Kubernetes service account that is linked to an IAM role, which defines what that pod can access in AWS.

This blog walks through enabling IRSA for your existing pods.

**Assumptions**

*   You have an EKS cluster already running 
    
*   Your pods are already deployed 
    
*   You're using AWS CLI, kubectl, and eksctl
    
*   You have access to create IAM roles and policies
    

**Step-by-Step Guide**

**Step 1: Verify OIDC Provider for Your EKS Cluster**

```shell
eksctl utils associate-iam-oidc-provider \
  --region <aws-region> \
  --cluster <cluster-name> \
  --approve
```

 **Step 2: Create an IAM Policy with Required Permissions**

For example, for S3 read access:

*   Create s3-read-policy.json:
    

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["<service-action>"],
      "Resource": ["<arn>"]
    }
  ]
}
```

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::rambunct-app"]
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::rambunct-app/*"]
    }
  ]
}
```

![](https://cdn.hashnode.com/uploads/covers/6338fc85e594fa4ba3b90a69/ec32c347-821e-408d-837a-db6b98cf6937.png align="center")

*   **Create a policy**
    

```shell
aws iam create-policy \
  --policy-name <your-policy-name> \
  --policy-document file://s3-read-policy.json
```

**Step 3: Create a Kubernetes Service Account Linked to IAM Role**

This account will be used by your pod.

```shell
eksctl create iamserviceaccount \
  --name <serviceaccount-name> \
  --namespace <namespace> \
  --cluster <cluster-name> \
  --region <region> \
  --attach-policy-arn arn:aws:iam::<account-id>:policy/<policy-name> \
  --approve \
  --override-existing-serviceaccounts
```

**Step 4: Patch the Pod (or Deployment) to Use the New Service Account**

**If you’re using plain pods (not Deployments):**

```shell
kubectl delete pod <your-pod>
```

**Then update your YAML ;**

```yaml
spec:
  serviceAccountName: <your-serviceaccount>
```

**Apply it:**

```shell
kubectl apply -f <your-pod>
```

 **Step 5: Verify from Pod Logs**

```shell
kubectl logs <your-pod>
```

### **Conclusion**

By using IAM Roles for Service Accounts (IRSA), you can give your existing pods secure access to AWS services without compromising credentials. This is a production-grade method to connect workloads running in EKS with services like S3, Secrets Manager, and DynamoDB.

If your app needs AWS access, don’t use long-lived keys use IRSA. It's more secure, scalable, and AWS-native.