cloudchristoph

Apply Tenant Restrictions with Azure Firewall

Tue, 04 Aug 2026 00:00:00 GMT

Picture a perfectly normal day in an AVD environment. An external consultant (cough) — someone from the systems integrator that supports your ERP, say — signs in to one of your session hosts to do exactly the work you hired them for. Their employer runs Microsoft 365 … like everybody else.

So at some point they open the browser on the session host, go to OneDrive and sign in to their own company’s OneDrive. Valid account, MFA passes, everything green. Now a foreign tenant’s OneDrive is open inside your corporate environment, one drag-and-drop away from your file shares.

Nobody attacked anything in that story, and that is exactly what makes it uncomfortable: it happens every day wherever external people work on internal machines. And often none of your controls reacted. Your Conditional Access policies never fired. Why? The consultant authenticated against their employer’s tenant, not yours, so there was nothing for your policies to evaluate. Your firewall saw an allowed HTTPS session to a Microsoft sign-in endpoint, which is exactly what it was.

The same door is open for the less innocent variants: a private Microsoft account, or a throwaway free-trial tenant created purely as an exfiltration target. Same endpoints, same non-reaction.

Microsoft Entra Tenant restrictions v2 (TRv2) closes this. Entra itself refuses the sign-in when the target tenant isn’t on your allow list. However, TRv2 is kind of “inactive” on its own: Client restrictions are enforced only when outbound login traffic is marked with your policy from some system. Historically that “something” was Global Secure Access, a Windows GPO, or a TLS-terminating proxy you had to own and operate.

Azure Firewall can now be that something: HTTP header insertion went generally available at the end of July 2026. Application rules can add or overwrite request headers — on every SKU for plain HTTP, but only Premium can do it inside TLS-inspected HTTPS. Two constraints follow directly and shape everything below: the sign-in endpoints are of course HTTPS, so you need Azure Firewall Premium with TLS inspection, and header insertion exists only on application rules (because you know, that network rules never touch HTTP). This post is how I actually made it work, and everything that went wrong on the way.

Prerequisites

Firewall: Azure Firewall Premium SKU,
Licensing: Microsoft Entra ID P1 or P2,
Entra Roles: At least the Security Administrator role to configure it.
Azure RBAC: Contributor on the Firewall Policy.

Why the network path, when you don’t manage the devices

TRv2 has three enforcement paths, and they are different products with different coverage:

Path	Covers	Requires
Universal tenant restrictions (Global Secure Access)	Any device with the GSA client, on or off network	Managed device, GSA client installed
Windows GPO (preview)	Windows + Edge / Windows networking stack; auth and data plane	Domain- or Intune-managed Windows devices
Proxy/firewall header injection	Everything routed through that egress, any OS	Central egress with TLS inspection

If you manage the endpoints, use Global Secure Access. It’s per-device, works off-network, and involves no CA distribution. I’d reach for it first, and the Windows GPO path is the only one of the three that also protects the data plane.

Neither of the other two paths can enforce anything on a machine you don’t manage. The firewall path doesn’t care. It enforces on the network, so every VM, container, appliance and BYO laptop behind that egress is covered whether it’s Windows, macOS or Linux, with nothing installed on it.

The flip side is equally blunt: devices not behind that egress are untouched — this is a control on a network path, not on an identity. Fine for AVD session hosts and cloud workloads, which never leave; useless for a roaming fleet.

Step 1: Make sure the policy exist in Entra ID

Option A: The Entra Admin Portal

In the Entra admin center: Entra ID > External Identities > Cross-tenant access settings > Default settings > Tenant restrictions > Edit tenant restrictions defaults. If no default policy exists yet, you can create the policy there. The pane then shows your Tenant ID and a generated Policy ID — you need both.

Two tabs control what the policy does. External users and groups sets Access status to Allow or Block for accounts from other tenants. External applications does the same for apps, either all of them or a selected list of app IDs. The default policy always applies to all users in your tenant — you cannot scope it at the default level. And note the portal’s own warning: blocking all users also blocks all external applications, so the two tabs are not independent.

Partners you want to keep working go under Organizational settings > Add organization, by domain or tenant ID, each with its own allow rules. This is where the consultant from the intro belongs: allow-list their employer’s tenant here as a deliberate decision, instead of leaving every tenant in the world reachable by default. By the way … Consumer Microsoft accounts live in the well-known tenant 9188040d-6c67-4c5b-b112-36a304b66dad if you want to add those too.

Option B: Microsoft Graph

You can also query the Microsoft Graph for this. Ensure you have “Policy.ReadWrite.CrossTenantAccess” or “Policy.Read.All” permissions and send a GET request to:

text

https://graph.microsoft.com/beta/policies/crossTenantAccessPolicy/default

The id field in the response is the policy GUID. That’s the value people spend twenty minutes hunting for in the portal.

Step 2: Inject the header in Azure Firewall

The header

This is the expected header:

text

sec-Restrict-Tenant-Access-Policy: <your-tenant-id>:<your-policy-id>

It goes onto these four Microsoft sign-in domains:

Microsoft explicitly sanctions TLS decryption of those four domains for this purpose. That’s a narrow exception to the general “don’t break-and-inspect Microsoft 365” guidance. Do not inspect Microsoft 365 traffic broadly.

The rule

You can configure it using the portal. Just edit your Firewall Policy and add a new application rule.

In the App Rule configure your source and then:

Destination Type: FQDN
Target FQDNs: login.live.com,login.microsoft.com,login.microsoftonline.com,login.windows.net
Enable TLS Inspection
Protocol: Https:443
In the HTTP Header Insertion add sec-Restrict-Tenant-Access-Policy with the value <your-tenant-id>:<your-policy-id>

Or configure it using IaC (my preferred and recommended way!). Here is a Terraform snippet for your Application Rule Collection Group. Adapt to your needs:

terraform

# inside azurerm_firewall_policy_rule_collection_group
application_rule {
  name             = "allow-entra-signin"
  source_addresses = ["10.2.3.0/24"]
  destination_fqdns = [
    "login.live.com",
    "login.microsoft.com",
    "login.microsoftonline.com",
    "login.windows.net",
  ]
  terminate_tls = true

  protocols {
    type = "Https"
    port = 443
  }

  http_headers {
    name  = "sec-Restrict-Tenant-Access-Policy"
    value = "${var.tenant_id}:${var.trv2_policy_id}"
  }
}

Do not copy Microsoft’s own header-insertion how-to here. That article uses tenant restrictions as its worked example, and the example still shows the v1 headers: Restrict-Access-To-Tenants and Restrict-Access-Context. Follow it and you’ll build a legacy TRv1 setup with a tenant allow-list crammed into a header value. TRv2 replaces all three v1 headers — including sec-Restrict-Tenant-Access-Policy: restrict-msa for login.live.com — with the single policy reference above. If you’re migrating, please remove the old ones. Because leaving both in place causes conflicts.

Step 3: Prove it actually works

Three checks, in order, because each one rules out a different failure.

Is TLS interception happening? From a VM behind the firewall you can use a command prompt (Linux or WSL):

bash

openssl s_client -connect postman-echo.com:443

It should show you something like this:

text

 0 s:CN = Azure Firewall Manager CA, CN = postman-echo.com
 1 s:CN = Azure Firewall Manager CA
 2 s:O = Contoso Lab, CN = Contoso Firewall Intermediate CA

Is the firewall actually inspecting? Check the log:

kql

