By using AWS re:Post, you agree to the AWS re:Post Terms of Use

Why is my EFS File system policy blocking Fargate from mounting the EFS even though it includes the Task Execution Role arn?

0

I'm currently using an EFS mounted on a Fargate task. The task uses roles CustomECSTaskExecutionAgent for task execution and CustomECSTaskAgent for the task. With no file system policy in place, Fargate mounts fine and my task is able to read/write to the EFS. However, my company requires a File System Policy for each EFS so I added the following

{
    "Version": "2012-10-17",
    "Id": "efs-statement-8e30733a-a93f-414f-b5b6-284bd5a02c0a",
    "Statement": [
        {
            "Sid": "efs-statement-7c9d03e6-379b-422e-afe6-4d92e7ff4303",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<accountid>:role/CustomECSTaskAgent",
                    "arn:aws:iam::<accountid>:role/CustomECSTaskExecutionAgent",
                    "arn:aws:iam::<accountid>:role/CustomEC2Agent"
                ]
            },
            "Action": "elasticfilesystem:*",
            "Resource": "arn:aws:elasticfilesystem:us-east-1:<accountid>:file-system/fs-id"
        }
    ]
}

With this policy Fargate is not able to mount the drive, I get the following error: ResourceInitializationError: failed to invoke EFS utils commands to set up EFS volumes: stderr: b'mount.nfs4: access denied by server while mounting fs-id.efs.us-east-1.amazonaws.com:/' : unsuccessful EFS utils command execution; code: 32 If I add the following statement to the policy then Fargate is able to mount the drive but the task fails immediately because it is not able to read/write. I cannot keep the below statement because it is too permissive and I'd like to know what Principal I need for 1. Fargate to mount successfully 2. For my task to read/write

        {
            "Sid": "efs-statement-7c9d03e6-379b-422e-afe6-4d92e7ff4303",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "elasticfilesystem:ClientMount",
            "Resource": "arn:aws:elasticfilesystem:us-east-1:<accountid>:file-system/fs-id"
        }
  • After removing the file system policy and starting my Fargate container, then looking through CloudTrail I noticed that the connection to the EFS from the container came through as an anonymous principal

    {
        "eventVersion": "1.08",
        "userIdentity": {
            "type": "AWSAccount",
            "principalId": "",
            "accountId": "ANONYMOUS_PRINCIPAL"
        },
        "eventTime": "2022-11-03T13:10:48Z",
        "eventSource": "elasticfilesystem.amazonaws.com",
        "eventName": "NewClientConnection",
        "awsRegion": "us-east-1",
        "sourceIPAddress": "AWS Internal",
    
1 Answer
0

Can you check and make sure that one of those IAM roles defined in the EFS policy are set as default in your Fargate instances..Refer the below on how credentials configuration does affect the default IAM role the instance takes when talking to STS service.

Refer: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html

You can also get the IAM role your instances are using by default by running the command "aws sts get-caller-identity".

AWS
answered 2 years ago
  • When I run aws sts get-caller-identity from my laptop I get my account. I cannot run this command from any Fargate instance because they are serverless. So how do I find out the default IAM role that is used by Fargate? I have an EC2 instance I use for development and when I run that same command I get "Arn": "arn:aws:sts::<account-id>:assumed-role/CustomEC2Agent/i-<somenumber>"

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions