AWS Storage Blog

Authorize NFS clients outside of AWS with AWS IAM Roles Anywhere

Securely storing and authorizing access to data in the cloud is a top priority. One challenge faced by organizations is developing a consistent authorization experience to grant access to data for hybrid architectures.

Workloads running on AWS can access data stored on services like Amazon Elastic File System (Amazon EFS) using AWS Identity and Access Management (IAM) service roles to retrieve and rotate temporary short-lived credentials. For workloads outside of AWS, customers may be using IAM users with long-term credentials that never expire, introducing security concerns if those credentials are compromised. IAM Roles Anywhere provides hybrid workloads a more consistent authorization experience, following AWS best practices to use temporary credentials.

In this post, we’ll demonstrate how to authorize your NFS clients running outside AWS to your Amazon EFS file system using IAM Roles Anywhere. To better understand how IAM Roles Anywhere works, see this blog “Extend AWS IAM roles to workloads outside of AWS with IAM Roles Anywhere“. By working through the following solution, you will learn how to extend your file system to your locations outside AWS, such as an on-premises data center. The benefits include the ability to provide a single file system share between your cloud resources and local data center resources, using IAM to authorize access.

Solution overview

You can authorize access to an EFS file system using both IAM identity policies used by your NFS clients and a resource policy applied to your file system, shown in the following Figure 1. Resource policies control who has access and what actions they can perform on your file system, such as ClientMount, ClientWrite, and ClientRootAccess. It’s recommend to restrict who can access your file system by creating a resource policy that requires IAM client authorization. You do this by including the ARN of your IAM role used by your NFS client in the Principal element of the file system resource policy. This identity-based control is an added security layer for client access to the Amazon EFS mount target and replaces the default anonymous file system policy statement“Principal”:{"AWS": "*"}. Adding additional controls to your file systems via resource policies and IAM client authorization improves the defense in depth approach when coupled with standard POSIX permissions that are supported by Amazon EFS.

 

NFS Client IAM Authorization

Figure 1: NFS Client IAM Authorization

When you create an EFS file system associated to your VPC, Amazon EFS creates elastic network interfaces (ENI) in each of the subnets specified. These ENIs are assigned a private IPv4 address from the available IP address range of the subnets selected during deployment. Additionally, the ENIs are associated with a VPC security group used to control the traffic that is allowed to reach your file system. These identity and network based controls used together allow you to align with Zero Trust principals.

The Amazon EFS mount helper utility provides additional NFS client options that simplifies mounting your file systems and includes recommended mount options by default. When using Amazon EFS IAM authorization, the mount helper is required and you need to specify the tls and iam options, for example:

sudo mount -t efs -o tls,iam fs-01234567:/ /mnt/efsdemo/

When using the Amazon EFS mount helper on Amazon EC2, temporary credentials can be retrieved from the IAM service role attached to the EC2 instance. However, when your workload resides outside of AWS you may require another method to retrieve those temporary credentials. In the next section we’ll walk through using IAM Roles Anywhere to offer you a convenient method of retrieving temporary credentials from your role. NFS clients outside of AWS can use IAM Roles Anywhere to retrieve temporary AWS credentials from IAM roles authorized to your file system. IAM Roles Anywhere exchanges X.509 certificates issued by a public key infrastructure (PKI) for temporary AWS credentials. Certificates can be issued from your existing PKI Certificate Authority (CA) or from AWS Private Certificate Authority (AWS Private CA). For additional information refer to the IAM Roles Anywhere concepts documentation. The following Figure 2 illustrates using IAM Roles Anywhere to retrieve temporary AWS credentials and mount a file system from a Linux server outside of AWS over AWS Direct Connect or VPN connection. For more information on accessing a file systems outside of AWS please take a moment to read this walkthrough. Figure 2 depicts the authentication and authorization workflow when using IAM Roles Anywhere to retrieve temporary AWS security credentials to mount an EFS file system.

Authenticating and Authorizing access to EFS file system