AZFWApplicationRule
| where TimeGenerated > ago(15m)
| where Fqdn has "login."
| project TimeGenerated, SourceIp, Fqdn, Action, Rule, IsTlsInspected, TargetUrl

IsTlsInspected is the column that matters. It is entirely possible to have Action = Allow, the correct rule matched, provisioningState = Succeeded on every resource — and IsTlsInspected = False. In that state the rule works, the traffic flows, the user is happy, and no header is being inserted at all. The control is off and nothing tells you.

The end-to-end test. From behind the firewall, sign in against a tenant that isn’t allow-listed — in the intro scenario, that would be the consultant opening their employer’s OneDrive on your session host. The error that is shown is:

text

Access is blocked

The Contoso IT department has restricted which organizations can be accessed.
...

And in the Troubleshooting Details (or in PowerShell or Az CLI) you’ll find the message:

text

AADSTS5000211: A tenant restrictions policy added to this request by a device or
network administrator does not allow access to 'tenant name'.

What could go wrong

(Everything that can go wrong with the TLS inspection setup itself — Key Vault permissions, certificate rotation, client trust — I think this deserves a separate post 😉. Here I’ll stick to what’s specific to this.)

QUIC bypasses inspection entirely. Azure Firewall does no FQDN, URL or TLS inspection for QUIC on UDP 80/443. If you never allowed UDP 443 outbound, browsers fall back to TCP and this is a non-issue. If you did allow it in a network rule, you’ve built a bypass around your own control.

Scope. This is authentication-plane protection only. It does not stop anonymous access to Teams meetings, SharePoint links or Forms — that needs Global Secure Access or the Windows GPO path. It is not DLP: a user already signed in to your tenant can still move data wherever they’re permitted to.

Logs never show the header. AZFWApplicationRule has no column for inserted header names or values. You get IsTlsInspected, the matched rule, and TargetUrl. If you want proof that enforcement happened, it’s in the Entra sign-in logs.

Conclusion

This is the right tool when you have a central egress that all the relevant VMs/systems already traverse, and you cannot install anything on those. AVD estates, jump hosts, build agents, appliances. In that shape it’s the only one of the three TRv2 paths that can enforce anything at all. The consultant from the intro either gets blocked at sign-in, or their employer’s tenant is on your allow list because you put it there. And this is a informed decision you made and not a gap you simply didn’t know about.

It’s the wrong tool if your fleet is managed. Global Secure Access gives you the same authentication-plane outcome per device, and also works when people are at home or on the road.

Hope it helps!

Hub-Deployment mit Azure Verified Modules

Thu, 26 Mar 2026 00:00:00 GMT

Azure Verified Modules (AVM) haben in der letzten Zeit an Bedeutung gewonnen und sind seit einiger Zeit mein präferierter Ansatz für Infrastructure-as-Code Implementierungen. In diesem Beitrag zeige ich euch, wie ihr mit AVM ein Hub-and-Spoke Netzwerk in Azure aufbauen könnt. Dabei verwende ich ein AVM Pattern-Modul, um eine oft genutzte Konfiguration zu demonstrieren.

Auf GitHub verfügbar

Den vollständigen Code für dieses Beispiel findet ihr in meinem GitHub Repository: https://github.com/cloudchristoph/lab-connectivity-hub-with-avm

Was ist AVM? Was ist ein Pattern-Modul?

Azure Verified Modules (AVM) sind von Microsoft unterstützte und empfohlene Terraform- oder Bicep-Module, die Best Practices für die Bereitstellung von Azure-Ressourcen implementieren. Sie bieten vor allem eine standardisierte und getestete Implementierung für häufig verwendete Funktionalitäten, wie Diagnostics Settings, Tags, Private Link, etc.

Ein Pattern-Modul ist eine spezielle Art von AVM, die ein komplettes Architektur- oder Designmuster implementiert. Es enthält nicht nur die Ressourcen, sondern auch die Logik und Konfiguration, um ein bestimmtes Szenario oder Muster in Azure umzusetzen. In diesem Fall implementiert das Pattern-Modul avm-ptn-alz-connectivity-hub-and-spoke-vnet das Hub-and-Spoke Netzwerkdesign, das häufig in Azure-Umgebungen verwendet wird.

Warum AVM für Hub-and-Spoke?

Bisher hatten wir verschiedenste Möglichkeiten, ein Hub-and-Spoke Netzwerk in Azure zu implementieren, sei es durch eigene Terraform- oder Bicep-Module oder auch das altbekannte terraform-azurerm-caf-enterprise-scale Modul. Dieses Modul war sehr mächtig und hat versucht quasi alles abzudecken - von Netzwerk, über Management Strukturen bis hin zu Policies. Dieser All-in-one-Ansatz hatte jedoch den Nachteil, dass er oft zu komplex und schwergewichtig war. Man war quasi gezwungen, das Modul mehrfach mit verschiedenen Parametern zu verwenden um nicht einen monolithischen Aufruf in seinen IaC Code zu haben.

Der neue Ansatz mit AVM ermöglicht uns es jetzt die einzelnen Komponenten des Hub-and-Spoke Designs modular und flexibel zu implementieren. Die Pattern-Module wiederrum bündeln jetzt einzelne Themenbereiche und verwenden dabei die AVM Module als Bausteine. In unserem Beispiel beschäftigen wir uns jetzt mit dem Connectivity-Stack, aber in einer realen Umgebung kommen noch weitere Module wie das `avm-ptn-alz’ dazu. Dieses kümmert sich dann um Management-Struktur und Policies.

Wie fangen wir an?

Mit Planung. Klar! Der erste Schritt ist die Zielarchitektur zu definieren. In unserem Fall wollen wir einen vollständigen Connectivity-Stack in der Region germanywestcentral aufbauen, der als zentrale Plattform für Hub-and-Spoke dient.

Komponenten der Zielarchitektur

Wir benötigen:

Ein Hub-VNet mit den entsprechenden Subnetzen für Firewall + Management, VPN Gateway und Bastion Host
Eine Azure Firewall Standard
Ein VPN Gateway für die Verbindung zum On-Premises Netzwerk
Routing, um den Traffic über die Firewall zu leiten
Logging, um die Aktivitäten der Firewall zu überwachen
Ein Bastion Host für den Zugriff auf alle Ressourcen in den Spokes

Zusätzlich stellen wir uns die Frage nach dem Lebenszyklus der Ressourcen. Beispielsweise gehe ich davon aus, dass Firewall-Regeln wesentlich häufiger angepasst werden als die Firewall selbst. Daher könnte es Sinn ergeben, die Basis-Komponenten wie Firewall/VPN/Bastion/Netz in einem eigenen Terraform-Projekt zu verwalten, während die Regeln in einem separaten Projekt liegen.

Das ist aber natürlich abhängig von der individuellen Umgebung und den Anforderungen.

Datei-Struktur

Unser Code-Beispiel verzichtet auf die Trennung in mehrere Projekte, damit ihr den Code in einem GitHub-Repository einfacher nachvollziehen könnt. Wir “simulieren” die Trennung der Projekte hier durch simple Ordner-Struktur.

Aufbau des Hub-Deployments

Schritt 1: Modul einbinden und grundsätzliche Konfiguration

Zunächst binden wir das Pattern-Modul avm-ptn-alz-connectivity-hub-and-spoke-vnet in unserem main.tf ein und bauen uns eine passende Resource Group.

Am Modul konfigureren wir im ersten Schritt, welche Ressourcen wir überhaupt bereitstellen wollen. Wie diese Ressourcen konfiguriert werden, also z.B. die Adressbereiche, die Firewall- und VPN-Einstellungen, etc. wird in den nächsten Schritten angepasst.

Das Modul erlaubt es, mehrere Hubs gleichzeitig bereitzustellen. Deshalb können wir einerseits die auszurollenden Ressourcen global angeben und andererseits pro Hub anpassen. In diesem Beispiel verwenden wir die globale Konfiguration, um DDoS Protection Pläne zu deaktivieren und die Hub-spezifische Konfiguration, um Firewall, VPN Gateway und Bastion Host zu aktivieren.

terraform

module "connectivity" {
  source  = "Azure/avm-ptn-alz-connectivity-hub-and-spoke-vnet/azurerm"
  version = "0.16.13"

  hub_and_spoke_networks_settings = {
    enabled_resources = {
      ddos_protection_plan = false
    }
  }

  hub_virtual_networks = {
    gwc = {
      location = "germanywestcentral"

      default_parent_id = azurerm_resource_group.hub.id

      enabled_resources = {
        firewall                              = true
        firewall_policy                       = true
        virtual_network_gateway_vpn           = true
        virtual_network_gateway_express_route = false
        bastion                               = true
        private_dns_zones                     = false
        private_dns_resolver                  = false
      }
    }
  }
}

resource "azurerm_resource_group" "hub" {
  name     = "rg-hub-network-gwc"
  location = "germanywestcentral"
}

Schritt 2: IP-Addressplanung

An sich müssten wir keine IP-Adressbereiche angeben, da das Modul automatisch Adressbereiche für die Firewall, VPN Gateway, etc. generiert. Es ist aber natürlich sinnvoll, die Adressplanung selbst in der Hand zu haben und nicht dem Modul zu überlassen. Zumal das Modul 10.0.0.0/22 als Hub-Adressraum nutzen möchte. Das ist für einen Test okay, aber meistens nicht für produktive Umgebungen geeignet (weil bereits besetzt) und ich die Größe auch für etwas übertriebe groß halte (/22 sind rund 1000 nutzbare Adressen).

Wir planen für unsere Hub-Umgebung den Adressraum 10.20.0.0/23.

Tipp: Zur Addressplanung nutze ich das wunderbare Tool Visual Subnet Calculator. Unsere Planung mit Aufteilung der Subnetze könnt ihr hier sehen: Hub-Subnetze auf Visual Subnet Calculator. Ich stelle gerne die Firewall vorne in’s Netzwerk und Gateway ganz hinten in das Netzwerk.

Wie bilden wir die Subnetze?

In Terraform nutze ich dafür die Funktion cidrsubnet(), um aus dem Hub-Adressraum konsistent Subnetze für Firewall, Firewall Management, VPN Gateway und Bastion Host zu generieren. So vermeide ich manuelle Fehler bei der Subnetzplanung und kann für weitere Hubs einfach einen neuen Adressraum definieren und die Subnetze errechnen sich automatisch.

Die Funktion ist etwas tricky zu verstehen (finde ich). Der erste Parameter ist der Adressraum - klar, der zweite Parameter gibt an, wie viele zusätzliche Bits angefügt werden sollen (bei uns /23 + 3 = /26) und der dritte Parameter ist die Nummer des Subnetzes, das generiert werden soll - beginned bei 0 (bei uns bspw. für Bastion das siebente /26 Subnetz aus /23 = 10.20.1.128/26).

Um die Übersicht zu behalten, definiere ich die Adressräume für Hub und Subnetze als locals und nutze diese dann in der Modul-Konfiguration.

terraform

locals {
  hub_address_prefix                = "10.20.0.0/23"
  subnet_firewall_prefix            = cidrsubnet(local.hub_address_prefix, 3, 0)
  subnet_firewall_management_prefix = cidrsubnet(local.hub_address_prefix, 3, 1)
  subnet_bastion_prefix             = cidrsubnet(local.hub_address_prefix, 3, 6)
  subnet_gateway_prefix             = cidrsubnet(local.hub_address_prefix, 3, 7)
}

Über den Parameter hub_virtual_network und den Unter-Parameter address_space können wir diesen Adressraum angeben und dann für unsere Komponenten die Subnetze definieren. Diese folgen immer dem gleichen Muster. Komponententyp als Parameter und subnet_address_prefix als Unter-Parameter. Die Azure Firewall bekommt zwei Subnetze, eines für die Firewall selbst und eines für das Management-Interface. Ich empfehle euch sehr, neue Firewall-Deployments mit Management Subnetz zu planen, selbst wenn dies noch nicht verpflichtend ist. Das lohnt sich in Zukunft!

Im Code nutzen wir dann diese locals.

terraform

hub_virtual_networks = {
  gwc = {
    location = "germanywestcentral"

    default_parent_id = azurerm_resource_group.hub.id

    enabled_resources = {
      firewall                              = true
      firewall_policy                       = true
      virtual_network_gateway_vpn           = true
      virtual_network_gateway_express_route = false
      bastion                               = true
      private_dns_zones                     = false
      private_dns_resolver                  = false
    }

    hub_virtual_network = {
      address_space = [local.hub_address_prefix]
    }

    firewall = {
      subnet_address_prefix            = local.subnet_firewall_prefix
      management_subnet_address_prefix = local.subnet_firewall_management_prefix
    }

    virtual_network_gateways = {
      subnet_address_prefix = local.subnet_gateway_prefix
    }

    bastion = {
      subnet_address_prefix = local.subnet_bastion_prefix
    }

  }
}

Schritt 3: Ausgestaltung unserer Komponenten

Nachdem wir die grundlegende Struktur unseres Hubs definiert haben, können wir jetzt die einzelnen Komponenten weiter konfigurieren. Wir werden eine Azure Firewall Standard bereistellen, ein zonen-redundantes VPN Gateway kleinerer Größe und für den Bastion Host aktivieren wir uns noch ein paar gute Funktionen.

Unser Firewall-Parameterblock wird jetzt so aussehen:

terraform

firewall = {
  subnet_address_prefix            = local.subnet_firewall_prefix
  management_subnet_address_prefix = local.subnet_firewall_management_prefix
  sku_name                         = "AZFW_VNet"
  sku_tier                         = "Standard"
  management_ip_enabled            = true
}

Für das VPN Gateway wählen wir die SKU VpnGw1AZ. Wir können hier auch gleich einen Tunnel konfigurieren und damit sofort die Verbindung zum On-Premises Netzwerk herstellen - es sprengt nur unser Beispiel. Dinge, wie die Erstellung einer Route Table für das GatewaySubnet steuern wir ebenfalls direkt in der Config.

terraform

virtual_network_gateways = {
  subnet_address_prefix                      = local.subnet_gateway_prefix
  route_table_creation_enabled               = true
  route_table_gateway_firewall_route_enabled = false
  vpn = {
    sku             = "VpnGw1AZ"
    vpn_bgp_enabled = false
  }
}

Für unseren Bastion Host aktivieren wir einige Funktionen, die das Leben erleichtern.

terraform

bastion = {
  subnet_address_prefix = local.subnet_bastion_prefix
  zones                 = []
  bastion_public_ip = {
    zones = []
  }
  file_copy_enabled      = true
  copy_paste_enabled     = true
  ip_connect_enabled     = true
  tunneling_enabled      = true
  shareable_link_enabled = true
}

Schritt 4: Firewall Policy in anderer Resource Group

Die Firewall Policy wird in einer eigenen Resource Group bereitgestellt. Wir haben ja am Anfang definiert, dass die Policy einem anderen Lebenszyklus unterliegen könnte als die Firewall selbst. Auch dies können wir einfach über die Parameter steuern.

DNS Proxy Funktionalität schalten wir hier direkt mit ein, damit die Firewall auch in Netzwerk-Regeln / Layer 3 mit FQDNs umgehen kann.

Der Firewall-Policy Parameterblock sieht dann so aus:

terraform

firewall_policy = {
  resource_group_name = azurerm_resource_group.firewall_policy.name
  dns = {
    proxy_enabled = true
    servers       = []
  }
}

Die Resource Group für die Firewall Policy definieren wir weiter unten im Code:

terraform

resource "azurerm_resource_group" "firewall_policy" {
  name     = "rg-hub-firewallpolicy-gwc"
  location = "germanywestcentral"
}

Huch. Was haben wir denn hier?! Ein Osterei.
Merkt euch die Farbe für euren Eggs of Knowledge Preis.

Firewall-Regeln

Die Firewall-Regeln werden nicht über das Pattern-Modul konfiguriert, sondern über ein separates Projekt (oder simpler in unserem Beispiel als separater Ordner). Das hat den Vorteil, dass wir die Regeln unabhängig von der Firewall selbst anpassen können, ohne Gefahr zu laufen, die Firewall oder andere Ressourcen zu verändern.

Schritt 1: Firewall Policy Data Source

Zunächst müssen wir die Firewall Policy, die wir im Hub-Deployment erstellt haben, in unserem Firewall-Regel-Projekt referenzieren. Dafür gibt es zwei Möglichkeiten - entweder direkt die Resource ID als Variable übergeben oder die Firewall Policy über eine Data Source referenzieren.

In diesem Fall halte ich eine Data Source für sinnvoll.

terraform

data "azurerm_firewall_policy" "hub_fw_policy" {
  name                = "fwp-hub-gwc"
  resource_group_name = "rg-hub-firewallpolicy-gwc"
}

Schritt 2: Firewall-Regeln definieren

Für unser Beispiel habe ich uns ein paar einfache Network und Application Rules überlegt und diese auch mit IP Groups umgsetzt. Schaut euch gerne den Code im GitHub Repository an, um die vollständige Konfiguration zu sehen. Hier zeige ich euch exemplarisch, wie eine einfache Network Rule Collection definiert wird.

terraform

resource "azurerm_firewall_policy_rule_collection_group" "example" {
  name                = "rcg-hub-gwc"
  firewall_policy_id  = data.azurerm_firewall_policy.hub_fw_policy.id
  priority            = 100
    rule_collections {
        name     = "rc-hub-gwc"
        action   = "Allow"
        rules {
        name                  = "Allow-OnPrem-Server"
        rule_type             = "NetworkRule"
        source_addresses      = ["*"]
        destination_addresses = ["10.1.0.0/23"]
        destination_ports     = ["3389"]
        protocols             = ["TCP"]
      }
    }
  }
}

Weitere Gedanken und Tipps

Das Pattern-Modul ist meines Erachtens noch nicht vollständig ausgereift, aber es bietet schon jetzt eine solide Grundlage für die Bereitstellung eines Hub-and-Spoke Netzwerks in Azure.

Bspw. fehlt mir momentan noch ein guter Weg, um die Diagnostics Settings für die Firewall zu konfigurieren. Im Beispiel-Repository hab ich zusätzlich noch main.firewalldiagnostics.tf angelegt, um die Diagnostics Settings für die Firewall zu konfigurieren.

Auch bin ich über seltene Rand-Konfigurationen gestolpert, die bisher noch nicht mit dem Modul abgebildet werden können. Beispielsweise ein Active-Active VPN Gateway mit zusätzlicher P2S VPN Konfiguration.

Ausgerollte Umgebung

Nach der Bereitstellung unserer Hub-Umgebung können wir uns - dieses mal mit Hilfe von AI - ein Diagramm der ausgerollten Ressourcen generieren lassen. Das sieht dann für unsere Umgebung so aus:

Ich experimentiere noch ein wenig mit den Skills und MCP-Servern. Wahrscheinlich gibts hier noch ein paar Updates über die nächsten Tage.

Fazit

AVM und die Pattern-Module bieten eine moderne und flexible Möglichkeit, Azure-Infrastruktur zu implementieren. Sie ermöglichen es uns, Best Practices zu nutzen und gleichzeitig die Kontrolle über die Konfiguration zu behalten. Das Hub-and-Spoke Pattern-Modul ist ein großartiges Beispiel dafür, wie wir komplexe Netzwerkarchitekturen in Azure mit AVM umsetzen können.

Eggs of Knowledge

Dieser Beitrag ist Teil der “Eggs of Knowledge” Serie des MVP-Treffs. Schaut gerne auf der Webseite vorbei, um weitere spannende Beiträge zu entdecken: https://www.mvptreff.de/beitraege-aus-der-community/

Santa Claus' Cloud-Powered Christmas: Optimizing Deliveries with Azure Multi-Hub Deployments 🎅🎄🎁

Tue, 03 Dec 2024 00:00:00 GMT

This post is part of the Festive Tech Calendar 2024 - organized by the CloudFamily. Find all speakers and sessions on the Festive Tech Calendar website.
This year we are raising money for the Beatson Cancer Charity and appreciate any contribution. Go to the Just Giving Page to find out more. Thanks!

As the holiday season approaches, Santa Claus faces the challenge of delivering millions of gifts worldwide in a single night.

To achieve this feat efficiently, Santa’s North Pole IT team has turned to modern cloud infrastructure — specifically, an Azure Multi-Hub Deployment — to optimize his global delivery network. But not only our beloved Santa faces this…

The Challenge

Azure provides the ability to deploy workloads in multiple regions. This is essential not only to be closer to end customers but also to guarantee resilience. What if an Azure region goes down—how long can we afford such downtime before it seriously impacts our business?

If customers or business locations are spread across the globe, it is crucial to ensure that necessary applications and services are deployed close to these customers (Remember: Santa has a global clientele, who would be sad if the gifts arrived too late). This improves both performance and user experience.

But how do we achieve this in Azure?

Hub-and-Spoke in a single region

A common approach is the hub-and-spoke architecture, which is well-understood. A central hub network contains key components for communication and securing workloads through a central firewall. Each workload (spoke) is connected only to the hub, ensuring clear separation of workloads, as well as centralized monitoring and security.

An alternative, full-mesh networking, where every workload is connected to every other workload, is generally discouraged as it leads to a complex and hard-to-manage network structure.

So far, so good. Let’s scale.

Hub-and-Spoke across multiple regions

What if we operate in multiple regions? It makes sense to retain the hub-and-spoke model in these regions, with each region having its own hub network connected to its respective spoke networks. But how do we connect the hubs across regions, ensuring communication between workloads in different regions?

Enter Full-Mesh networking - but for the right purpose

While we avoid the full-mesh model within a single region, it is beneficial to connect all hub networks across regions. This enables fast communication between workloads in different regions. However, we still avoid direct connectivity between all workloads. We aim to maintain workload segregation and centralized monitoring.

In short: Use a full-mesh model for hub networks and a hub-and-spoke model for spoke networks.

Let’s have a look at a fully deployed Multi-Hub environment (Simplified illustration):

You can see, that each Hub is peered with each other hub, but spokes are only peered to the regional hub and also never to other spokes.

Key Considerations

VNET Address Planning

Why is this important?
Proactive address planning is foundational for achieving our scenario. We need to avoid address conflicts between VNETs to ensure seamless communication and also need contiguous ranges. I’ll explain why.

How do we proceed?

Define a sufficiently large address space for the entire Azure environment, including all regions.
Allocate a unique address range for each region.
Subdivide each region’s address range for hubs and spokes.

Avoid overlaps and ensure continuous address ranges within each region to simplify routing table configurations.

Example IP Address Planning

Description	Address range
Azure Environment	10.64.0.0/13
🌎 Azure Region East US	10.64.0.0/16
- Hub Network EUS	10.64.0.0/24
- Spoke Networks EUS	10.64.<1-255>.0/24
🌍 Azure Region West Europe	10.65.0.0/16
- Hub Network WEU	10.65.0.0/24
- Spoke Networks WEU	10.64.<1-255>.0/24
🌍 Azure Region Germany West Central	10.66.0.0/16

VNET Peering

Within a single region, spokes connect only to the hub, avoiding direct peering between spokes.

Across multiple regions, all hubs are peered with one another. This ensures traffic from a spoke in one region to a spoke in another region always flows through the respective hubs, avoiding intermediate hubs.

Hub Components

Azure VNETs are non-transitive, meaning direct connectivity is required between networks for communication.

Take for example those VNET peerings:

VNET A can communicate with VNET B, and VNET B with VNET C, but VNET A cannot directly communicate with VNET C unless there’s a routing component in VNET B.

When traffic flows from a spoke in one region to a spoke in another, it must pass through both regional hubs. Therefore, hubs must have the necessary components to route traffic between them.

Recommended Components:

VPN or ExpressRoute Gateway
Azure Firewall
Third-party virtual appliances (e.g., Check Point, Palo Alto, Fortinet)
VM acting as a router (e.g., checkout the AzureVM-Router by Daniel Mauser)

Best Practice: Use Azure Firewall or third-party virtual appliances for centralized monitoring and security.

What about other Components in Hubs?
Avoid adding other components to hubs. Deploy services like DNS, domain controllers, or … Zscaler Private Access Connectors … whatever … in dedicated spokes to simplify routing.

Routing

Routing is a critical part of this scenario. We need to ensure that traffic from a spoke in one region to a spoke in another region passes through the hubs in the respective regions. This requires appropriate configuration of the routing tables in the VNETs. Why is this configuration necessary? I’ll answer that in the next section.

What routes does a VNET know?

An Azure VNET typically knows the following routes:

Local routes: All address ranges defined within this VNET.
Routes to peered VNETs: All address ranges defined in directly peered VNETs.
Routes learned from a gateway (VPN or ExpressRoute).
Default route: 0.0.0.0/0 -> Internet.
Some private network ranges with next hop to None (We will ignore it here because it is not relevant to our scenario)

The key here is point 2. Because, a VNET only knows the address ranges of directly peered VNETs. This means a VNET does not know it could communicate with a third VNET via another VNET.

Our example is just showing two regional Hubs in East US and West Europe and only one Spoke per region to make it easier to understand :

In this example, the Routing Table for Spoke EUS looks like this:

Address prefixes	Next hop type	IP
10.64.1.0/24	Virtual Network	-
10.64.0.0/24	VNET Peering	-
0.0.0.0/0	Internet	-

Routing Table of Spoke EUS

Following what we know - since the Spoke EUS is only peered with the Hub EUS: The Spoke EUS knows only the address ranges of Hub EUS (10.64.0.0/24). It does not know the address ranges of Hub WEU, because they’re not directly peered. Thus, Spoke EUS cannot send traffic to Spoke WEU or Hub WEU. Additionally, Spoke EUS can directly communicate with the internet, which we want to avoid — this is why we have firewalls in the hubs.

Direct the traffic to the regional hub

How do we solve this problem?
Each spoke in a region gets a routing table that directs traffic to the regional hub. This is straightforward. In the routing table, we override the default route:

Address prefix: 0.0.0.0/0
Next hop type: Virtual Appliance
IP: Hub EUS Firewall IP (10.64.0.4 in this case).

From now on, any traffic from a spoke that is not destined for a system within the spoke itself is routed through the hub.

Address prefixes	Next hop type	IP
10.64.1.0/24	Virtual Network	-
10.64.0.0/24	VNET Peering	-
~~0.0.0.0/0~~	~~Internet~~	-
0.0.0.0/0	Virtual Appliance	10.64.0.4

Routing Table of Spoke EUS with added route to the firewall

Observant readers may notice that the spoke network still has a valid and functional route to the hub’s entire address range because of the peering. This route is more specific than the default route.
Is this a problem? Only if additional components have been deployed in the hubs (which we aim to avoid). These additional components can be directly reached by a spoke system without passing through the firewall, as the spoke knows the route. To prevent this, we would also need to override the hub’s address range in the spoke’s routing table. This is possible but not ideal.

Great, we can now communicate between Spoke EUS and Hub EUS Firewall. Also the Internet traffic flows through our firewall.

But how do we reach the Spoke WEU?

Hub EUS knows the following routes:

Local routes: The address range of Hub EUS.
Routes to peered VNETs: The address ranges of Spoke EUS and Hub WEU.
Routes learned from a gateway (VPN or ExpressRoute).
Default route: 0.0.0.0/0 -> Internet.

Address prefixes	Next hop type	IP
10.64.0.0/24	Virtual Network	-
10.64.1.0/24	VNET Peering	-
10.65.0.0/24	Global VNET Peering	-
0.0.0.0/0	Internet	-

Routing Table of Hub EUS

What’s missing? The route to the address range of Spoke WEU (10.65.1.0/24).

Regional routes

Do we simply add this route to the spoke?
It’s possible, but do we want to add a route for every new spoke in any region, in every hub? Even with Infrastructure as Code, this would create a significant workload, not to mention the potential for confusion and errors.

Fortunately, our careful IP address planning pays off here.
We already know the entire address range of the other regions. We can add a route for the entire address range of each region, which requires adding just one route per region.

In the routing table for Hub EUS, we add:

Adress Prefix: 10.65.0.0/16
Next hop type: Virtual Appliance
IP: Hub WEU Firewall IP (10.65.0.4 in this case).

We don’t need to specify which spoke network in WEU we want to reach because we know Hub WEU will route the traffic correctly—it is peered with the spokes in its region.

Address prefixes	Next hop type	IP
10.64.0.0/24	Virtual Network	-
10.64.1.0/24	VNET Peering	-
10.65.0.0/24	Global VNET Peering	-
0.0.0.0/0	Internet	-
10.65.0.0/16	Virtual Appliance	10.65.0.4

Routing Table of Hub EUS with added route to complete WEU region

Rinse and repeat

We apply this approach to all hubs in all regions. For each hub, we add a route for the entire address range of the other regions. Additionally, for each spoke, we add a route to the regional hub.

Summary

With careful planning of IP address ranges and routing tables, we can implement a multi-hub scenario in Azure. This ensures that workloads in different regions can communicate while traffic passes through the required security components.

…and for Santa’s IT team?
Santa’s IT team can in fact implement a nice multi-hub scenario in Azure. This setup here allows Santa’s regional operations — from toy workshops to delivery hubs — seamlessly communication across the globe. At the same time, all traffic passes through the North Pole’s advanced security systems, ensuring that the Naughty/Nice lists and other critical data remain protected.

Hope this approach was useful for you.
🎄 Happy Holidays Y’all

Outbound Internet Access for Azure VMs - your options

Wed, 04 Oct 2023 00:00:00 GMT

Since Microsoft is retiring default outbound connectivity for Azure Virtual Machines, we should have a look at the other options.

Don’t panic … yet

The retirement is announced for 30 September, 2025. Almost two years from now.

But since we all know how long projects and especially migration projects can drag on, I wouldn’t wait too much longer to start planning.

Furthermore, I recommend not deploying new workloads this way from now on. It was never really a good idea, by the way - no control over the public IP of the machine, risk of using up NAT space quickly, no inbound connections possible, etc.

General approach

It is generally not a good idea to allow VMs direct access to the Internet. Normally, we have a hub and spoke architecture in Azure and traffic from a VM in a spoke is routed through a firewall in the hub. In this case, nothing changes.

But of course, there are test environments, isolated systems, or very small deployments where such access needs to be enabled directly from the VM. So…

What are our options?

Attach a public IP address

You can attach a Basic or Standard Public IP address to the NIC. I wouldn’t recommend adding a Basic Public IP, since they’re also deprecated and will retire at the same date.

You can add either a Public IPv4 or IPv6 to the interface. For IPv6, you’ll have to add an IPv6 range to your VNET and the subnet and add a new IP Configuration to the NIC before attaching this Public IP. If you attach a Public IPv4, you can do this directly to first IP Configuration.

I recommend this approach, if you have only a few VMs within this VNET. If you choose an IPv4 this IP will cost you money. IPv6 addresses are free of charge right now.. You’ll still pay for outgoing bandwith with both options.

Keep in mind: Standard Public IP addresses are closed by default for incoming connections, so you have to attach a Network Security Group (NSG) which allows Internet access to the NIC of the VM or the subnet the VM NIC is deployed to, to get connectivity from the outside. Allowed connection to Internet is one of the default rules of an NSG, so you actually don’t have to change anything else within the NSG (though you should).

Costs: Free - Public IPv6; or Low - Public IPv4 (€3.47*)

Use a Azure Load Balancer

A public Azure Load Balancer (LB) can be configured with Outbound Rules. So if you’re going to add your VMs to a Backend Pool on the LB, the LB will be used for outgoing traffic.

Using only one Public IP can be an upside (costs), but only if you have more than ~4 VMs using the LB.

To be honest, I wouldn’t recommend this approach. The SNAT allocation is mostly static or has other downsides and doesn’t scale well. Only if you also have to provide inbound connectivity, I think this can be a viable option.

Costs: Okay - Standard Load Balancer (€17.36*) + Data Processed by LB (€4.87* for 1TB) + Public IP (€3.47*)

Use a Azure NAT Gateway

A Azure NAT Gateway gives you SNAT port functionality for automatically scaling outbound connectivity and reduce the risk of SNAT port exhaustion. It’s not possible to use it for inbound connectivity (of course), but you can add another Public IP to the VM NIC or use another Load Balancer for this.

I would recommend this, if you have many VMs within your VNET and cannot live with the risk of exhausting your SNAT ports.

Costs: Questionable (my opinion!) - NAT Gateway (€31.25*) + Data Processed by NAT Gateway (€43,84* for 1TB) - Public IP (€3.47*)

Conclusion

I strongly recommend avoiding all these options and building a reasonable Hub-and-Spoke architecture. Direct connection to the Internet is mostly a security nightmare. But if you want to use it for test scenarios or very small deployments, then use the first option (Public IP) if possible. If you need to configure dedicated traffic for multiple VMs or VM scale sets anyway, use the load balancer. Only if SNAT port exhaustion is really a risk in your environment, then use a NAT gateway.

Please remember: This reflects only my personal opinion, which does not have to be that of Microsoft or my employer. Your feedback is always welcome!

* = based on retail prices as of October 2023 in the Azure Region West Europe; Your costs might be different

Find Azure RBAC Roles with specific permissions

Mon, 03 Jul 2023 00:00:00 GMT

In order to apply the Least Privilege Principle in Azure you sometimes need to find the best fitting Azure RBAC role for the job. The default roles Owner, Contributor, Reader are just too much in most cases.

Example:
You want to give an Automation Account the permission to Start, Stop and Restart Virtual Machines in your environment.

The permissions needed to perform the actions are:

Microsoft.Compute/virtualMachines/start/action
Microsoft.Compute/virtualMachines/stop/action
Microsoft.Compute/virtualMachines/restart/action

See: Azure Built-in Roles for Virtual Machines

But how do you find the Roles with those permissions?

In the Portal navigate to the Resource (or one of the levels above)
Go to “Access Control (IAM)”, choose “Add” and then “Add role assignment”
Type in the specific action in the search field.
In our case we’re searching for ‘Microsoft.Compute/virtualMachines/start/action’
The Azure Portal will show you all Role Definitions that have this permission included.
Be aware that Microsoft has started to split the Role Definitions by “Job function roles” and “Privileged administrator roles” (the tabs above the search field).

You should aim for using a “Job function role” to actually follow the Least Privileges Principle.
Have a look at the Details view to check for the Role with the least permissions needed to perform the job.

In our case we have two viable options:

Virtual Machine Contributor - but with quite broad permissions.
One Custom Role we called “Virtual Machine Operator” with necessary permissions for starting/stopping VMs and Scale Sets.

Hope that helps.

Erste Schritte mit Azure Bicep 💪

Mon, 07 Sep 2020 00:00:00 GMT

Anfang letzter Woche hat Microsoft die erste Version (0.1) von Azure Bicep veröffentlicht.

Azure Bicep stellt eine domänenspezifische Sprache (DSL) dar, mit denen wir Azure Ressourcen deklarativ beschreiben können. Die Sprache ist kein ARM Ersatz. Vielmehr werden Bicep Templates in ARM Templates übersetzt und wir werden weiterhin ARM Templates in Azure ausrollen. ARM Templates werden damit zu einer Intermediate Language (IL)

Ziele sind, dass wir wesentlich leichter modulare Templates bauen können, eine saubere und besser lesbare Syntax erhalten und unseren Template Code besser wiederverwenden können.

Voraussetzungen

Zum Start ist nicht viel nötig. Wir benötigen die Bicep CLI und zum leichteren Schreiben die Bicep VS Code Erweiterung.

Die Schritte für macOS, Linux und Windows sind gut dokumentiert im GitHub Repository.

Erstes Template

Heute beginnen wir mit ein paar Grundlagen. Parameter, Variablen, Ressourcen, Ausgaben.

Parameter

Wir legen zunächst einen Parameter fest:

bicep

param storageAccountName string = 'mycoolstorage'

Es ist fast selbsterklärend. “param” ist das Schlüsselwort, danach folgt der Parameter-Name, dann der Parameter-Typ (string, int, bool, array, object) und ein Default Wert.

Variablen

Eine Variable kommt ohne den Typ aus (genau wie in einem ARM Template):

bicep

var location = 'westeurope'

Um einen Parameter oder eine Variable zu nutzen, benötigen wir keine Funktionsaufrufe mehr. Einfach den Namen nutzen! Ein Beispiel:

bicep

param environment = 'dev'
param appName = 'MyApp'
var vmName = 'vm-${appName}-${environment}' // Ergebnis: "vm-MyApp-dev"

Ressourcen

Bauen wir uns eine Ressource. Einen Storage Account.
Wir benötigen einen Namen, eine Location und eine Angabe über Redundanz.

bicep

resource MyStorageAccount 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: 'mycoolstorage'
  location: 'westeurope'
  kind: 'Storage'
  sku: {
    name: 'Standard_LRS'
  }
}

“resource” ist wieder das Schlüsselwort, “MyStorageAccount” ist meine Ressourcen-Referenz, die ich später im Template nutzen kann (Achtung: Das ist nicht der Name der Ressource!), dann folgt der Ressourcen-Typ mit API-Version.

Wir sollten ein paar Parameter und Variablen für unser Template nutzen:

bicep

param location string = resourceGroup().location
param environment string = 'dev'
param appName string = 'myapp'
var storageAccountName = 'st${appName}${environment}'

Der “Location” Parameter nutzt eine Expression (auch ähnlich zu ARM Templates). Der Ausdruck hier verweist auf die Location der Ressource Group, in der das Deployment ausgeführt wird.

Dazu passen wir die Ressourcen-Beschreibung an:

bicep

resource MyStorageAccount 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: storageAccountName
  location: location
  kind: 'Storage'
  sku: {
    name: 'Standard_LRS'
  }
}

Wie man an den Eigenschaften “name” und “location” erkennen kann: Sollten wir nichts verketten oder umschreiben, können wir die Variablen oder Parameter ohne weitere Funktionen nutzen. Eine - im Vergleich zu ARM - erfrischend kurze Schreibweise.

Ausgaben

Zum Schluss lassen wir uns noch beispielhaft die ID und den Blob-Endpunkt unseres Storage Accounts ausgeben:

bicep

output storageId string = MyStorageAccount.id
output blobEndpoint string = MyStorageAccount.properties.primaryEndpoints.blob

Für Ausgaben ist “output” das Schlüsselwort, dann der Name, dann der Typ. Danach nutzen wir die Ressourcen-Referenz “MyStorageAccount” und greifen auf Eigenschaften zu.
Wir können auf alle Eigenschaften zugreifen, auf die wir auch im ARM-Template Zugriff hätten.

Zu ARM übersetzen

Zunächst die vollständige Bicep-Datei (wir nennen sie “mytemplate.bicep”):

bicep

param location string = resourceGroup().location
param environment string = 'dev'
param appName string = 'myapp'
var storageAccountName = 'st${appName}${environment}'

resource MyStorageAccount 'Microsoft.Storage/storageAccounts@2019-06-01' = {
    name: storageAccountName
    location: location
    kind: 'Storage'
    sku: {
      name: 'Standard_LRS'
    }
}

output storageId string = MyStorageAccount.id
output blobEndpoint string = MyStorageAccount.properties.primaryEndpoints.blob

In einer PowerShell können wir jetzt die Datei zu ARM übersetzen lassen:

powershell

bicep build .\mytemplate.bicep

Bicep erzeugt eine “mytemplate.json” Datei. Ein, wie wir ja vermutet hatten, ARM-Template:

json

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]"
    },
    "environment": {
      "type": "string",
      "defaultValue": "dev"
    },
    "appName": {
      "type": "string",
      "defaultValue": "myapp"
    }
  },
  "functions": [],
  "variables": {
    "storageAccountName": "[format('st{0}{1}', parameters('appName'), parameters('environment'))]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-06-01",
      "name": "[variables('storageAccountName')]",
      "location": "[parameters('location')]",
      "kind": "Storage",
      "sku": {
        "name": "Standard_LRS"
      }
    }
  ],
  "outputs": {
    "storageId": {
      "type": "string",
      "value": "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]"
    },
    "blobEndpoint": {
      "type": "string",
      "value": "[reference(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))).primaryEndpoints.blob]"
    }
  }
}

Schon beim Lesen hier im Blog sieht man den Vergleich, wie kurz und knackig Bicep-Dateien im Vergleich zu den sehr “geschwätzigen” ARM-Templates sind.

Links: Azure Bicep Datei, Rechts: Erzeugtes ARM-Template

Was ist gut gelungen?

Die Templates sind wesentlich schmaler und lesbarer. Es erinnert sehr an Terraform.

Automatische Dependencies. Wenn ich eine Resource in einer anderen referenziere, dann fügt Bicep automatisch eine Abhängigkeit (“dependsOn”) ein.

“concat” ist Geschichte. Einfach '${appName}-abc-${environment}' schreiben. Das ist wesentlich leichter lesbar als "[concat(parameters('appName'), '-abc', variables('environment')]".

Referenzen auf andere Ressourcen und deren Eigenschaften ist auch gut gelungen.
Vorher: “reference(resourceId('Microsoft.insights/components', variables('appInsightsName'))).InstrumentationKey]"

Nachher: AppInsights.properties.InstrumentationKey

Was funktioniert (noch) nicht?

Bicep ist im Alpha-Stadium (momentan Version 0.1). Das heißt, da gibt es sicher noch jede Menge fehlende Funktionalität.

Was ist mir bisher beim Testen aufgefallen?

Keine Parameter-Datei:
Bicep 0.1 erzeugt noch eine Parameter-Datei. Es steht uns aber frei einfach eine “mytemplate.parameters.json” Datei anzulegen. Dann natürlich im ARM-Format.
Subscription Level Templates nutzen momentan das falsche Schema. Es werden nur ARM-Templates mit Resource Group Deployments erzeugt.
Das erzeugte Template kann man trotzdem auf Subscription-Ebene anwenden.
Die API-Version muss fest angegeben werden, du kannst keine Variable dafür nutzen (das ist aber eh gegen die Best Practices)
Verschacheltung von Funktionen: Ich habe es nicht geschafft bspw. einen String zusammen zu stellen und diesen dann direkt durch “toLower” zu schicken. Momentan regele ich das über zwei Variablen.

Referenzen, Version, Quellcode

Das kleine Beispiel findet ihr als Gist hier: https://gist.github.com/cloudchristoph/865c8cd2130ed4fa3700053d8c95902c
Azure Bicep GitHub Repository: https://github.com/Azure/bicep
Verwendete Bicep Version für diesen Blog-Beitrag: 0.1

Zum Schluss: Bicep? Warum denn nun gerade Bicep? “Well, your biceps let’s you flex your ARM.” 😎 … Ich bin ja schon weg…

Save money using Azure Hybrid Benefit for your VMs

Mon, 02 Mar 2020 00:00:00 GMT

What is the Hybrid (Use) Benefit?

Azure Hybrid Benefit (a.k.a. Azure Hybrid Use Benefit or HUB) is a offer by Microsoft for (re)using already existing On-premises licenses for Windows Server or SQL Server on Azure if they are under Software Assurance.

There are a few rules in place as to when and if you’re eligible for this.

A short exerpt from the Azure Hybrid Use FAQ regarding Windows Server:

Each 2-processor license or each set of 16-core licenses, Datacenter or Standard Editions, are entitled to two instances of up to 8 cores, or one instance of up to 16 cores. Datacenter Edition licenses allow for simultaneous usage both on-premises and in Azure. Standard Edition licenses must be used either on-premises or in Azure, although customers get 180 days of concurrent use rights while they are migrating their servers.

In the end, you only pay the Linux price of a virtual machine (only Compute costs), without the added minute price for the Windows Server license.

How can I use Hybrid Benefit for my VM?

You can activate this benefit while deploying your VM from the Portal.

Activate Azure Hybrid Use while deploying your VM

If you’re deploying your VM via PowerShell or Azure CLI you have to provide the “LicenseType” parameter.

Here is an example creating a new Windows Server 2016 VM with activated Hybrid Benefit.

powershell

New-AzVM `
    -ResourceGroupName "rg-workload1" `
    -Name "vm-srvwithhub" `
    -Location "West Europe" `
    -ImageName "Win2016Datacenter" `
    -LicenseType "Windows_Server"

How can I see how many VMs are using Hybrid Benefit?

It’s really just a parameter on the VM. So you can easily query all VMs within your subscription and look at the “LicenseType” parameter.

powershell

Get-AzVM ` | 
    Where-Object { $_.LicenseType -like "Windows_Server" } | `
    Select-Object ResourceGroupName, Name, LicenseType -ExpandProperty "HardwareProfile"

Be sure to also view and export the hardware size to determine exactly how many Windows Server licenses you are using.

For how many VMs may I activate the Hybrid Benefit?

Use this calculator to get your maximum server count with activated HUB: https://azure.microsoft.com/en-us/pricing/hybrid-benefit/

Hybrid Benefit Calculator for Windows Server VMs

I hope this helps you to save further (also unnecessary) costs in Azure.

Export your Azure inventory as CSV files

Tue, 18 Feb 2020 00:00:00 GMT

You can always use the Azure portal to export all your resources to one CSV file (Use the “All resources” blade and then click “Export to CSV”).

Script for exporting your inventory

Or you can use this script to export your Azure inventory. It builds different CSV files for each subscription with resources.
After downloading open your favorite PowerShell and type:

powershell

.\Get-AzureInventory.ps1

Marketplace resources vs. CSP contracts

It also creates a CSV file thats contains only your marketplace items. This is most useful if you change your Azure contract model.

