feat: providing granuarity on network ACLs

[imprateeksh]

Description

Narrowing down the network connectivity rules as mentioned below:

• On inbound: source : VPC address prefixes ; destination cidr 10.0.0.0/8
• On outbound: source cidr is 10.0.0.0/8 , destination: VPC address prefixes.
  (There is one ACL rule per VPC address prefix.)

Types of changes in this PR

No release required

• Examples or tests (addition or updates of examples or tests)
• Documentation update
• CI-related update (pipeline, etc.)
• Other changes that don't affect Terraform code

Release required

• Bug fix (patch release (x.x.X): Change that fixes an issue and is compatible with earlier versions)
• New feature (minor release (x.X.x): Change that adds functionality and is compatible with earlier versions)
• Breaking change (major release (X.x.x): Change that is likely incompatible with previous versions)

Release notes content

Reducing the ACL network rules by narrowing down the network connectivity as mentioned below:

• On inbound: source : VPC address prefixes ; destination cidr 10.0.0.0/8
• On outbound: source cidr is 10.0.0.0/8 , destination: VPC address prefixes.
  (There is one ACL rule per VPC address prefix.)

---

Checklist for reviewers

• If relevant, a test for the change is included or updated with this PR.
• If relevant, documentation for the change is included or updated with this PR.

Merge actions for mergers

• Merge by using "Squash and merge".

• Use a relevant conventional commit message that is based on the PR contents and any release notes provided by the PR author.

  The commit message determines whether a new version of the module is needed, and if so, which semver increment to use (major, minor, or patch).

[vbontempi]

For a more fined setup of outbound and inbound acl rules, should we limit outbound destination and inbound source to the vpc prefixes in the same way it is done for outbound source and inbound destination?

We are currently setting to the network cidr or to everything if this is null

[imprateeksh]

Hi @vbontempi Thank you for providing your valuable input. I think we need to restrict the destination in case of inbound and source in case of outbound to 10.0.0.0/8 (for now atleast) as @vburckhardt mentioned in the issue here , also the default value of variable network_cidr is set to 10.0.0.0/8 so this I think will not be null but this is generic null check which already exists.

[vbontempi]

Hi @vbontempi Thank you for providing your valuable input. I think we need to restrict the destination in case of inbound and source in case of outbound to 10.0.0.0/8 (for now atleast) as @vburckhardt mentioned in the issue here , also the default value of variable network_cidr is set to 10.0.0.0/8 so this I think will not be null but this is generic null check which already exists.

that's true as

terraform-ibm-landing-zone-vpc/variables.tf

Line 40 in da828a5

default = "10.0.0.0/8"

makes the default value of network_cidr to "10.0.0.0/8": in such a case the inbound destination and the outbound source will be set to this value.

However a value null for network_cidr explicitly set by the consumer will still set the rules values to anything ("0.0.0.0/0")

terraform-ibm-landing-zone-vpc/network_acls.tf

Line 56 in da828a5

destination = var.network_cidr != null ? var.network_cidr : "0.0.0.0/0"

terraform-ibm-landing-zone-vpc/network_acls.tf

Line 68 in da828a5

source = var.network_cidr != null ? var.network_cidr : "0.0.0.0/0"

Maybe limiting outbound destinations and inbound sources to the vpc prefixes may be the default behaviour in the case of a null value?
I know that I am probably 'splitting the hair' on this matter, I am trying to think from a SF perspective

@vburckhardt your thoughts? may it be a further enhancement to rules or something too much for the current requirements?

[vburckhardt]

Hello @imprateeksh - just one comment here.

[vburckhardt]

@vbontempi - I think the source for outbound and destination for inbound are not really relevant here anyways. In outbound, the source is always going to be the subnets the acl is attached to. And inbound, the destination is always the subnet to acl is attached to. So whether we put 10.0.0.0/8 (if the subnets fall in this address prefix) or 0.0.0.0/0 we end up with same behavior here.

[imprateeksh]

@vburckhardt / @ocofaigh - Could you please approve/merge this PR? I have made the changes as suggested.

[vburckhardt]

Missing , ibm_is_vpc_address_prefix.subnet_prefix as well in the depends_on list for data "ibm_is_vpc_address_prefixes" "get_address_prefixes" - I added it in a commit to this PR so that we can go ahead and merge it. Without this depends on, the acl is missing the prefixes added at

terraform-ibm-landing-zone-vpc/subnet.tf

Line 16 in 1e89ae2

resource "ibm_is_vpc_address_prefix" "subnet_prefix" {

[terraform-ibm-modules-ops]

🎉 This PR is included in version 5.1.0 🎉

The release is available on:

• GitHub release
• v5.1.0

Your semantic-release bot 📦🚀

[imprateeksh]

Thank you @vburckhardt