How to Use a Dedicated IAM Role with the EFS CSI Driver Node Component in Amazon EKS Using Pod Identity

Overview

When using the Amazon EFS CSI driver with Amazon EKS, the node component (efs-csi-node) performs the actual EFS mount operations on each worker node. By default, this component uses the EC2 node instance role for IAM authentication. However, if you enforce least-privilege access to your EFS file systems using IAM-based mount authentication (the iam mount option), you may want to assign a dedicated IAM role to the node component rather than granting broad EFS permissions to the node instance role.

As of EFS CSI driver release v3.0.0-eksbuild.1 (upstream driver v3.0.0; latest upstream release is v3.0.1 as of April 2026), the EKS managed add-on natively supports configuring Pod Identity for both the controller (efs-csi-controller-sa) and node (efs-csi-node-sa) service accounts. However, the official AWS documentation for EFS storage currently only covers Pod Identity setup for the controller service account. The node service account Pod Identity setup is documented on the S3 Files storage page but not on the EFS-specific page. This article bridges that gap for customers using EFS with IAM-based mount authentication who want least-privilege access for the node component. It covers:

• How to configure Pod Identity for the EFS CSI node component natively (v3.0.0+).
• A manual workaround for customers on older add-on versions.
• Common pitfalls with EFS file system policies that cause mount failures.
• Troubleshooting tips for EFS mount operations in EKS.

Prerequisites

• An Amazon EKS cluster with the Amazon EKS Pod Identity Agent installed.
• The AWS EFS CSI driver managed add-on installed.
• An Amazon EFS file system accessible from your cluster's VPC.
• AWS CLI v2 and kubectl configured for your cluster.

Option 1: Native Pod Identity Configuration (v3.0.0-eksbuild.1 / Upstream v3.0.0+ and Later)

From EFS CSI driver v3.0.0-eksbuild.1 onwards (upstream v3.0.0+), you can configure Pod Identity associations for both the controller and node service accounts. First install the add-on, then create the associations:

# Install the add-on (if not already installed)
aws eks create-addon \
    --cluster-name <CLUSTER_NAME> \
    --addon-name aws-efs-csi-driver \
    --region <REGION>

# Create Pod Identity association for the controller
aws eks create-pod-identity-association \
    --cluster-name <CLUSTER_NAME> \
    --role-arn arn:aws:iam::<ACCOUNT_ID>:role/<CONTROLLER_ROLE> \
    --namespace kube-system \
    --service-account efs-csi-controller-sa

# Create Pod Identity association for the node
aws eks create-pod-identity-association \
    --cluster-name <CLUSTER_NAME> \
    --role-arn arn:aws:iam::<ACCOUNT_ID>:role/<NODE_ROLE> \
    --namespace kube-system \
    --service-account efs-csi-node-sa

After creating the node association, restart the DaemonSet to pick up the new credentials:

kubectl rollout restart daemonset efs-csi-node -n kube-system

This is the recommended approach as the associations are managed alongside the add-on lifecycle.

Option 2: Manual Workaround (Older Add-on Versions)

If you are running an EFS CSI driver version prior to v3.0.0-eksbuild.1, the managed add-on only supports Pod Identity for the controller service account (efs-csi-controller-sa). You can manually create a Pod Identity Association for the node component after add-on installation.

Step 1: Create the Pod Identity Association

aws eks create-pod-identity-association \
    --cluster-name <CLUSTER_NAME> \
    --namespace kube-system \
    --service-account efs-csi-node-sa \
    --role-arn arn:aws:iam::<ACCOUNT_ID>:role/<YOUR_NODE_ROLE> \
    --region <REGION>

Step 2: Restart the efs-csi-node DaemonSet

The DaemonSet must be restarted for the pods to pick up the new credentials:

kubectl rollout restart daemonset efs-csi-node -n kube-system

Step 3: Verify Pod Identity Injection

Confirm that the Pod Identity credentials are injected into the node pods:

kubectl exec -n kube-system <efs-csi-node-pod> -c efs-plugin -- env | grep AWS_CONTAINER

Expected output:

AWS_CONTAINER_CREDENTIALS_FULL_URI=http://169.254.170.23/v1/credentials
AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token

Note: With the manual workaround, you may need to verify the association still exists and restart the DaemonSet after add-on updates.

IAM Role Configuration