For example you switch from your EA/SCE or Pay-As-You-Go to a CSP contract then some of the marketplace resources aren’t available yet in CSP.

So you can send your CSP provider this files to give them an overview about your Azure environment and then discuss with them if all your resources will be available.

Download

Download ZIP file

or view the repository on GitHub:
https://github.com/cloudchristoph/AzureInventory

I’ve tested this with:

PowerShell 5.1
PowerShell 6.0 Core
Azure Az Module Version 3.3.0

Don’t hesitate to contact me if you have questions or ideas for this script.

What are the default security settings for an Azure VNet?

Mon, 17 Feb 2020 00:00:00 GMT

My client has asked me in our workshop:

What are the default security settings for an Azure VNet?

On an Azure VNet you cannot initially apply things like a Network Security Group, only things like allowed services (via Service endpoints or Private endpoints). So there are no default security settings except those that Microsoft itself always applies (e.g. DDoS Protection).

However, each VNet consists of at least one subnet. Network Security Groups (NSGs) can (and should) then be applied at the subnet level.

Whats a Network Security Group?

An NSG contains security rules in the form of a 5-tuple ACL.
So you define source IP (or IP range), destination IP (or IP range), source port, destination port and protocol (TCP or UPD). Furthermore you define the action - Allow or Deny.

