refactor(cloudfront): reorganize into atomic submodules under composition/cloudfront-v2 with registry module v6

[itsharshvb]

Summary

This PR introduces a complete reorganization of CloudFront infrastructure modules, moving from a monolithic v1 approach to atomic submodules under modules/composition/cloudfront-v2/.

Motivation

The existing v1 modules (cloudfront-distribution, cloudfront-functions, cloudfront-logging, cloudfront-policies, cloudfront-access-control) were tightly coupled standalone modules at the modules/ root level. This created:

• Large blast radius — any change required touching the entire distribution
• Custom distribution module maintenance burden
• No clean separation between concerns (OAC, logging, policies, functions)

What's Changed

Deleted (v1 cleanup)

• modules/cloudfront-distribution/ — custom distribution module
• modules/cloudfront-functions/ — standalone functions module
• modules/cloudfront-logging/ — standalone logging module
• modules/cloudfront-policies/ — standalone policies module
• modules/cloudfront-access-control/ — standalone access control module

Created (v2 atomic submodules)

All relocated under modules/composition/cloudfront-v2/:

Submodule	Purpose
access-control/oac/	Creates aws_cloudfront_origin_access_control resources
access-control/oai/	Creates aws_cloudfront_origin_access_identity resources (legacy compat)
distribution/	Wrapper around terraform-aws-modules/cloudfront/aws ~> 6.0
functions/	Creates and manages CloudFront functions
logging/	Creates S3 logging bucket with CloudFront log delivery permissions
policies/	Creates custom/managed cache, origin-request, and response-headers policies

Key Improvements

1. Registry module v6: Distribution wrapper uses terraform-aws-modules/cloudfront/aws ~> 6.0 instead of a custom module. This provides:

   • Native OAC support (inline creation via origin_access_control variable)
   • Active maintenance and AWS provider v6 compatibility
   • Built-in VPC Origin, gRPC, and HTTP/3 support

2. Atomic design: No monolithic composition wrapper. Each submodule is independently callable with its own state file, minimizing blast radius.

3. OAC integration:

   • Distribution wrapper accepts origin_access_control map for inline OAC creation
   • Exposes oac_objects output (full OAC objects with id/arn) for S3 bucket policy consumption
   • Origins reference OAC by key: origin_access_control = "my-oac-key"

4. OAI backward compatibility: Standalone access-control/oai/ submodule retained for existing OAI-based origins.

5. Consistent patterns: Follows lambda-resource composition precedent — submodules grouped under composition/ rather than scattered at modules/ root.

Breaking Changes

• Old module paths (modules/cloudfront-*) are removed. Live layer terragrunt configs must update source paths to modules/composition/cloudfront-v2/{submodule}.
• Distribution outputs renamed (removed cloudfront_ prefix to match registry module v6 convention):
  • cloudfront_distribution_id → distribution_id
  • cloudfront_distribution_arn → distribution_arn
  • etc.
• OAI no longer supported in distribution wrapper (v6 dropped it; use standalone access-control/oai/ or migrate to OAC).

Migration Path

Live layer configs should be updated separately:

# Old
source = "git::...//terraform/aws/modules/cloudfront-distribution"

# New
source = "git::...//terraform/aws/modules/composition/cloudfront-v2/distribution"

[sentinelone-cnapp-aps1]

SentinelOne IaC Issues Detector

❌ Detected 3 issue(s) in your pull request

Here are the detected issues.

Resource	File	Issue Message	Severity
aws_s3_bucket.logs	main.tf	Terraform - Missing MFA Delete feature in S3 Bucket configuration	MEDIUM
aws_cloudfront_distribution.this	main.tf	Terraform - CloudFront distribution should use a custom SSL certificate	MEDIUM
aws_s3_bucket.logs	main.tf	Terraform - AWS S3 Buckets not encrypted With KMS Customer Managed Key (CMK)	LOW

---

SentinelOne CNS is a cloud-agnostic, agentless CSPM & CWPP solution that continuously detects and prevents vulnerabilities that have the highest probability of being exploited in Azure, AWS, Google Cloud, and Kubernetes.