The IAM role used for the node component requires two configurations:

Trust Policy (for Pod Identity)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

Permissions Policy (for EFS Mount Operations)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticfilesystem:ClientMount",
                "elasticfilesystem:ClientWrite",
                "elasticfilesystem:ClientRootAccess"
            ],
            "Resource": "arn:aws:elasticfilesystem:<REGION>:<ACCOUNT_ID>:file-system/<EFS_FS_ID>"
        }
    ]
}

Scope the Resource to the specific file system ARN(s) your workloads need to access.

EFS File System Policy - Common Pitfall

A common mistake when enforcing IAM-based EFS access is configuring a file system policy with only Deny statements and no explicit Allow. This causes all mount operations to fail, even when the calling principal has the correct IAM permissions.

Incorrect - Deny-Only Policy (Mounts Will Fail)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": { "AWS": "*" },
            "Action": "*",
            "Resource": "arn:aws:elasticfilesystem:<REGION>:<ACCOUNT_ID>:file-system/<EFS_FS_ID>",
            "Condition": {
                "Bool": { "aws:SecureTransport": "false" }
            }
        },
        {
            "Effect": "Deny",
            "Principal": { "AWS": "*" },
            "Action": "*",
            "Resource": "arn:aws:elasticfilesystem:<REGION>:<ACCOUNT_ID>:file-system/<EFS_FS_ID>",
            "Condition": {
                "Bool": { "elasticfilesystem:AccessedViaMountTarget": "false" }
            }
        }
    ]
}

The above policy denies non-TLS and non-mount-target access, but it does not grant any access. Without an explicit Allow, no principal - regardless of their IAM permissions - can mount the file system.

Correct - Add an Explicit Allow for the Pod Identity Role

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowEFSCSINodeRole",
            "Effect": "Allow",
            "Principal": { "AWS": "*" },
            "Action": [
                "elasticfilesystem:ClientMount",
                "elasticfilesystem:ClientWrite",
                "elasticfilesystem:ClientRootAccess"
            ],
            "Resource": "arn:aws:elasticfilesystem:<REGION>:<ACCOUNT_ID>:file-system/<EFS_FS_ID>",
            "Condition": {
                "ArnLike": {
                    "aws:PrincipalArn": "arn:aws:iam::<ACCOUNT_ID>:role/<YOUR_POD_IDENTITY_ROLE>"
                }
            }
        },
        {
            "Effect": "Deny",
            "Principal": { "AWS": "*" },
            "Action": "*",
            "Resource": "arn:aws:elasticfilesystem:<REGION>:<ACCOUNT_ID>:file-system/<EFS_FS_ID>",
            "Condition": {
                "Bool": { "aws:SecureTransport": "false" }
            }
        },
        {
            "Effect": "Deny",
            "Principal": { "AWS": "*" },
            "Action": "*",
            "Resource": "arn:aws:elasticfilesystem:<REGION>:<ACCOUNT_ID>:file-system/<EFS_FS_ID>",
            "Condition": {
                "Bool": { "elasticfilesystem:AccessedViaMountTarget": "false" }
            }
        }
    ]
}

This policy enforces TLS and mount-target access whilst explicitly allowing the EFS CSI node role to perform mount operations.

Troubleshooting Tips

1. EFS mount operations are data plane activities - ClientMount, ClientWrite, and ClientRootAccess are not logged in CloudTrail or EKS control plane logs. To troubleshoot mount failures, check the efs-csi-node pod logs:

   kubectl logs -n kube-system <efs-csi-node-pod> -c efs-plugin

2. Verify credentials injection - If mounts fail after configuring Pod Identity, confirm the environment variables are present (see Step 3 above). If they are missing, ensure the Pod Identity Agent add-on is installed and the DaemonSet has been restarted.

3. Check the EFS file system policy - If you see AccessDeniedException in the node pod logs, review your file system policy for the Deny-only pitfall described above.

4. After add-on updates (manual workaround only) - Verify the Pod Identity Association still exists and restart the DaemonSet if credentials are no longer injected.

References

• GitHub Issue #1759 - Pod Identity support for the node component in EKS managed addon
• Amazon EFS CSI Driver - Parameters Documentation
• Amazon EKS Pod Identity
• Amazon EFS - Resource-Based Policy Examples
• Amazon EFS CSI Driver Releases