The order is determined by priority. Higher priority (lower number) means that the rule will beat a rule with lower priority.

What are the default rules?

Default Network Security Group rules

For outgoing connections you’ll find these rules:

Allow any outgoing connections to other resources in the same VNet
Allow any outgoing connections to the Internet
Everything else outgoing? Deny

For incoming connections you’ll find these rules:

Allow any incoming connections from other resources in the same VNet
Allow any connections from Azure Load Balancer probes
Everything else incoming? Deny

“Unwritten rule” - Port 25

Port 25 (used for sending Emails over SMTP) is blocked by default if you’re not on an EA contract or your agreement was made after November 2017. If you want to send Mails from your VMs over Port 25, you’ll have to open a support case at Microsoft.
Why does this rule exist? I think that Microsoft wants to prevent spambots from running in Azure on a large scale and messing up the entire IP address space.

Should I adjust these default rules?

It depends (of course). For example, if you don’t want your resources in this VNet to communicate directly with the Internet, you have to adapt this rule.
Very often a rule is also set up that opens the RDP port for Windows or SSH for Linux. For this you should rather use modern methods like Azure Bastion or Just-in-time Access.

Learn more

Microsoft Docs about Network Security Groups

4 useful sites for your next Azure Workshop

Wed, 12 Feb 2020 00:00:00 GMT

