Terraform - Sovereign Landing Zone

The sovereign_landing_zone starter module provides full customization of the Sovereign Landing Zone (SLZ) using the inputs.yaml file. The inputs.yaml file provides the ability to enable and disable modules, configure module inputs and outputs, and configure module resources. A custom inputs.yaml file can be passed to the inputs argument of the ALZ PowerShell Module(version 4.1.5 should be used). This allows you to firstly design your Azure Landing Zone, and then deploy it.

The default inputs.yaml file will need to be modified based on the documentation below.

Example input files can be found here:

• inputs-azure-devops.yaml
• inputs-github.yaml
• inputs-local.yaml

The following table describes the inputs for the sovereign_landing_zone starter module.

An example of the format for the policy_exemptions map is as follows:

policy_exemptions: {
  policy_exemption1: {
    name: "globalexemption",
    display_name: "global",
    description: "test",
    management_group_id: "/providers/Microsoft.management/managementGroups/<MG-ID-SCOPE>",
    policy_assignment_id: "/providers/microsoft.management/managementGroups/<MG-ID-SCOPE>/providers/microsoft.Authorization/policyassignments/enforce-sovereign-global",
    policy_definition_reference_ids: ["AllowedLocations"]
  }
}

NOTE - management_group_configuration archetypes array can be used for including non-ALZ archetypes. ALZ archetypes can be toggled using input variable apply_alz_archetypes_via_architecture_definition_template.

All archetypes(ALZ/SLZ) can be found here.

The default format for the management_group_configuration map is as follows:

management_group_configuration: {
  root: {
    id: "${default_prefix}${optional_postfix}",
    display_name: "Sovereign Landing Zone",
    archetypes: ["global"]
  },
  platform: {
    id: "${default_prefix}-platform${optional_postfix}",
    display_name: "Platform",
    archetypes: []
  },
  landingzones: {
    id: "${default_prefix}-landingzones${optional_postfix}",
    display_name: "Landing Zones",
    archetypes: []
  },
  decommissioned: {
    id: "${default_prefix}-decommissioned${optional_postfix}",
    display_name: "Decommissioned",
    archetypes: []
  },
  sandbox: {
    id: "${default_prefix}-sandbox${optional_postfix}",
    display_name: "Sandbox",
    archetypes: []
  },
  management: {
    id: "${default_prefix}-platform-management${optional_postfix}",
    display_name: "Management",
    archetypes: []
  },
  connectivity: {
    id: "${default_prefix}-platform-connectivity${optional_postfix}",
    display_name: "Connectivity",
    archetypes: []
  },
  identity: {
    id: "${default_prefix}-platform-identity${optional_postfix}",
    display_name: "Identity",
    archetypes: []
  },
  corp: {
    id: "${default_prefix}-landingzones-corp${optional_postfix}",
    display_name: "Corp",
    archetypes: []
  },
  online: {
    id: "${default_prefix}-landingzones-online${optional_postfix}",
    display_name: "Online",
    archetypes: []
  },
  confidential_corp: {
    id: "${default_prefix}-landingzones-confidential-corp${optional_postfix}",
    display_name: "Confidential Corp",
    archetypes: ["confidential"]
  },
  confidential_online: {
    id: "${default_prefix}-landingzones-confidential-online${optional_postfix}",
    display_name: "Confidential Online",
    archetypes: ["confidential"]
  }
}

An example of the format for the landing_zone_management_group_children map is as follows:

landing_zone_management_group_children: {
  child1: {
      id: "${default_prefix}-landingzones-child1${optional_postfix}",
      display_name: "Landing zone child one",
      archetypes: []
  }
}

An example of the format for the platform_management_group_children map is as follows:

platform_management_group_children: {
    security: {
      id: "${default_prefix}-platform-security${optional_postfix}",
      display_name: "Security",
      archetypes: ["confidential"]
  }
}

An example of the format for the tags map is as follows:

tags: {
  Environment: "Production",
  ServiceName: "SLZ"
}

An example of the format for the express_route_gateway_config map is as follows:

express_route_gateway_config: {
  name: "express_route",
  gatewayType: "ExpressRoute",
  sku: "ErGw1AZ",
  vpnType: "RouteBased",
  vpnGatewayGeneration: null,
  enableBgp: false,
  activeActive: false,
  enableBgpRouteTranslationForNat: false,
  enableDnsForwarding: false,
  asn: 65515,
  bgpPeeringAddress: "",
  peerWeight: 5
}

An example of the format for the vpn_gateway_config map is as follows:

vpn_gateway_config: {
  name: "vpn_gateway",
  gatewayType: "Vpn",
  sku: "VpnGw1",
  vpnType: "RouteBased",
  vpnGatewayGeneration: "Generation1",
  enableBgp: false,
  activeActive: false,
  enableBgpRouteTranslationForNat: false,
  enableDnsForwarding: false,
  bgpPeeringAddress: "",
  asn: 65515,
  peerWeight: 5,
  vpnClientConfiguration: {
    vpnAddressSpace: ["10.2.0.0/24"]
  }
}

The following are known issues with the Public Preview release for the SLZ.

The inputs for bootstrap_location and starter_locations must be identical, using the first region in starter_locations as the default location. Therefore, starter_locations is required and must include at least one region. In a future release, we will have defaults and overrides for these values.

Any updates should be made to the inputs.yaml file and the tfvars will be updated upon executing the Deploy-Accelerator PowerShell command.

There is no validation done to ensure subnets fall within the hub network CIDR or that subnets do not overlap. These issues will be uncovered during apply.

