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_info block accepts owner_uid and owner_gid, which set directory ownership at creation time. Those do not satisfy this control. The posix_user block at the top level of aws_efs_access_point is what enforces the runtime NFS identity for all client connections.

Access point replacement on posix_user change

The posix_user attributes are ForceNew in the AWS provider. Changing uid or gid destroys and recreates the access point, generating a new access point ID. Any ECS task definitions using accessPointId must 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.

EFS file systems should have encryption at rest enabled

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

Compliance.tf Control: efs_access_point_enforce_user_identity
AWS Config Managed Rule: EFS_ACCESS_POINT_ENFORCE_USER_IDENTITY
Checkov Check: CKV_AWS_330
Powerpipe Control: aws_compliance.control.efs_access_point_enforce_user_identity
Prowler Check: efs_access_point_enforce_user_identity
AWS Security Hub Control: EFS.4

Last reviewed: 2026-03-09