Description
An EFS customer managed KMS key lets your organization control the key policy and lifecycle. Enabling encryption without kms_key_id can use an AWS managed key, so the absence of a customer key does not by itself mean that stored data is unencrypted.
Define key-management requirements for shared files and verify the actual encryption state and key. Configure file permissions and TLS for mounts separately.
Potential impact
- The default key may not meet organizational controls that require a customer managed key.
- An actually unencrypted file system lacks protection from encryption at rest.
Remediation
Use encrypt: yes and a required customer managed kms_key_id when creating a file system. Verify that the key is in the same Region and has the necessary permissions. Existing encryption and key settings cannot be changed, so migrate data to a new file system instead of only editing playbook options. Verify data consistency, mount cutover and normal access.
Examples
Replace the example key, subnet and security group values for your environment. Check the actual state first if a file system with the same name already exists.
Before
- name: EFS 생성
community.aws.efs:
state: present
name: myTestEFS
encrypt: no
tags:
Name: myTestNameTag
purpose: file-storage
targets:
- subnet_id: subnet-748c5d03
security_groups:
- sg-1a2b3c4d
This does not request encryption for a new file system.
After
- name: EFS 생성
community.aws.efs:
state: present
name: myTestEFS
encrypt: yes
tags:
Name: myTestNameTag
purpose: file-storage
targets:
- subnet_id: subnet-748c5d03
security_groups:
- sg-1a2b3c4d
kms_key_id: some-key-id
This requests a new file system encrypted with a customer managed key. These options alone do not encrypt an existing, unencrypted myTestEFS.