AWS News Blog
New for Amazon EFS – IAM Authorization and Access Points
|
When building or migrating applications, we often need to share data across multiple compute nodes. Many applications use file APIs and Amazon Elastic File System (Amazon EFS) makes it easy to use those applications on AWS, providing a scalable, fully managed Network File System (NFS) that you can access from other AWS services and on-premises resources.
EFS scales on demand from zero to petabytes with no disruptions, growing and shrinking automatically as you add and remove files, eliminating the need to provision and manage capacity. By using it, you get strong file system consistency across 3 Availability Zones. EFS performance scales with the amount of data stored, with the option to provision the throughput you need.
Last year, the EFS team focused on optimizing costs with the introduction of the EFS Infrequent Access (IA) storage class, with storage prices up to 92% lower compared to EFS Standard. You can quickly start reducing your costs by setting a Lifecycle Management policy to move to EFS IA the files that haven’t been accessed for a certain amount of days.
Today, we are introducing two new features that simplify managing access, sharing data sets, and protecting your EFS file systems:
- IAM authentication and authorization for NFS Clients, to identify clients and use IAM policies to manage client-specific permissions.
- EFS access points, to enforce the use of an operating system user and group, optionally restricting access to a directory in the file system.
Using IAM Authentication and Authorization
In the EFS console, when creating or updating an EFS file system, I can now set up a file system policy. This is an IAM resource policy, similar to bucket policies for Amazon Simple Storage Service (Amazon S3), and can be used, for example, to disable root access, enforce read-only access, or enforce in-transit encryption for all clients.
Identity-based policies, such as those used by IAM users, groups, or roles, can override these default permissions. These new features work on top of EFS’s current network-based access using security groups.
I select the option to disable root access by default, click on Set policy, and then select the JSON tab. Here, I can review the policy generated based on my settings, or create a more advanced policy, for example to grant permissions to a different AWS account or a specific IAM role.
The following actions can be used in IAM policies to manage access permissions for NFS clients:
ClientMountto give permission to mount a file system with read-only accessClientWriteto be able to write to the file systemClientRootAccessto access files as root
I look at the policy JSON. I see that I can mount and read (ClientMount) the file system, and I can write (ClientWrite) in the file system, but since I selected the option to disable root access, I don’t have ClientRootAccess permissions.
Similarly, I can attach a policy to an IAM user or role to give specific permissions. For example, I create a IAM role to give full access to this file system (including root access) with this policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite",
"elasticfilesystem:ClientRootAccess"
],
"Resource": "arn:aws:elasticfilesystem:us-east-2:123412341234:file-system/fs-d1188b58"
}
]
}I start an Amazon Elastic Compute Cloud (Amazon EC2) instance in the same Amazon Virtual Private Cloud (Amazon VPC) as the EFS file system, using Amazon Linux 2 and a security group that can connect to the file system. The EC2 instance is using the IAM role I just created.
The open source efs-utils are required to connect a client using IAM authentication, in-transit encryption, or both. On Amazon Linux 2, I can install efs-utils using yum. You can find instructions for other Linux distributions in this repository.
To mount the EFS file system, I use the mount command. To leverage in-transit encryption, I add the tls option. I am not using IAM authentication here, so the permissions I specified for the “*” principal in my file system policy apply to this connection.
My file system policy disables root access by default, so I can’t create a new file as root.
I now use IAM authentication adding the iam option to the mount command (tls is required for IAM authentication to work).
When I use this mount option, the IAM role from my EC2 instance profile is used to connect, along with the permissions attached to that role, including root access:
Here I used the IAM role to have root access. Other common use cases are to enforce in-transit encryption (using the aws:SecureTransport condition key) or create different roles for clients needing write or read-only access.
EFS IAM permission checks are logged by AWS CloudTrail to audit client access to your file system. For example, when a client mounts a file system, a NewClientConnection event is shown in my CloudTrail console.
Using EFS Access Points
EFS access points allow you to easily manage application access to NFS environments, specifying a POSIX user and group to use when accessing the file system, and restricting access to a directory within a file system.
Use cases that can benefit from EFS access points include:
- Container-based environments, where developers build and deploy their own containers (you can also see this blog post for using EFS for container storage).
- Data science applications, that require read-only access to production data.
- Sharing a specific directory in your file system with other AWS accounts.
In the EFS console, I create two access points for my file system, each using a different POSIX user and group:
/data– where I am sharing some data that must be read and updated by multiple clients./config– where I share some configuration files that must not be updated by clients using the/dataaccess point.
I used file permissions 755 for both access points. That means that I am giving read and execute access to everyone and write access to the owner of the directory only. Permissions here are used when creating the directory. Within the directory, permissions are under full control of the user.
I mount the /data access point adding the accesspoint option to the mount command:
I can now create a file, because I am not doing that as root, but I am automatically using the user and group ID of the access point:
I mount the file system again, without specifying an access point. I see that datafile was created in the /data directory, as expected considering the access point configuration. When using the access point, I was unable to access any files that were in the root or other directories of my EFS file system.
To use IAM authentication with access points, I add the iam option:
I can restrict a IAM role to use only a specific access point adding a Condition on the AccessPointArn to the policy:
"Condition": {
"StringEquals": {
"elasticfilesystem:AccessPointArn" : "arn:aws:elasticfilesystem:us-east-2:123412341234:access-point/fsap-0204ce67a2208742e"
}
}Using IAM authentication and EFS access points together simplifies securely sharing data for container-based architectures and multi-tenant-applications, because it ensures that every application automatically gets the right operating system user and group assigned to it, optionally limiting access to a specific directory, enforcing in-transit encryption, or giving read-only access to the file system.
Available Now
IAM authorization for NFS clients and EFS access points are available in all regions where EFS is offered, as described in the AWS Region Table. There is no additional cost for using them. You can learn more about using EFS with IAM and access points in the documentation.
It’s now easier to create scalable architectures sharing data and configurations. Let me know what you are going use these new features for!
— Danilo