Besides the Azure Portal of course, there are some useful and nicely done websites that I use during my workshops. Maybe they are also helpful for your next meeting.

Azure Charts

This site from Alexey Polkovnikov gives you a great overview over all Azure services and their latest updates. At this moment the region comparison tool is very useful to me. I use it for example to show my customers what services are still missing in the new Germany datacenters compared to West Europe.

cloudchristoph

Apply Tenant Restrictions with Azure Firewall

Prerequisites

Why the network path, when you don’t manage the devices

Step 1: Make sure the policy exist in Entra ID

Option A: The Entra Admin Portal

Option B: Microsoft Graph

Step 2: Inject the header in Azure Firewall

The header

The rule

Step 3: Prove it actually works

What could go wrong

Conclusion

Further reading

Hub-Deployment mit Azure Verified Modules

Auf GitHub verfügbar

Was ist AVM? Was ist ein Pattern-Modul?

Warum AVM für Hub-and-Spoke?

Wie fangen wir an?

Komponenten der Zielarchitektur

Datei-Struktur

Aufbau des Hub-Deployments

Schritt 1: Modul einbinden und grundsätzliche Konfiguration

Schritt 2: IP-Addressplanung

Schritt 3: Ausgestaltung unserer Komponenten

Schritt 4: Firewall Policy in anderer Resource Group