Figure 2: Authenticating and Authorizing access to EFS file system

  1. When the mount command is issued, the Amazon EFS mount helper calls the AWS CLI to retrieve credentials.
  2. The AWS CLI uses the credential process feature to call the IAM Roles Anywhere credential helper tool.
  3. The IAM Roles Anywhere credential helper tool uses your X.509 certificate and private key to call the IAM Roles Anywhere feature, specifying from which IAM role to retrieve credentials.
  4. IAM Roles Anywhere validates the certificate and retrieves temporary credentials on your behalf from AWS Security Token Service (AWS STS).
  5. Temporary credentials are returned and used by the Amazon EFS mount helper to mount the file system.
  6. The Amazon EFS mount target security group validates the inbound source, protocol, and port are allowed.
  7. The EFS file system policy evaluates if the principal is authenticated (signed in) and is authorized (has permission) to the file system.

Prerequisites

For this walk through, you will need to have the following prerequisites:

Note: At the time of writing this blog IAM Roles Anywhere does not support encrypted private keys.

Walkthrough

I will now walkthrough the solution in the preceding Figure 2 to setup an Amazon EFS file system with IAM authorization and authentication. This walkthough will take you through the following steps:

  1. (Optional) Store your CA PEM certificate.
  2. Deploy the stack.
  3. Configure the AWS CLI to use the IAM Roles Anywhere credential helper tool.
  4. Update Hosts file.
  5. Update amazon-efs-utils for your AWS Region.
  6. Mount the file system.
  7. Verify EFS file system mount.

Step 1: (Optional) Store your CA PEM certificate

If you are using AWS Private Certificate Authority you can skip this step and proceed to Step 2. Using the AWS CLI, create an SSM parameter to store your external certificate bundle in Privacy Enhanced Mail (PEM) format. The CloudFormation stack will reference this parameter to create the trust anchor.

  1. Create the SSM parameter with the following command:
aws ssm put-parameter --name "/demo/efsanywheredemo/cabundlepem"
--value "file://bundlefolder/CAbundle.pem" --type String

Note: Replace the file path for your CA bundle PEM file

Step 2: Deploy the stack

Next, you will need to deploy the stack in the same AWS Region as your VPC and Subnet with network connectivity to your Linux server running outside of AWS. If you are using AWS Private Certificate Authority, the private CA must be created in the same region.

  1. Download the CloudFormation template efs-iam-roles-anywhere.yaml.
  2. On the AWS CloudFormation console, choose Create stack.
  3. Select Upload a template file and choose Choose file. Upload the efs-iam-roles-anywhere.yaml, then choose Next.
  4. On the Specify stack details page, enter a stack name and the requested parameters.
  5. On the Configure stack options page, choose Next.
  6. On the Review page, select I acknowledge that AWS CloudFormation might create IAM resources, and choose Create stack.
  7. The script takes less than 5 minutes to run and change to a CREATE_COMPLETE state. Once complete make note of your stack output values, you’ll need these in the proceeding steps.

Step 3: Configure the AWS CLI to use the IAM Roles Anywhere credential helper tool

Using the AWS CLI external credential feature with the IAM Roles Anywhere credential helper tool, you can request temporary credentials for your Linux server. The EFS mount helper retrieves those temporary credentials from either /root/.aws/credentials or /root/.aws/config. It is recommended to not use the root user for day-to-day operations.

1. Log in to your Linux server and copy your end-entity X.509 certificate and private key PEM files locally.

Note: Your private key is a secret and should be properly secured.

2. If you installed the AWS CLI for the first time the /root/.aws/config file may not exist. To create it, run the following command:

sudo mkdir -p /root/.aws/ && sudo touch /root/.aws/config

3. Create a named profile section in the AWS CLI config file to be used by the EFS mount helper by running the following command:

echo [profile efs] | sudo tee -a cat /root/.aws/config

4. After the CloudFormation stack has completed, using your text editor of choice, open /root/.aws/config and append the value of ProfileCredentials in the outputs section of your stack to your AWS CLI config file [profile efs], for example:

-[profile efs]
 credential_process = /aws_signing_helper credential-process 
