EFS access points should enforce a user identity
Without a POSIX user identity on an EFS access point, NFS clients can connect as any user, including root. This undermines access points entirely, because a client application can impersonate any UID/GID and read or modify files it shouldn't.
Enforcing a fixed user identity at the access point level removes trust in the client. Even if a container or EC2 instance is compromised, the attacker operates under the constrained UID/GID rather than escalating to root on the file system.
Retrofit consideration
Changing the POSIX user on an existing access point requires replacing the access point resource. Verify that workloads referencing the access point ID can tolerate the new resource ID and that file ownership on existing directories matches the enforced uid/gid.
Implementation
Choose the approach that matches how you manage Terraform.
Use AWS provider resources directly. See docs for the resources involved: aws_efs_access_point.
resource "aws_efs_access_point" "this" {
file_system_id = "fs-abc123"
posix_user {
gid = 1000
uid = 1000
}
root_directory {
creation_info {
owner_gid = 1000
owner_uid = 1000
permissions = "755"
}
path = "/data"
}
}
What this control checks
The aws_efs_access_point resource must include a posix_user block with both uid and gid set to integer values. Omitting the block, or defining it without valid uid and gid values, fails this control. The secondary_gids argument inside posix_user is optional. The root_directory.creation_info sub-block also accepts owner_uid, owner_gid, and permissions, but those govern directory creation ownership, not runtime NFS identity. This control only evaluates the posix_user block.
Common pitfalls
Confusing root_directory.creation_info with posix_user
The
root_directory.creation_infoblock acceptsowner_uidandowner_gid, which set directory ownership at creation time. Those do not satisfy this control. Theposix_userblock at the top level ofaws_efs_access_pointis what enforces the runtime NFS identity for all client connections.Access point replacement on posix_user change
The
posix_userattributes are ForceNew in the AWS provider. Changinguidorgiddestroys and recreates the access point, generating a new access point ID. Any ECS task definitions usingaccessPointIdmust be updated accordingly.UID 0 technically passes but defeats the purpose
Setting
posix_user { uid = 0, gid = 0 }satisfies the structural check because a POSIX user is defined. It also grants root-level access through the access point, negating the security benefit entirely. Pair this control with a policy or Sentinel rule that rejects uid 0.
Audit evidence
AWS Config rule evaluation results showing all AWS::EFS::AccessPoint resources as COMPLIANT are the primary audit artifact. Supplementary evidence is an export from aws efs describe-access-points filtered to the PosixUser field for each access point, or EFS console screenshots showing the enforced user identity. CloudTrail CreateAccessPoint events confirm that access points were provisioned with POSIX user identity parameters from initial creation.
Framework-specific interpretation
PCI DSS v4.0: Requirement 7 scopes access to system components and cardholder data by business need. Without a fixed POSIX identity, an NFS client on shared EFS storage can read or write files as any UID, which breaks that access scoping entirely. A defined posix_user on each access point is how you enforce per-workload file-level boundaries on storage that processes or stages cardholder data.
Related controls
Tool mappings
Use these identifiers to cross-reference this control across tools, reports, and evidence.
Compliance.tf Control:
efs_access_point_enforce_user_identityAWS Config Managed Rule:
EFS_ACCESS_POINT_ENFORCE_USER_IDENTITYCheckov Check:
CKV_AWS_330Powerpipe Control:
aws_compliance.control.efs_access_point_enforce_user_identityProwler Check:
efs_access_point_enforce_user_identityAWS Security Hub Control:
EFS.4
Last reviewed: 2026-03-09