chore(efs): scope down overly permissive AnyPrincipal in anonymous access policy

[pahud]

Issue # (if applicable)

N/A - Security improvement and test reliability fix. Related to #36224

Reason for this change

Primary goal: Current implementation for anonymousAccess: false is essentially derived from EFS console. With this default resource policy

1. No identity principal can mount this filesystem until explicitly granted with ClientMount
2. No cross-account identity can do that until we add an additional statement in the policy to allow that with ClientMount

so this policy is general fine with protective purpose but confusing. We should scope down the resource policy principal definition from any arn('*') to account root principal as this could be a concern(though it's default behavior from EFS console)

Secondary goal: Update the existing integration test to validate this policy change. The current test uses EC2 NANO instances with AL2023, which has critical reliability issues:

• NANO instances are subject to OOM (Out of Memory) kills and cannot successfully complete the test
• AL2023's automatic dnf package updates conflict with our NFS utils package installation, causing timeouts
• This combination makes the test extremely difficult to maintain and cannot guarantee successful deployment

We replace the EC2-based implementation with Lambda functions to simplify the process and ensure reliable test execution.

Description of changes

1. EFS File System Policy Security Fix (packages/aws-cdk-lib/aws-efs/lib/efs-file-system.ts):

• Changed principal from AnyPrincipal (AWS: '*') to AccountRootPrincipal to scope down overly permissive access
• Resource policy intentionally does NOT include ClientMount action - principals must be explicitly granted via grantRead(), grantReadWrite(), or grantRootAccess() methods
• Added comprehensive documentation explaining the policy behavior and why ClientMount is excluded
• Restricts access to IAM principals within the same AWS account only
• Prevents unintended cross-account access while requiring explicit grants for same-account IAM principals

2. Integration Test Refactor (packages/@aws-cdk-testing/framework-integ/test/aws-efs/test/integ.efs.permission.ts):

• Replaced EC2 NANO instances with Lambda functions to eliminate OOM and package management issues
• Added EFS Access Point for Lambda mounting at /mnt/efs
• Replaced SSM command invocations with direct Lambda function invocations
• Added ASCII architecture diagram showing Lambda-to-EFS connectivity
• Three Lambda functions test different scenarios: read-write, read-only, no permissions
• Eliminates dnf auto-update conflicts and ensures reliable test execution

Key technical changes:

• Policy: AnyPrincipal() → AccountRootPrincipal(), ClientMount intentionally excluded from resource policy
• Test: EC2 NANO + SSM → Lambda + direct invocations
• Reliability: Eliminated OOM kills, package management conflicts, and deployment failures

Describe any new or updated permissions being added

EFS File System Policy Change:

• Before: Used AWS: '*' (any principal) with ClientWrite and ClientRootAccess actions
• After: Uses AccountRootPrincipal (account root) with only ClientWrite and ClientRootAccess actions

This change is more restrictive and follows AWS security best practices:

• Primary improvement: Scopes down from AnyPrincipal to AccountRootPrincipal, limiting access to IAM principals within the same AWS account
• Prevents anonymous cross-account access
• Requires explicit grants via grantRead(), grantReadWrite(), or grantRootAccess() for principals to mount the filesystem
• ClientMount is intentionally excluded from the resource policy to enforce explicit grants through identity-based permissions

Description of how you validated changes

• Unit tests: Updated 5 test cases in efs-file-system.test.ts to reflect the new policy structure with AccountRootPrincipal and ClientMount action
• Integration tests: The refactored integration test validates:
  • WriteLambda can write and read files on EFS (grantReadWrite)
  • ReadLambda can read but not write (grantRead, permission denied on write)
  • AnonymousLambda cannot access EFS (no grant, access denied)
  • All tests use Lambda function invocations with payload assertions

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

(This review is outdated)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.