--certificate /certificate.pem 
--private-key /private-key.pem 
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:111222333444:trust-anchor/293a65af-145f-4064-9764-02f9d2c3be72 
--profile-arn arn:aws:rolesanywhere:us-east-1:111222333444:profile/c310e5e6-d165-40c4-a0bf-7aa4552db931 
--role-arn arn:aws:iam::111222333444:role/efstest1-EFSanywhereDemoIAMRole-SI4HDR4M802R

Note: Replace the file paths for your IAM Roles Anywhere: aws_signing_helper tool, certificate.pem and private-key.pem.

Step 4: Update Hosts file

To locally resolve the Amazon EFS hostname with the ENI IPv4 address of your EFS mount target, update the local /etc/hosts file on your Linux server.

  1. Log in to your Linux server and run the command copied from the value of HostsCommand in the outputs section of your stack in Step 2, for example:
echo '172.16.2.191 fs-01234567.efs.us-east-1.amazonaws.com fs-01234567' | sudo tee -a /etc/hosts

Step 5: Update amazon-efs-utils for your AWS Region

When using the Amazon EFS mount helper outside of AWS, update the efs-utils.conf file on your Linux server to reflect your AWS region.

  1.  Using your text editor of choice, open /etc/amazon/efs/efs-utils.conf for editing.
  2.  Find the line #region = and uncomment by removing the #.
  3. Append your AWS region to the region =, for example:
region = us-east-1

Step 6: Mount the file system

Mount the file system to your Linux server using the Amazon EFS mount helper with the temporary credentials from the AWS CLI.

1. Log in to your Linux server and create a mount directory by running the following command:

sudo mkdir /mnt/efsdemo

2. Run the command copied from the value of the MountCommand in the outputs section of your stack in Step 2, for example:

sudo mount -t efs -o tls,iam,awsprofile=efs fs-01234567.efs.us-east-1.amazonaws.com:/ /mnt/efsdemo/

3. (Optionally) To automatically mount the file system, run the command copied from the value of the FstabCommand in the outputs section in Step 2, for example:

echo 'fs-01234567.efs.us-east-1.amazonaws.com:/ /mnt/efsdemo efs _netdev,tls,iam,awsprofile=efs 0 0' | sudo tee -a /etc/fstab

Step 7: Verify EFS file system mount

1. While logged into your Linux server check that the mount command was successful by running the Linux df command:

sudo df -h

Example df command output:

$ sudo df -h
Filesystem                                          Size  Used Avail Use% Mounted on
devtmpfs                                             63G     0   63G   0% /dev
tmpfs                                                63G     0   63G   0% /dev/shm
tmpfs                                                63G  524K   63G   1% /run
tmpfs                                                63G     0   63G   0% /sys/fs/cgroup
/dev/nvme0n1p1                                      1.0T  904G  121G  89% /
127.0.0.1:/                                         8.0E     0  8.0E   0% /mnt/efsdemo
tmpfs                                                13G     0   13G   0% /run/user/0

2. Check that you have read permissions to the file system by running the Linux ls command:

sudo ls -l /mnt/

Example ls output:

total 4
drwxr-xr-x 2 root root 6144 Nov  7 19:08 efsdemo

3. Check that you can write a test file to the file system by running the Linux touch and lscommand:

sudo touch /mnt/efsdemo/testfile
ls -asl /mnt/efsdemo/

Example ls output:

total 8
4 drwxr-xr-x 2 root root 6144 Nov  7 19:13 .
0 drwxr-xr-x 3 root root   21 Nov  2 18:21 ..
4 -rw-r--r-- 1 root root    0 Nov  7 19:14 testfile

4. Check that you can delete the test file from the file system by running the Linux rm and ls command:

sudo rm /mnt/efsdemo/testfile
ls -asl /mnt/efsdemo/

Example ls output:

total 4
4 drwxr-xr-x 2 root root 6144 Nov  7 19:14 .
0 drwxr-xr-x 3 root root   21 Nov  2 18:21 ..

Additional security considerations

