AWS EFS CSI Driver follows with AssumeRole Error - cross account dynamic provisioning

[quanhk711]

/kind bug
For cross account provisioning, the efs-csi-driver need IAM role to describe mount targets of the EFS file system. The driver will select an IP address from one of the mount targets on the EFS file system to perform cross-account mount.

The describe-mount-target IAM Role wasn't working when following this blog post:
https://aws.amazon.com/blogs/storage/mount-amazon-efs-file-systems-cross-account-from-amazon-eks/

What happened?

failed to provision volume with StorageClass "corp-data-migration-file-preprod-efs": rpc
error: code = Internal desc = Failed to fetch Access Points or Describe File System: List
Access Points failed: AccessDenied: User: arn:aws:sts:xxxx-A:assumed-
role/TF_AWSEfsCsiDriverlAMPolicy_preprod/1709202420990880480 is not authorized
to perform: sts:AssumeRole on resource:
arn:awstiam::xxxx-B:role/EFSCrossAccountAccessAssumeRoleCorpPREPROD
status code: 403, request id: 564cefe0-28f6-4a9e-89db-1179bef01c0d

How to reproduce it (as minimally and precisely as possible)?

TF_AWSEfsCsiDriverIAMPolicy_preprod (eks account xxxx-A) :

{
    "Statement": [
        {
            "Action": [
                "elasticfilesystem:DescribeAccessPoints",
                "elasticfilesystem:DescribeFileSystems",
                "elasticfilesystem:DescribeMountTargets",
                "ec2:DescribeAvailabilityZones"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "elasticfilesystem:CreateAccessPoint"
            ],
            "Condition": {
                "StringLike": {
                    "aws:RequestTag/efs.csi.aws.com/cluster": "true"
                }
            },
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "elasticfilesystem:TagResource"
            ],
            "Condition": {
                "StringLike": {
                    "aws:ResourceTag/efs.csi.aws.com/cluster": "true"
                }
            },
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": "elasticfilesystem:DeleteAccessPoint",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/efs.csi.aws.com/cluster": "true"
                }
            },
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "2012-10-17"
}

EFSCrossAccountAccessAssumeRoleCorpPREPROD Trust relationships (efs account xxxx-B):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::xxxx-A:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Amazon EFS CSI Driver version: v1.7.5-eksbuild.2

[RyanStan]

Hi! As you pointed out, it looks like you're failing to assume the cross account role.

Did you complete step #2?

In the AWS account A hosting your EKS cluster, create and attach an IAM policy with sts assume permissions to cross-account IAM role created in Step 1. Attach this policy to IAM role associated with service account of driver’s controller service.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/EFSCrossAccountAccessRole"
}
}

Also, your policy looks correct, TF_AWSEfsCsiDriverIAMPolicy_preprod , but we recommend that customers use the EFS managed policy instead, AmazonEFSCSIDriverPolicy.

[quanhk711]

yes, I have completed step 2

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten