Landing Zone
Fundemantals

Rainer Stropek | time cockpit

General Comments

General Comments

  • DevOps is hard
    • Time consuming because processes take a while - and usually fail at the end 😅
    • Struggling with permissions - especially if you try follow least-privilege approach
    • Lack of/errors in documentation - particularly meaningful/correct examples
    • AI assistants are of limited value
  • Bash or PowerShell?
    • Both are fine
    • More people know bash
    • Advantages of PowerShell in some Azure services (e.g. Azure Automation, Azure Functions)

This Workshop

  • We are not building a landing zone
    • We are learning the fundamentals to build one
  • This is not a workshop about software or cloud architecture
    • Would be too project-specific
  • This is not a workshop about software development
    • Focus on IaC, not regular app code
  • We want to gather foundational knowledge about Azure

Management Groups

Management Groups

  • Way to efficiently manage access, policies, and compliance for subscriptions
    • E.g. apply policy to group of subscriptions
    • E.g. provide a user access to multiple subscriptions
  • Hierarchical structure
    • Restructuring is possible (except Root MG)
    • Warning: MG hierarchy is cached for up to 30 minutes
  • Limits apply 🔗
  • Root MG: Single top-level management group
    • Global policies and role assigments
    • ID of the Root MG is the same value as the Microsoft Entra tenant ID
    • Can't be moved or deleted
    • Default MG can be different 🔗
    • Note: Elevated permissions 🔗
  • Roles on MGs 🔗

Exercise: MG Hierarchy

  • Group exercise (recommendation: pairs)
  • Think about how the MG hierarchy for your org could look like
    • Consider Microsoft's samples; e.g. 🔗:








      ​
  • Document and present your ideas

Bicep

What is Bicep?

  • Domain-specific language to deploy Azure resources
    • Aka Infrastructure as Code (IaC)
  • Declarative, type-safe, modular language
  • Always up-to-date
    • Supports GA and preview versions of Azure resources
  • Good authoring experience in VSCode (and forks)
  • Works well with Azure CLI 🔗 and Azure PowerShell 🔗
  • Uses Azure Resource Manager behind the scenes
  • Preview changes with what-if operation 🔗
  • Getting started

Exercise

  • Create a Bicep file to generate a resource group (example 🔗)
  • Create a Bicep module that generates an Azure Storage Account
    • Example 🔗
    • From ARM Quickstart Templates 🔗
  • Compile to ARM template 🔗 with az bicep build
    • Take a moment to compare Bicep with JSON ARM Template
    • Note that multiple Bicep modules (including loaded JSON files) are compiled into a single ARM Template file
  • Deploy everything (az deployment 🔗, example 🔗)
  • Verify in portal

Private Module Registry

  • Used to share Bicep modules with other users
    • Similar to Docker Registry (including versioning)
    • Uses Azure Container Registry (ACR)
    • Supports Private Endpoints for network isolation
  • Publish
    • az bicep publish [...] --target br:myreg.azurecr.io/...
    • With or without source code and documentation link

Exercise

  • Recommended, but optional: Pair up in groups of 2
  • Together
    • Use/adjust Bicep file for RG creation from previous exercise
    • Create a Bicep file to generate an ACR (example 🔗)
    • Permissions (Example 🔗)
      • User 1: push and pull permissions
      • User 2: Only pull permissions
    • Deploy everything (az deployment 🔗, example 🔗)
    • Verify in portal
  • User 1
    • Use/adjust Bicep file for Azure Storage Account creation from prev. exercise
    • Publish the Bicep file to ACR (example 🔗)
  • User 2
    • Consume the Bicep file from ACR to create storage account (example 🔗)

Azure Verified Modules 🔗

  • Library of IaC modules verified and supported by MS
    • Bicep, Terraform (additional languages might be added in the future)
    • referenced with br/public:avm/...
    • Intellisense in VSCode
  • Resource Modules
    • Verified modules for creating various (hierarchies of) resources
  • Pattern Modules
    • ​Application tier
  • Specification published by MS 🔗
    • Can be basis for custom Bicep modules
    • ⚠️ Do not over-complicate things

Exercise

  • Use the AVM for Resource Groups 🔗 to create a new RG
    • Take some time to look at the implementation and sample on GitHub
  • Use the AVM for Storage Account 🔗 to create a new storage account
    • Blob storage
    • Take a look at the implementation
      Takeaway: Bicep modules can be quite large and compilicated
  • Deploy everything
  • Verify in portal

Template Specs

  • Resource type for storing ARM templates (including Bicep)
  • Used to share templates with other users
    • Can be used to deploy resources later (scripted, portal)
  • RBAC applies
  • Differences to Module Registries
    • TS can be deployed without writing a Bicep file
    • TS do not need to be Bicep, can also be ARM templates
    • No support for embedded artifacts like scripts
    • Details see 🔗
  • Optional exercise 🔗

Deployment Stacks

Deployment Stacks

  • Manage group of Azure resources as a single unit
    • Can span MGs, subscriptions, RGs
  • Simplifies cleanup significantly
    • Delete or detach
  • Protected
    • RBAC applies
    • deny-settings-mode
    • Control access by carefully choosing deployment scope
    • Possible to exclude actions and principals
  • Detailed documentation see 🔗

Exercise

  • Groups of 2 or 3 people
  • Discuss possible applications of deployment stacks
  • For two applications:
    • Describe how you would use deployments stacks
    • Which scope would you use?
    • Which action on unmanage would you use and why?
    • Would protection of resources be necessary? If yes, how?

Azure Policies

What is a "Policy"?

  • Rule that enforces organizational standards and/or assess compliance
    • With automated subscription vending, no human can verify compliance
    • Manual verification does not scale
  • Defined using JSON 🔗
  • Grouped into Policy Intiatives (aka Policy Sets) 🔗
  • Tip: Azure Policy extension for VSCode 🔗

Structure of a Policy

  • Name + Description
  • Type
    • Built-in (provided by MS)
    • Custom
    • Static (compliance results of non-MS audits)
  • Mode
    • For ARM: Typically all, for details see docs 🔗
    • Special handling of AKS, Key Vault, and VNets 🔗
  • Version and metadata
  • Definition location
    • Subscription
    • Management group

Structure of a Policy

  • Parameters
    • Parameters to make policies more flexible
  • Name
    • Will be used to reference param. value with parameters('myparam')
  • Type
    • string, array, object, boolean, integer, float, dateTime
  • Metadata
  • Default value
  • Allowed values
  • Schema (for object-type parameters)
  • For details see docs 🔗

Structure of a Policy

"parameters": {
  "allowedLocations": {
    "type": "array",
    "metadata": {
      "description": "The list of allowed locations for resources.",
      "displayName": "Allowed locations",
      "strongType": "location"
    },
    "defaultValue": [
      "westus2"
    ],
    "allowedValues": [
      "eastus2",
      "westus2",
      "westus"
    ]
  }
}

Example:

Policy Rules

  • if-then block
    • Policy is inforced if the if-condition is true
    • then-block contains effects 🔗
  • if-block
    • Conditions 🔗
    • Logical operators not, allOf, anyOf 🔗
    • Fields 🔗
  • Many ARM template functions can be used 🔗

Learn by Example

  • Azure Policy built-ins 🔗🔗
     

  • Audit or deny
    • Storage accounts should have the specified minimum TLS version 🔗🔗
    • [Preview]: Azure PostgreSQL flexible server should have Microsoft Entra Only Authentication enabled 🔗🔗
    • Allowed Locations 🔗🔗
  • Modify
    • Inherit a tag from the resource group 🔗🔗
  • Deploy/audit if not exists
    • Configure Azure AI Services resources to disable local key access (disable local authentication) 🔗🔗

Exercise

  • Choose two Azure Policies you would like to apply
  • Create a Policy Set​ from the two policies
    • Bicep or portal
  •  Assign the Policy Set to a MG or Subscription
    • Bicep or portal
  • Try to deploy a resource that is not compliant
    • See if your policy worked

Exercise

  • Choose an Azure Policy with effect Audit
  • Assign the policy (any scope)
    • Bicep or portal (Bicep preferred)
  • Create a corresponding resource that violates the policy
    • Bicep
  • Verify non-compliance in portal
  • Create a policy exemption
    • Bicep or portal
    • Wait a while (some hours) and check compliance again

CI/CD

GitOps

  • IaC is in Git
    • Benefit from branches, code reviews, automated workflows, etc.
  • GitHub is the "Hero" git server for Azure
    • Best support for federated authentication
    • Docs 🔗