It’s strongly recommended to use attributes extracted from the X.509 end-entity certificate to restrict which certificates can obtain credentials from IAM Roles Anywhere. This is done by using condition statements in the IAM Roles Anywhere trust policy. IAM Roles Anywhere extracts theSubject,Issuer, andSubject Alternative Name (SAN) fields in the X.509 certificate and uses them as PrincipalTagsin the session. For example, a certificate may contain a SAN with the following:

Certificate:
...
    X509v3 extensions:
        X509v3 Subject Alternative Name: 
            DNS:nfsclient.outsideaws

Using the SAN information as a PrincipalTag you can edit the trust policy to append a condition statement.

  1. Sign in to the AWS Management Console and open the IAM console.
  2. On the IAM roles page, choose the role you want to use.

Note: The IAM role created in the walkthrough contains the name EFSanywhereDemoIAMRole.

  1. On the Trust relationships tab, choose Edit trust policy.
  2. Append a similar Condition statement to your trust policy that reflects attributes in your certificate, for example:
"Condition": {
          "StringEquals": {
            "aws:PrincipalTag/x509SAN/DNS": "nfsclient.outsideaws"
          }
        }

To learn more, see the trust policy for IAM Roles Anywhere

For added security IAM Roles Anywhere offers an interface VPC endpoints powered by AWS PrivateLink for private connectivity to the service directly from your VPC without the need for an Internet Gateway (IGW) or a public IP address. These virtual devices are horizontally scaled, redundant and highly available; they appear as network interfaces in your VPC and can be reached from your hybrid environments over Direct Connect or AWS site-to-site VPN. You can attach an endpoint policy to your IAM Roles Anywhere VPC endpoint to control access to the service. Like your EFS file system resource policy, endpoint policies are a type of resource policy and provide you additional fine-grain control over which IAM principals can perform certain actions against the service. Additionally, VPC endpoints use security groups to allow you to further restrict network access to the endpoint. Note that at the time of writing this blog the VPC endpoint policy does not support the action CreateSesssion.

Cleaning up

When you are finished using the resources created as part of this walk through, make sure to delete the CloudFormation stack to avoid incurring future charges. To do this:

  1. Unmount the EFS file system from your Linux server.
  2. Delete the stack by opening the AWS CloudFormation console.
  3. Select the stack that was created and choose Delete.
  4. Select Delete Stack when prompted.

Conclusion

In this post, we replaced the EFS default anonymous access resource policy with IAM authorization and granting access to an IAM Role. We walked through establishing a trust anchor between IAM roles Anywhere and your certificate authority. We then configured your IAM Role to trust IAM Roles Anywhere. These trusts allow your Linux server to use the IAM Roles Anywhere credential helper tool to authenticate using X.509 certificates and obtain temporary AWS credentials.

Additionally, we walked through updating your Linux server local hosts file to resolve the file system name and configuring the AWS CLI to use the IAM Roles Anywhere credential helper tool. This included walking through creating a CLI profile that was used by the EFS mount helper tool to connect to the file system. Finally, we reviewed some additional security considerations to strengthen your security posture when using IAM Roles Anywhere.

By working through these steps you have the tools and knowledge available to extend your file system to your locations outside AWS, such as an on-premises data center. This solution will enable you to provide a single file system share between your cloud resources and local data center resources, using IAM to authorize access. Amazon IAM Roles Anywhere and Amazon EFS provide a way to securely authenticate and authorize access to a shared network file system between your AWS account and resources outside of AWS. To learn more about Amazon EFS IAM integration, read the blog post “New for Amazon EFS – IAM Authorization and Access Points”. Thank you!

TAGS: , , ,
Michael Sullivan

Michael Sullivan

Michael is a Solutions Architect with a focus on infrastructure security at AWS. He joined AWS in 2018 and enjoys helping customers design solutions that meet the most demanding security requirements.

Mike Fauntleroy

Mike Fauntleroy

Mike is a Storage Specialist at AWS who has been helping customers democratize new AWS storage services since 2018. His interests outside of AWS include auto sports, hockey, and spending time with his family.