Enhancement | Default Disabling of Restrictive Network ACLs (NACLs)

[exequielrafaela]

Describe the Feature

Within the le-tf-infra-aws-template repository, there's a need to ensure that restrictive Network ACLs (NACLs) are disabled by default. This proactive approach will prevent potential complications, streamline user experience, and ensure that the use of NACLs is only when explicitly required and approved.

Expected Behavior

1. In the default configuration, NACLs should be disabled, particularly in the shared account base-network layer variables.
2. Expected variables setup:

     manage_default_network_acl    = true
     public_dedicated_network_acl  = false // use dedicated network ACL for the public subnets.
     private_dedicated_network_acl = false // use dedicated network ACL for the private subnets.

3. Users or tech leads wishing to enable NACLs must undergo an explicit approval process.
4. Feedback mechanisms should be in place to inform users of the status of NACLs and any associated permissions.
5. Comprehensive testing should be conducted to ensure that the default disabling of NACLs does not introduce new issues.

Use Case

Given the recurrent challenges and complications associated with NACLs, especially during real-time troubleshooting with clients, a safer default approach is to have them disabled. This ensures a smoother experience for most users while still providing the flexibility to enable NACLs when necessary.

Describe Ideal Solution

1. Update the default configurations in the le-tf-infra-aws-template repository to have NACLs disabled.
2. Implement a clear and straightforward process for users or tech leads to request and approve the activation of NACLs.
3. Enhance the architecture's feedback mechanisms to provide users with clear information about NACL status and permissions.
4. Strengthen testing protocols to validate the behavior and implications of having NACLs disabled by default.

Alternatives Considered

1. Maintaining the current setup and addressing NACL-related challenges reactively.
2. Offering granular NACL controls without changing the default state.

Additional Context

• The emphasis is on providing a safer and more user-friendly default setting by having restrictive NACLs disabled.
• The proposed changes aim to reduce the frequency of NACL-related issues while still offering the capability to use them when justified.

[rodriguez-matias]

Hi @exequielrafaela, just to confirm. The idea is to add these points to the leverage documentation, correct?

Describe Ideal Solution

• Implement a clear and straightforward process for users or tech leads to request and approve the activation of NACLs.
• Enhance the architecture's feedback mechanisms to provide users with clear information about NACL status and permissions.
• Strengthen testing protocols to validate the behavior and implications of having NACLs disabled by default.

[exequielrafaela]

@rodriguez-matias Matu I think It could be useful if we have a dedicated VPC NACLs entry with the info in this PR in the doc under the Ref Arch Network section:

[rodriguez-matias]

Working on this documentation in this branch
https://github.com/binbashar/le-ref-architecture-doc/tree/ISSUE-36/feat/defaul-network-acl