I am in the process of setting up an EFS file system for mounting to an EC2 instance and I need to understand what the policy condition key elasticfilesystem:AccessedViaMountTarget controls.
This page indicates that the key serves this purpose:
Use this key to prevent access to an EFS file system by clients that are not using file system mount targets.
(This seems to imply that there are ways to access an EFS file system without mount targets?)
I have confirmed that mounting an EFS file system to an EC2 instance makes use of the configured mount targets (by confirming that the Security Group on the EFS mount targets block access to the EC2 instance when configured accordingly).
However, when I create a policy and set elasticfilesystem:AccessedViaMountTarget to true, as per the following example:
{
"Version": "2012-10-17",
"Id": "efs-policy-wizard-b0b6bcfd-6848-4239-9070-b807d53b5919",
"Statement": [
{
"Sid": "efs-statement-3aa0a8f1-5010-4da3-8407-2a49c45d9ca0",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"elasticfilesystem:ClientRootAccess",
"elasticfilesystem:ClientWrite"
],
"Resource": "arn:aws:elasticfilesystem:XXXX:XXXX:file-system/fs-XXXX",
"Condition": {
"Bool": {
"elasticfilesystem:AccessedViaMountTarget": "true"
}
}
}
]
}
Then I am unable to mount the EFS drive to an EC2 instance as it fails with this error:
b'mount.nfs4: access denied by server while mounting X.X.X.X:/
Furthermore, this article indicates that the elasticfilesystem:AccessedViaMountTarget policy key can be used to block public access to an EFS file system - I am battling to figure out what this conditional key actually does.
In summary, what does the elasticfilesystem:AccessedViaMountTarget conditional key control and do I need to set this key on an EFS file system to block "public" access assuming Security Groups are correctly configured on the mount targets?
This has been in the back of my mind since early 2022. Recently I dug into it again and I believe I have the answer. This was not tested, but the evidence is quite strong to me.
AWS Transfer Family is capable of accessing EFS filesystems directly, without going through a mount target. AWS Transfer Family is a service that allows you to expose your EFS filesystem (or S3 bucket) through SSH, FTP or others, publicly or not, and even in other accounts. You can read more about it in the docs.
This could be a big security problem - previously, all accesses were through mount target, which were endpoints inside your VPC. You could have a policy allowing any access to your EFS filesystem, and it would still be contained to your VPC, but now no more. The addition of EFS support to Transfer Family creates the possibility of that being exploited for accessing filesystems with policies that are not restrictive enough.
Because of this, AWS disables use of EFS with Transfer Family for any accounts containing exploitable policies, as described here:
Do note that Janury 6, 2021 is the day before the announcement of AWS Transfer Family adding support for EFS.
So this also explains what "allows public access" means: it means your EFS filesystem has a policy that could be exploited by an attacker in a different account to mount your filesystem through AWS Transfer Family. To avoid this problem, any EFS that "allows public access" (i.e. is exploitable in this way) is blocked from being used by AWS Transfer Family. If you really want to use it that way, you have to be explicit in adding a
elasticfilesystem:AccessedViaMountTarget: false.TLDR
AWS Transfer Family can be used to access EFS without a mount target, and the concept of "allowing public access" is actually a way to avoid this being exploited by an attacker from a different AWS account.