Workaround:

1. Set deploy_bastion= false in inputs file
2. Run deployAccelerator command
3. Run .\scripts\deploy-local.ps1
4. Set deploy_bastion= true in inputs file, update AzureBastionSubnet address_prefix
5. Run deployAccelerator command
6. Run .\scripts\deploy-local.ps1

Work around:

1. Set deploy_bastion= false and enable_firewall = false in inputs file
2. Run deployAccelerator command
3. Run .\scripts\deploy-local.ps1
4. Set deploy_bastion= true and enable_firewall = true in inputs file, update AzureFirewallSubnet address_prefix
5. Run deployAccelerator command

Certain resources are not receiving the default tags. This will be addressed in a future release.

Certain resources will show as being out of compliance by default. This will be addressed in a future release.

1. Policy Definition migrateToMdeTvm will be excluded from remediation as customers must enable MDFC on their subscriptions for this policy and then run remediation via Azure portal.

2. Log analytics polices deploy-diag-logscat and deploy-azactivity-log will be skipped for remediation until customer has set the log_analytics_workspace_resource_id(output after successful deployment of LZ) input and re-run deploy-accelerator/deploy-local.ps1.

3. Updating assignment policies or management group configuration will trigger recreation of azapi policy remediation resources - Because customers have the option to include custom policies with built-in policy set definitions, and remediations require the policyReferenceId for policy definitions in policy sets, the policyReferenceId must be queried dynamically and due to Terraform’s limitations on creating resources in a for_each, remediations will get recreated as the result of a workaround for allowing this dynamic query. Remediation tasks will only be created if a policy is not in compliance.

There is an experimental feature that would allow the dynamic creation of resources in a for_each, but work on this is on-going.

To deploy with lowered permissions using a service principal with “Owner” role assignment at the tenant root management group, set the following environment variable in powershell:

$env:AZAPI_RETRY_GET_AFTER_PUT_MAX_TIME="30m"

The following permissions are needed for security group creation

Security group creation can be disabled by setting input management_security_groups = []. Also, security groups in management_security_groups are case-sensitive.

Custom policies can be added to the lib directory in the root of the starter module. Here is an example in the AVM terraform-azurerm-avm-ptn-alz repo.

NOTE - Customers can also include custom policy set definition and policy definition ARM templates into the lib directory. File names must contain the same format as in the given examples.

Customers can also update policy parameter values for ALZ or SLZ policies by including an updated copy of the policy file in the lib directory. The new file will overwrite the existing policy file in the module. The new file must contain the same format as the original policy file.

In the starter module locals.tf, customers can update the slz_policy_default_values for any of the parameters set in this example.

slz_policy_default_values = {
  slz_policy_effect                            = jsonencode({ value = var.policy_effect })
  list_of_allowed_locations                    = jsonencode({ value = var.allowed_locations })
  allowed_locations_for_confidential_computing = jsonencode({ value = var.allowed_locations_for_confidential_computing })
  ddos_protection_plan_id                      = jsonencode({ value = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/placeholder/providers/Microsoft.Network/ddosProtectionPlans/placeholder" })
  ddos_protection_plan_effect                  = jsonencode({ value = var.deploy_ddos_protection ? "Audit" : "Disabled" })
  email_security_contact                       = jsonencode({ value = var.ms_defender_for_cloud_email_security_contact })
  ama_user_assigned_managed_identity_id        = jsonencode({ value = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/placeholder/providers/Microsoft.ManagedIdentity/userAssignedIdentities/${local.uami_name}" })
  ama_user_assigned_managed_identity_name      = jsonencode({ value = local.uami_name })
  log_analytics_workspace_id                   = jsonencode({ value = var.log_analytics_workspace_resource_id })
}

The Terraform-based deployment for the Sovereign Landing Zone (SLZ) provides an Enterprise Scale Landing Zone with equivalent compliance posture equal to that of our Bicep implementation. There is not currently a migration path between the two implementations, however multiple landing zones can be created with either deployment technology in the same Azure tenant.

The alz-archetypes and slz-archetypes are different from Terraform modules, but are used to deploy the management group hierarchy, policy assignments and management resources including the sovereign baseline policies. For more information on the archetypes, view the ALZ archetypes and the SLZ archetypes.

The subscription-vending module is used to deploy the subscriptions and move them within the right management group scopes. For more information on the module itself see here.

The hubnetworking module is used to deploy the hub VNET, Azure Firewall , Route Tables, and other networking primitives into the connectivity subscription. For more information on the module itself see here.

The private-link module is used to deploy default private link private DNS Zones. For more information on the module itself see here.

The alz-management module is used to deploy a set of management resources such as those for centralized logging. For more information on the module itself see here.

The resource-group module is used to deploy a variety of resource groups within the default subscriptions. For more information on the module itself see here.

The portal-dashboard module is used to deploy the default compliance dashboard. For more information on the module itself see here.

The azure-bastion module is used to deploy Azure Bastion for remote access. For more information on the module itself see here.

The firewall-policy module is used to deploy a default Azure Firewall Policy for further configuration. For more information on the module itself see here.

The ddos-protection module is used to deploy a Standard SKU DDoS Protection Plan resource for network security. For more information on the module itself see here.

The public-ip module is used to deploy a Azure Public IP resoures for offerings that need inbound public internet access such as the VPN and ExpressRoute Gateways. For more information on the module itself see here.

The networksecuritygroup module is used to deploy a default NSG for the Azure Bastion subnet to restrict ingress and egress network access. For more information on the module itself see here.