Firewall-Regeln

Schritt 1: Firewall Policy Data Source

Schritt 2: Firewall-Regeln definieren

Weitere Gedanken und Tipps

Ausgerollte Umgebung

Fazit

Eggs of Knowledge

Santa Claus' Cloud-Powered Christmas: Optimizing Deliveries with Azure Multi-Hub Deployments 🎅🎄🎁

The Challenge

Hub-and-Spoke in a single region

Hub-and-Spoke across multiple regions

Enter Full-Mesh networking - but for the right purpose

Key Considerations

VNET Address Planning

VNET Peering

Hub Components

Routing

What routes does a VNET know?

Direct the traffic to the regional hub

Regional routes

Rinse and repeat

Summary

Outbound Internet Access for Azure VMs - your options

Don’t panic … yet

General approach

Attach a public IP address

Use a Azure Load Balancer

Use a Azure NAT Gateway

Conclusion

Find Azure RBAC Roles with specific permissions

But how do you find the Roles with those permissions?

Erste Schritte mit Azure Bicep 💪

Voraussetzungen

Erstes Template

Parameter

Variablen

Ressourcen

Ausgaben

Zu ARM übersetzen

Was ist gut gelungen?

Was funktioniert (noch) nicht?

Referenzen, Version, Quellcode

Save money using Azure Hybrid Benefit for your VMs

What is the Hybrid (Use) Benefit?

How can I use Hybrid Benefit for my VM?

How can I see how many VMs are using Hybrid Benefit?

For how many VMs may I activate the Hybrid Benefit?

Export your Azure inventory as CSV files

Script for exporting your inventory

Marketplace resources vs. CSP contracts

Download

What are the default security settings for an Azure VNet?

Whats a Network Security Group?

What are the default rules?