Skip to content
Ask AI about this
Help improve this page

EFS access points should enforce a root directory

EFS access points exist to enforce application-specific entry points into a shared file system. When the root directory is left as /, every application or container mounting through that access point can traverse the entire file system, including directories belonging to other workloads. This turns a multi-tenant file system into a flat, shared namespace with no isolation.

Setting a non-root path (e.g., /app1/data) ensures that NFS clients connecting through the access point can only see and interact with that subtree. This limits blast radius if credentials are compromised and prevents accidental cross-application data access.

Retrofit consideration

Changing the root_directory path on an existing access point forces replacement of the resource. Applications referencing the old access point ID will lose connectivity until updated to use the new one. Verify that the target subdirectory exists or configure creation_info to auto-create it with correct ownership.

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 policy checks aws_efs_access_point resources: the root_directory block must contain a path argument with a value other than /. If root_directory is omitted entirely, EFS defaults to / and the check fails. A passing configuration looks like root_directory { path = "/app1/data" }. When the target path doesn't yet exist on the file system, include the nested creation_info block with owner_gid, owner_uid, and permissions so EFS creates the directory on first mount. Any access point where path equals / or root_directory is absent fails.

Common pitfalls

  • Omitting root_directory defaults to /

    Terraform won't error if you omit root_directory on aws_efs_access_point, but AWS defaults Path to /. The control silently fails and nothing in the apply output indicates the problem. Always set root_directory { path = "..." } explicitly.

  • Missing creation_info causes mount failures

    NFS clients will get I/O errors if root_directory.path points to a directory that doesn't exist yet and creation_info isn't set. The terraform apply succeeds without complaint. Add creation_info with owner_gid, owner_uid, and permissions so EFS creates the directory on first mount.

  • Access point replacement on path change

    The root_directory.path argument is ForceNew in the AWS provider, so changing it destroys and recreates the access point with a new id. Any ECS task definition, Lambda mount config, or fstab entry referencing the old access point ID must be updated at the same time, or those workloads will fail to mount.

  • Path must be absolute

    The path value must start with / (e.g., /data/app). A relative path like data/app is rejected by the AWS API. The other edge case: / is technically absolute but fails the control, since the entire point is to scope the mount point below root.

Audit evidence

Auditors expect evaluation results from AWS Config (custom rule or conformance pack) or equivalent policy tooling confirming all EFS access points have a non-root path configured. aws efs describe-access-points output showing RootDirectory.Path set to something other than / for every access point is the most direct evidence. Console screenshots from the EFS access points tab work as supplementary documentation. Policy tooling reports that map each access point ARN to its configured path give auditors a single artifact covering the full inventory.

Framework-specific interpretation

PCI DSS v4.0: Requirement 7.2 calls for access to system components and cardholder data to be restricted to the minimum necessary. Scoping an EFS access point to a specific subdirectory rather than / is one way to satisfy that at the storage layer, limiting what any given workload can reach through a shared file system.

Tool mappings

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

  • Compliance.tf Control: efs_access_point_enforce_root_directory

  • AWS Config Managed Rule: EFS_ACCESS_POINT_ENFORCE_ROOT_DIRECTORY

  • Checkov Check: CKV_AWS_329

  • Powerpipe Control: aws_compliance.control.efs_access_point_enforce_root_directory

  • Prowler Check: efs_access_point_enforce_root_directory

  • AWS Security Hub Control: EFS.3

Last reviewed: 2026-03-09