adding new subnet for crime-idam

[shabmama53]

Jira link

See PROJ-XXXXXX

Change description

Testing done

Security Vulnerability Assessment

CVE Suppression: Are there any CVEs present in the codebase (either newly introduced or pre-existing) that are being intentionally suppressed or ignored by this commit?

• Yes
• No

Checklist

• commit messages are meaningful and follow good commit message guidelines
• README and other documentation has been updated / added (if needed)
• tests have been updated / new tests has been added (if needed)
• Does this PR introduce a breaking change

Link to Terraform Plan

https://tfplan-viewer.hmcts.net/aks-cft-deploy/820

🤖AEP PR SUMMARY🤖

• environments/network/demo.tfvars 🛠️

  • Added a new subnet named "crime-idam" with address prefix 10.50.65.0/24.
  • Configured subnet delegation for PostgreSQL flexible servers allowing subnet join action.

• environments/network/ithc.tfvars 🛠️

  • Added a new subnet named "crime-idam" with address prefix 10.11.192.0/24.
  • Configured subnet delegation for PostgreSQL flexible servers allowing subnet join action.

• environments/network/perftest.tfvars 🛠️

  • Added a new subnet named "crime-idam" with address prefix 10.48.65.0/24.
  • Configured subnet delegation for PostgreSQL flexible servers allowing subnet join action.

• environments/network/preview.tfvars 🛠️

  • Added a new subnet named "crime-idam" with address prefix 10.101.129.0/24.
  • Configured subnet delegation for PostgreSQL flexible servers allowing subnet join action.

[github-actions]

Suggested Improvements

1. Consistent Indentation and Readability:

   • Indentation within the newly added delegations objects is inconsistent, making the code less readable.
   • Example improvement:
     hcl
     delegations = {
     postgres_flexible = {
     service_name = "Microsoft.DBforPostgreSQL/flexibleServers"
     actions = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
     }
     }

2. DRY (Don't Repeat Yourself):

   • The crime-idam subnet is repeated across multiple environments with identical delegations. Consider extracting common configurations into a shared file or module for reuse to reduce duplication.
   • Example: Define the common subnet configuration in a common-subnets.tfvars or a Terraform module.

3. Validation of Address Prefixes:

   • The address ranges (address_prefix) should be validated to ensure they don't overlap with existing subnets or reserved ranges. For example, confirm the 10.50.x.x ranges are appropriate for each environment.

4. Explicit Action Values:

   • Currently, the actions array includes only one value. If additional actions might be added in the future, consider specifying the exact action explicitly for clearer intent.
   • Example: Replace [\"Microsoft.Network/virtualNetworks/subnets/join/action\"] with a more scoped and textually described item, if possible (e.g., "joinSubnet" if supported).

5. Versioning and Comments:

   • The changes could benefit from inline comments indicating why this delegation is necessary for this subnet, particularly in environments like ithc and perftest.
   • Example:

     # Delegation for PostgreSQL Flexible Servers to integrate securely
     delegations = {
       postgres_flexible = {
         service_name = \"Microsoft.DBforPostgreSQL/flexibleServers\"
         actions      = [\"Microsoft.Network/virtualNetworks/subnets/join/action\"]
       }
     }

6. Parameterization:

   • Consider using variables for environment-specific values (name and address_prefix) to simplify maintenance. This practice could facilitate deployment in additional environments without duplicating configuration.

7. Potential Cost and Carbon Impacts:

   • Be mindful of creating /24 subnets (256 addresses) where a smaller subnet might suffice. Evaluate actual resource requirements before committing to larger subnets to optimize costs and minimize unused IPs, which contributes to inefficient routing.
     • Example: Use /27 (32 addresses) or /26 (64 addresses) if your workload permits.

8. Security Best Practices:

   • If these configurations are for PostgreSQL Flexible Servers, ensure network access control policies (NSGs or firewalls) allow only trusted IP ranges for database access to minimize the attack surface.
   • Document or enforce any specific access restrictions.

Summary

The changes are functional, but implementing DRY principles, improving readability, and performing additional validation will enhance maintainability and security. Optimizing IP ranges where possible will help reduce costs and carbon footprint. Estimated annual cost impact for unused IPs could be in the range of £50–£200 per environment (based on typical cloud provider pricing for unused subnets).