# Data encryption in Amazon EFS
Amazon EFS provides comprehensive encryption capabilities to protect your data both at rest and in transit.
+ **Encryption at rest** – Encrypts data stored on your file system.
+ **Encryption in transit** – Encrypts data as it travels between your clients and the file system.
If your organization is subject to corporate or regulatory policies that require encryption of data and metadata, we recommend creating a file system that is encrypted at rest and mounting your file system using encryption of data in transit.
**Topics**
+ [Encrypting data at rest](encryption-at-rest.md)
+ [Encrypting data in transit](encryption-in-transit.md)
+ [Using AWS KMS keys for Amazon EFS](EFSKMS.md)
+ [Troubleshooting encryption](troubleshooting-efs-encryption.md)
# Encrypting data at rest
Encryption at rest encrypts data stored on your EFS file system. This helps you meet compliance requirements and protect sensitive data from unauthorized access. Your organization might require encryption of all data that meets a specific classification or is associated with a particular application, workload, or environment.
**Note**
The AWS key management infrastructure uses Federal Information Processing Standards (FIPS) 140-3 approved cryptographic algorithms. The infrastructure is consistent with National Institute of Standards and Technology (NIST) 800-57 recommendations.
When you create a file system using the Amazon EFS console, encryption at rest is enabled by default. When using the AWS CLI, API, or SDKs to create a file system, you must explicity enable encryption.
After you create an EFS file system, you cannot change its encryption setting. This means that you cannot modify an unencrypted file system to make it encrypted. Instead, [replicate the file system](efs-replication.md) to copy data from the unencrypted file system to a new encrypted file system. For more information, see [ How do I turn on encryption at rest for an existing EFS file system?](https://repost.aws/knowledge-center/efs-turn-on-encryption-at-rest)
## How encryption at rest works
In an encrypted file system, data and metadata are encrypted by default before being written to storage and are automatically decrypted when read. These processes are handled transparently by Amazon EFS, so you don't need to modify your applications.
Amazon EFS uses AWS KMS for key management as follows:
+ **File data encryption** – The contents of your files are encrypted using the KMS key that you specify. This can be either:
+ The AWS owned key for Amazon EFS (`aws/elasticfilesystem`) – Default option, no additional charges.
+ A customer managed key that you create and manage – Provides additional control and audit capabilities.
+ **Metadata encryption** - File names, directory names, and directory contents are encrypted using a key that Amazon EFS manages internally.
### Encryption process
When a file system is created or rerplicated to a file system in the same account, Amazon EFS uses a [ Forward Access Session (FAS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html) to make KMS calls using the caller's credentials. In CloudTrail logs, the `kms:CreateGrant` call appears to be made by the same user identity that created the file system or replication. You can identify Amazon EFS service calls in CloudTrail by looking for the `invokedBy` field with the value `elasticfilesystem.amazonaws.com`. The resource policy on the KMS key must allow the `CreateGrant` action for FAS to make the call.
**Important**
You manage control of the grant, and can revoke it at any time. Revoking the grant prevents Amazon EFS from accessing the KMS key for future operations. For more information, see [Retiring and revoking grants](https://docs.aws.amazon.com/kms/latest/developerguide/grant-delete.html) in the *AWS Key Management Service Developer Guide.*.
When using customer managed KMS keys, the resource policy must also allow the Amazon EFS service principal and include the `kms:ViaService` condition to restrict access to the specific service endpoint. For example:
```
"kms:ViaService":
"elasticfilesystem.us-east-2.amazonaws.com"
```
Amazon EFS uses industry-standard AES-256 encryption algorithm to encrypt data and metadata at rest.
For more information about KMS key policies for Amazon EFS, see [Using AWS KMS keys for Amazon EFS](EFSKMS.md).
## Enforcing encryption at rest for new file systems
You can use the `elasticfilesystem:Encrypted` IAM condition key in AWS Identity and Access Management (IAM) identity-based policies to enforce creation at rest when users create EFS file systems. For more information about using the condition key, see [Example: Enforce the creation of encrypted file systems](security_iam_id-based-policy-examples.md#using-iam-to-enforce-encryption-at-rest).
You can also define service control policies (SCPs) inside AWS Organizations to enforce Amazon EFS encryption for all AWS accounts in your organization. For more information about service control policies in AWS Organizations, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#orgs_manage_policies_scp) in the *AWS Organizations User Guide*.
# Encrypting data in transit
Amazon EFS supports encryption of data in transit with Transport Layer Security (TLS). When encryption of data in transit is declared as a mount option for your EFS file system, Amazon EFS establishes a secure TLS connection with your EFS file system upon mounting your file system. All NFS traffic is routed through this encrypted connection.
## How encrypting in transit works
We recommend using the EFS mount helper to mount your file system because it simplifies the mounting process as compared to mounting with NFS `mount`. The EFS mount helper manages the process by using either efs-proxy (for efs-utils version 2.0.0 and later) or stunnel (for efs-utils earlier versions) to establish a secure TLS connection with your EFS file system.
If you're not using the mount helper, you can still enable encryption of data in transit. The following are the steps to do so.
**To enable encryption of data in transit without using the mount helper**
1. Download and install `stunnel`, and note the port that the application is listening on. For more information, see [Upgrading `stunnel`](upgrading-stunnel.md).
1. Run `stunnel` to connect to your EFS file system on port 2049 using TLS.
1. Using the NFS client, mount `localhost:port`, where `port` is the port that you noted in the first step.
Because encryption of data in transit is configured on a per-connection basis, each configured mount has a dedicated `stunnel` process running on the instance. By default, the stunnel process used by the mount helper listens on a local port between 20049 and 20449, and it connects to Amazon EFS on port 2049.
**Note**
By default, when using the EFS mount helper with TLS, it enforces the use of the Online Certificate Status Protocol (OCSP) and certificate hostname checking. The EFS mount helper uses the stunnel program for its TLS functionality. Some versions of Linux don't include a version of stunnel that supports these TLS features by default. When using one of those Linux versions, mounting an EFS file system using TLS fails.
After you've installed the amazon-efs-utils package, to upgrade your system's version of stunnel, see [Upgrading `stunnel`](upgrading-stunnel.md).
For issues with encryption, see [Troubleshooting encryption](troubleshooting-efs-encryption.md).
When using encryption of data in transit, your NFS client setup is changed. When you inspect your actively mounted file systems, you see one mounted to 127.0.0.1, or `localhost`, as in the following example.
```
$ mount | column -t
127.0.0.1:/ on /home/ec2-user/efs type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=20127,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1)
```
When mounting with TLS and the EFS mount helper, you are reconfiguring your NFS client to mount to a local port. The EFS mount helper starts a client `stunnel` process that is listening on this local port, and `stunnel` is opening an encrypted connection to the EFS file system using TLS. The EFS mount helper is responsible for setting up and maintaining this encrypted connection and the associated configuration.
To determine which Amazon EFS file system ID corresponds to which local mount point, you can use the following command. Remember to replace *efs-mount-point* with the local path where you’ve mounted your file system.
```
grep -E "Successfully mounted.*efs-mount-point" /var/log/amazon/efs/mount.log | tail -1
```
When you use the EFS mount helper for encryption of data in transit, it also creates a process called `amazon-efs-mount-watchdog`. This process ensures that each mount's stunnel process is running, and stops the stunnel when the EFS file system is unmounted. If for some reason a stunnel process is terminated unexpectedly, the watchdog process restarts it.
# Using AWS KMS keys for Amazon EFS
Amazon EFS integrates with AWS Key Management Service (AWS KMS) for key management. Amazon EFS uses customer managed keys to encrypt your file system in the following way:
+ **Encrypting metadata at rest** – Amazon EFS uses the AWS managed key for Amazon EFS, `aws/elasticfilesystem`, to encrypt and decrypt file system metadata (that is, file names, directory names, and directory contents).
+ **Encrypting file data at rest** – You choose the customer managed key used to encrypt and decrypt file data (that is, the contents of your files). You can enable, disable, or revoke grants on this customer managed key. This customer managed key can be one of the two following types:
+ **AWS managed key for Amazon EFS** – This is the default customer managed key, `aws/elasticfilesystem`. You're not charged to create and store a customer managed key, but there are usage charges. To learn more, see [AWS Key Management Service pricing](https://aws.amazon.com/kms/pricing/).
+ **Customer managed key** – This is the most flexible KMS key to use, because you can configure its key policies and grants for multiple users or services. For more information on creating customer managed keys, see [Creating keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide.*
If you use a customer managed key for file data encryption and decryption, you can enable key rotation. When you enable key rotation, AWS KMS automatically rotates your key once per year. Additionally, with a customer managed key, you can choose when to disable, re-enable, delete, or revoke access to your customer managed key at any time. For more information, see [Using AWS KMS keys for Amazon EFS](#EFSKMS).
**Important**
Amazon EFS accepts only symmetric customer managed keys. You cannot use asymmetric customer managed keys with Amazon EFS.
Data encryption and decryption at rest are handled transparently. However, AWS account IDs specific to Amazon EFS appear in your AWS CloudTrail logs related to AWS KMS actions. For more information, see [Amazon EFS log file entries for encrypted-at-rest file systems](logging-using-cloudtrail.md#efs-encryption-cloudtrail).
## Amazon EFS key policies for AWS KMS
Key policies are the primary way to control access to customer managed keys. For more information on key policies, see [Key policies in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) in the *AWS Key Management Service Developer Guide. *The following list describes all the AWS KMS–related permissions that are required or otherwise supported by Amazon EFS for encrypted at rest file systems:
+ **kms:Encrypt** – (Optional) Encrypts plaintext into ciphertext. This permission is included in the default key policy.
+ **kms:Decrypt** – (Required) Decrypts ciphertext. Ciphertext is plaintext that has been previously encrypted. This permission is included in the default key policy.
+ **kms:ReEncrypt** – (Optional) Encrypts data on the server side with a new customer managed key, without exposing the plaintext of the data on the client side. The data is first decrypted and then re-encrypted. This permission is included in the default key policy.
+ **kms:GenerateDataKeyWithoutPlaintext** – (Required) Returns a data encryption key encrypted under a customer managed key. This permission is included in the default key policy under **kms:GenerateDataKey\$1**.
+ **kms:CreateGrant** – (Required) Adds a grant to a key to specify who can use the key and under what conditions. Grants are alternate permission mechanisms to key policies. For more information on grants, see [Grants in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) in the *AWS Key Management Service Developer Guide.* This permission is included in the default key policy.
+ **kms:DescribeKey** – (Required) Provides detailed information about the specified customer managed key. This permission is included in the default key policy.
+ **kms:ListAliases** – (Optional) Lists all of the key aliases in the account. When you use the console to create an encrypted file system, this permission populates the **Select KMS key** list. We recommend using this permission to provide the best user experience. This permission is included in the default key policy.
### AWS managed key for Amazon EFS KMS policy
The KMS policy JSON for the AWS managed key for Amazon EFS, `aws/elasticfilesystem` is as follows:
```
{
"Version": "2012-10-17",
"Id": "auto-elasticfilesystem-1",
"Statement": [
{
"Sid": "Allow access to EFS for all principals in the account that are authorized to use EFS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "elasticfilesystem.us-east-2.amazonaws.com",
"kms:CallerAccount": "111122223333"
}
}
},
{
"Sid": "Allow direct access to key metadata to the account",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"kms:Describe*",
"kms:Get*",
"kms:List*",
"kms:RevokeGrant"
],
"Resource": "*"
}
]
}
```
## Key states and their effects
The state of your KMS key directly affects access to your encrypted file system:
Enabled
Normal operation - full read and write access to the file system
Disabled
File system becomes inaccessible after a brief period. Can be re-enabled.
Pending deletion
File system becomes inaccessible. Deletion can be canceled during the waiting period.
Deleted
File system permanently inaccessible. This action cannot be reversed.
**Warning**
If you disable or delete the KMS key used for your file system, or revoke Amazon EFS access to the key, your file system will become inaccessible. This can result in data loss if you don't have backups. Always ensure you have proper backup procedures in place before making changes to encryption keys.
# Troubleshooting encryption
**Topics**
+ [Mounting with encryption of data in transit fails](#mounting-tls-fails)
+ [Mounting with encryption of data in transit is interrupted](#mounting-tls-interrupt)
+ [Encrypted-at-rest file system can't be created](#unable-to-encrypt)
+ [Unusable encrypted file system](#unusable-encrypt)
## Mounting with encryption of data in transit fails
By default, when you use the Amazon EFS mount helper with Transport Layer Security (TLS), it enforces hostname checking. Some systems don't support this feature, such as when you use Red Hat Enterprise Linux or CentOS. In these cases, mounting an EFS file system using TLS fails.
**Action to take**
We recommend that you upgrade the version of stunnel on your client to support hostname checking. For more information, see [Upgrading `stunnel`](upgrading-stunnel.md).
## Mounting with encryption of data in transit is interrupted
It's possible, however unlikely, that your encrypted connection to your Amazon EFS file system can hang or be interrupted by client-side events.
**Action to take**
If your connection to your Amazon EFS file system with encryption of data in transit is interrupted, take the following steps:
1. Ensure that the stunnel service is running on the client.
1. Confirm that the watchdog application `amazon-efs-mount-watchdog` is running on the client. You can find out whether this application is running with the following command:
```
ps aux | grep [a]mazon-efs-mount-watchdog
```
1. Check your support logs. For more information, see [Getting support logs](mount-helper-logs.md).
1. Optionally, you can enable your stunnel logs and check the information in those as well. You can change the configuration of your logs in `/etc/amazon/efs/efs-utils.conf` to enable the stunnel logs. However, doing so requires unmounting and then remounting the file system with the mount helper for the changes to take effect.
**Important**
Enabling the stunnel logs can use up a nontrivial amount of space on your file system.
If the interruptions continue, contact AWS Support.
## Encrypted-at-rest file system can't be created
You've tried to create a new encrypted-at-rest file system. However, you get an error message saying that AWS KMS is unavailable.
**Action to take**
This error can occur in the rare case that AWS KMS becomes temporarily unavailable in your AWS Region. If this happens, wait until AWS KMS returns to full availability, and then try again to create the file system.
## Unusable encrypted file system
An encrypted file system consistently returns NFS server errors. These errors can occur when EFS can't retrieve your master key from AWS KMS for one of the following reasons:
+ The key was disabled.
+ The key was deleted.
+ Permission for Amazon EFS to use the key was revoked.
+ AWS KMS is temporarily unavailable.
**Action to take**
First, confirm that the AWS KMS key is enabled. You can do so by viewing the keys in the console. For more information, see [Viewing Keys](https://docs.aws.amazon.com/kms/latest/developerguide/viewing-keys.html) in the *AWS Key Management Service Developer Guide*.
If the key is not enabled, enable it. For more information, see [Enabling and Disabling Keys](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) in the *AWS Key Management Service Developer Guide*.
If the key is pending deletion, then this status disables the key. You can cancel the deletion, and re-enable the key. For more information, see [Scheduling and Canceling Key Deletion](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html#deleting-keys-scheduling-key-deletion) in the *AWS Key Management Service Developer Guide*.
If the key is enabled, and you're still experiencing an issue, or if you encounter an issue re-enabling your key, contact AWS Support.