Make it easier to exclude/change the core Landing Zone hierarchy

[larsakerlund]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Is your feature request related to a problem?

The core Landing Zone hierarchy is too complex for a smaller enterprise setup like the Trey Reserach reference deployment.

In order to opt out from some of the management groups today, deploy_core_landing_zones must be set to false and the core Landing Zones must be defined in custom_landing_zones.

Since the hierarchy is already defined in the module, this leads to code duplication. See the additional context for an example deployment.

Describe the solution you'd like

It would be nice to be able to exclude parts of the hierarchy, instead of having to re-define it from scratch.

Another viable solution to this would be to make it possible to choose between the standard and lite ES hierarchy.

Additional context

Example of how the lite ES hierarchy can be deployed:

module "enterprise_scale" {
  source  = "Azure/caf-enterprise-scale/azurerm"
  version = "0.3.2"
root_parent_id = data.azurerm_client_config.current.tenant_id
root_id        = var.root_id
root_name      = var.root_name
library_path   = var.library_path
// We have to define the core Landing Zones ourselves to prevent some
// of the management groups from being created.
deploy_core_landing_zones = false
custom_landing_zones = {
(var.root_id) = {
display_name               = var.root_name
parent_management_group_id = data.azurerm_client_config.current.tenant_id
subscription_ids           = []
archetype_config = {
archetype_id   = "es_root"
parameters     = {}
access_control = {}
}
}
"${var.root_id}-platform" = {
  display_name               = "Platform"
  parent_management_group_id = var.root_id
  subscription_ids           = []
  archetype_config = {
    archetype_id   = "es_platform"
    parameters     = {}
    access_control = {}
  }
}

"${var.root_id}-landing-zones" = {
  display_name               = "Landing Zones"
  parent_management_group_id = var.root_id
  subscription_ids           = []
  archetype_config = {
    archetype_id   = "es_landing_zones"
    parameters     = {}
    access_control = {}
  }
}

"${var.root_id}-decommissioned" = {
  display_name               = "Decommissioned"
  parent_management_group_id = var.root_id
  subscription_ids           = []
  archetype_config = {
    archetype_id   = "es_decommissioned"
    parameters     = {}
    access_control = {}
  }
}

"${var.root_id}-sandboxes" = {
  display_name               = "Sandboxes"
  parent_management_group_id = var.root_id
  subscription_ids           = []
  archetype_config = {
    archetype_id   = "es_sandboxes"
    parameters     = {}
    access_control = {}
  }
}

}
}

[krowlandson]

Hi @larsakerlund... just to let you know we've acknowledged this and are considering the best way to approach this. We actually have a number of other considerations relating to this which may be the best time to apply this change. Specifically, I'm looking at options to simplify the overall approach to configuring all of the overrides for the core landing zones, which would also provide the ability to override the display name values if desired.

[krowlandson]

Just a quick update. We won't be including this in the next release but I will be looking at this for the following major release which we would hope to deliver in the next quarter. For now, please continue to use the custom_landing_zones to override the configuration of any built-in landing zones as required.

[krowlandson]

Initial thoughts for feature development:

• Implement new (optional) input variables for each of the built-in landing zones, with each containing default values for the "out of the box" settings, but providing the option for a custom to set their own values as needed

Need to consider whether it's better to use a single complex input object per landing zone, or to decompose across multiple simple input objects.

Single complex input example

variable "configure_lz_root" {
  type = object({
      display_name               = string
      parent_management_group_id = string
      subscription_ids           = list(string)
      archetype_config = object({
        archetype_id   = string
        parameters     = object({})
        access_control = object({})
      })
  })
  description = "Customize the `root` landing zones configuration settings."
  default = {
      display_name               = "Enterprise-Scale" # For `root` only, how does this interplay with the `root_name` input variable?
      parent_management_group_id = "" # For `root` only, how does this interplay with the `root_parent_id` input variable?
      subscription_ids           = [] # This would remove the need for `subscription_id_overrides` input variable.
      archetype_config = { # This would remove the need for `archetype_config_overrides` input variable.
        archetype_id   = "es_root"
        parameters     = {}
        access_control = {}
      }
  }
}

Multiple simple inputs example

variable "lz_root_display_name" {
  type = string
  default = "Enterprise-Scale" # For `root` only, how does this interplay with the `root_name` input variable?
}

variable "lz_root_parent_management_group_id" {
  type = string
  default = "" # For `root` only, how does this interplay with the `root_parent_id` input variable?
}

variable "lz_root_subscription_ids" {
  type = list(string)
  default = [] # This would remove the need for `subscription_id_overrides` input variable.
}

variable "lz_root_archetype_id" {
  type = string
  default = "es_root" # This would partially remove the need for `archetype_config_overrides` input variable.
}

variable "lz_root_archetype_parameters" {
  type = any
  default = {} # This would partially remove the need for `archetype_config_overrides` input variable.
}

variable "lz_root_archetype_access_control" {
  type = any
  default = {} # This would partially remove the need for `archetype_config_overrides` input variable.
}

Also need to consider whether to have a flag to enable/disable deployment of a specific landing zone (and all children) or to allow a null or empty map input be used to achieve the same outcome.

Inner workings of module could be written to allow co-existence of "old" and "new" approaches for setting these values, but intent would ultimately be to remove the "old" approach on a future major release.

[matt-FFFFFF]

Initial thoughts for feature development:

• Implement new (optional) input variables for each of the built-in landing zones, with each containing default values for the "out of the box" settings, but providing the option for a custom to set their own values as needed

I think, with the upcoming TF 1.3 release, I'm leaning towards the complex input with optional().

Thoughts @krowlandson?

[jtracey93]

Trigger ADO Sync

[matt-FFFFFF]

AB#26868

[vitoravancini]

Hello! was this issue solved? Is there a better way now of deploying the 'TreyResearch' lite landing zone better than the suggestion by @larsakerlund in this issue?

[matt-FFFFFF]

Hi!

This is in our backlog but we don't have a timescale yet

[vitoravancini]

Alright @matt-FFFFFF, the suggestion here seems to have some encoding error so I'm not exactly sure how to use it. The platform landing zones have predefined archetypes at this repo? can you point me to how I could use the custom landing zones to achieve that?

Thank you!

[vitoravancini]

found it here https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/tree/main/modules/archetypes/lib/archetype_definitions, I'll try to use this, thank you!