Cloud Adoption Framework: Een duik in Terraform implementatie

In mijn vorige blog heb ik uitgelegd wat het Cloud Adoption Framework is en waarom elke organisatie dit framework zou moeten gebruiken. Daarbij heb ik een conceptuele Azure landingzone architectuur laten zien en verteld hoe de implementatie hiervan in zijn werk gaat. In deze blog laat ik zien hoe je dit met Terraform code kan gaan uitrollen. 

CAF-enterprise-scale-module

Om het framework uit te rollen maken we gebruik van een terraform module. Dit is de terraform-azurerm-caf-enterprise-scale module die onder andere wordt onderhouden door mensen van Microsoft. Zie de GitHub pagina Azure/terraform-azurerm-caf-enterprise-scale: Azure landing zones Terraform module (github.com) voor meer informatie. 

In de basis zorgt de module voor de hiërarchie van de managementgroepen en wordt er een basis set aan Policies en Acces Control gezet op deze managementgroepen. De basis configuratie hiervoor is: 

/main.tf

module "enterprise_scale" {
source  = "Azure/caf-enterprise-scale/azurerm" 
version = "4.2.0" 
default_location = var.location 
providers = { 
azurerm              = azurerm 
azurerm.connectivity = azurerm 
azurerm.management   = azurerm 
} 
root_parent_id = data.azurerm_client_config.core.tenant_id 
root_id        = "myorg" 
root_name      = "My Organization" 

} 

Hiermee hebben we de managementgroepen en de hiërarchie daarvan uitgerold. Daarbij zijn de aanbevolen Policies en Acces Controls gezet op deze groepen. 

Tip: Deze basis configuratie lijkt klein, maar als je dit gaat uitrollen dan zullen er meer dan 200 resources uitgerold worden in Azure. Dit zijn veelal policies en hun permissies die gezet worden op de verschillende managementgroepen. Deze resources kosten geen geld. 

We hebben nu een goede basis staan, maar de managementgroep Landing Zones is leeg en we willen een eigen naamgeving gebruiken. Om de naamgeving aan te passen moeten we de values van root_id en root_name veranderen.  

In de managementgroep Landing Zones willen we twee managementgroepen maken met de naam Workload1 en Workload2. Daarin zetten we ook de ID’s van de abonnementen die we daarin wil hebben, de “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx” moet vervangen worden met eigen specifieke abonnementen ID’s. 

Dit ziet er als volgt uit:

/main.tf

module "enterprise_scale" { 

  source  = "Azure/caf-enterprise-scale/azurerm" 

  version = "4.2.0" 

  default_location = var.location 

  providers = { 

    azurerm              = azurerm 

    azurerm.connectivity = azurerm 

    azurerm.management   = azurerm 

  } 

  root_parent_id = data.azurerm_client_config.core.tenant_id 

  root_id        = "es" 

  root_name      = "Enterprise-Scale" 

  library_path   = "${path.root}/lib" 

  custom_landing_zones = { 

    "${var.root_id}-Workload1" = { 

      display_name               = "Workload1" 

      parent_management_group_id = "${var.root_id}-landing-zones" 

      subscription_ids           = ["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"] 

      archetype_config = { 

        archetype_id   = "online" # this archetype_id refers to the archetype_definition_online.json file in the lib folder 

        parameters     = {} 

        access_control = {} 

      } 

    } 

    "${var.root_id}-Workload2" = { 

      display_name               = "Workload2" 

      parent_management_group_id = "${var.root_id}-landing-zones" 

      subscription_ids           = ["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"] 

      archetype_config = { 

        archetype_id   = "online" # this archetype_id refers to the archetype_definition_online.json file in the lib folder 

        parameters     = {} 

        access_control = {} 

      } 

    } 

  } 

} 

Omdat we zelfgemaakte managementgroepen willen uitrollen onder de Landing Zone managementgroep, moeten we een library folder aanmaken. De library_path variabele verwijst naar deze folder. Onze folder heet in dit geval “lib”. 

In de lib folder maken we een archetype_definition_online.json aan. Dit wordt onze archetype definition en krijgt de archetype_id met de naam “online”.  

Deze definitie zier er als volgt uit: 

/lib/archetype_definition_online.json 

{ 

    "online": {  
       "policy_assignments": [ 
            "Deny-Resource-Locations", 
            "Deny-RSG-Locations" 

        ], 

        "policy_definitions": [], 

        "policy_set_definitions": [], 

        "role_definitions": [], 

        "archetype_config": { 

            "parameters": { 

                "Deny-Resource-Locations": { 

                    "listOfAllowedLocations": [ 

                        "westeurope", 

                        "northeurope" 

                    ] 

                }, 

                "Deny-RSG-Locations": { 

                    "listOfAllowedLocations": [ 

                        "westeurope", 

                        "northeurope" 

                    ] 

                } 

            }, 

            "access_control": {} 

        } 

    } 

} 

In de archetype definition (het json bestand hierboven) geven we het de naam “online” en zetten we tweetal policies neer. We kunnen hierbij gebruik maken van de built-in policies die in de caf-module zitten. In dit voorbeeld maken we gebruik van de built-in policies “Deny-Resource-Locations” en “Deny-RSG-Locations. Hierbij definiëren we per policies de parameters zodat er alleen resources uitgerold mogen worden in west en noord Europa.  

Tip: Zie terraform-azurerm-caf-enterprise-scale/modules/archetypes/lib/policy_assignments at main · Azure/terraform-azurerm-caf-enterprise-scale (github.com) voor alle built-in policies die met deze module uitgerold worden.  

Na het succesvol uitrollen van de code ziet de management groepen structuur er in Azure als volgt uit: 

Als we nu een resource groep in de management groep “Workload1” willen uitrollen, dan moet deze voldoen aan de policies. Als we bijvoorbeeld een resource groep in “East US” willen uitrollen, dan krijgen we een melding dat dit niet mag van de policy: 

Iedereen die in deze Azure omgeving werkt, moet dus voldoen aan deze policy heeft niet de mogelijkheid om in een andere regio cloud resources uit te rollen. Op deze manier kunnen we door middel van policies ervoor zorgen dat we in controle blijven van onze Azure omgeving.  

Zo zijn er nog tientallen policies die gebruikt kunnen worden om beleid toe te passen op de Azure omgeving. Zie List of built-in policy definitions - Azure Policy | Microsoft Learn voor de built-in policies die je kan gebruiken. Het is daarbij ook mogelijk om eigen policies te maken.  

Conclusie

Met deze basisconfiguratie van de CAF-module kunnen we onze Azure omgeving beheren en beveiligen met behulp van policies en management groepen. We hebben de hiërarchie van de managementgroepen neergezet en kunnen verschillende policies definiëren per managementgroep. Als alle managementgroepen aan dezelfde policie(s) moeten voldoen dan kan deze toegewezen worden aan de hoogste managementgroep, de managementgroepen eronder erven deze policy.  

De module is heel schaalbaar en aanpasbaar, waardoor het voor elke organisatie toepasbaar is. Zowel voor kleine als grote enterprise organisaties. Voor meer informatie of vragen kun je contact opnemen: daan.toes@cloudnation.nl