Release-Historie¶
Eine verdichtete Historie der Plattform, nach Generationen gruppiert. Sie zeigt, was jede Major- und Minor-Version brachte, welche Änderungen manuelle Schritte brauchten und wo die Plattform die Richtung geändert hat. Patch-Versionen sind gruppiert. Work-Item-Nummern und Versionstabellen pro Kunde sind bewusst weggelassen.
Zu den manuellen Schritten selbst siehe die Upgrade-Leitfäden der Plattform. Zu den Nummerierungsregeln siehe Releasing.
Versionen mit manuellen Schritten¶
| Upgrade auf | Was du von Hand tun musstest | Leitfaden |
|---|---|---|
| v4.4.0 | Dateien für policy assignments, definitions und initiatives löschen; state-storage-Overrides setzen, wenn nicht Standard; zwei policy-Objekte im Portal entfernen | v4.4.0 |
| v4.5.0 | Die Entry-pipeline bearbeiten: das Konfigurations-Repository als Ressource hinzufügen und als Artifact veröffentlichen (Single-pipeline-Layout) | v4.5.0 |
| v4.5.1 | Die benutzerdefinierten Alerting-policy-assignments und -initiatives im Portal entfernen und die Deploy_*-policy-definitions per Befehl |
v4.5.1 |
| v4.6.0 und v4.6.1 | Eine Datei ghrunners.auto.tfvars pro Umgebung und Region hinzufügen |
v4.6.x |
| v4.7.0 | Drei Defender-for-Cloud-policy-assignments im Portal entfernen | v4.7.0 |
| v4.9.0 | Dateipfade in jeder tfvars-Datei kürzen, eine firewall-Variable hinzufügen, einen environment-Parameter aus der Entry-pipeline entfernen |
v4.9.0 |
| v4.11.x | Alte Dateien für private DNS und BIO policies löschen; zwei assignments und zwei initiatives im Portal entfernen | v4.11.x |
| v4.12.x | Das private-DNS-zones-assignment und die initiative im Portal entfernen; sicherstellen, dass jedes Application-Gateway-JSON eine gültige firewall_policy_id hat |
v4.12.x |
Alle anderen Versionen dieser Historie brauchten, soweit die Upgrade-Leitfäden es zeigen, keine besonderen Schritte.
Version 2.x: das erste Landing-Zone-Produkt¶
Vor Terraform. Die Versionen 2.0 bis 2.2 bauten den hub und ergänzten ein spoke-Deployment.
| Version | Typ | Highlights |
|---|---|---|
| 2.0 | Major | Private DNS Resolver ersetzt die DNS-Proxy-virtuellen-Maschinen (eine IaaS-Komponente durch eine PaaS-Komponente ersetzt). Management-group-Struktur aus den Parameterdateien. Standard-policies, dynamische policy assignments und optionale BIO-Compliance-policies. Alerts auf dem Activity Log. Standardparameter, um Parameterdateien zu verkürzen. Azure-Firewall-SKU als Parameter. Network Watcher im Deployment. Getrennte subscriptions für connectivity und management sind möglich. |
| 2.0.1 | Patch | Fix für das Deployment der private DNS zones. |
| 2.1 | Minor | Ein gemeinsames Application Gateway, das mehrere Teams, Anwendungen oder Umgebungen nutzen können. |
| 2.1.1 bis 2.1.3 | Patch | Rollenzuweisung für die Diagnostic-Settings-policy. VNet-Peering ohne virtual network gateway. SSL-Zertifikate, Parameter und optionales Deployment beim Application Gateway. Ein Deployment-Selector für den DNS Private Resolver. Ein Problem mit dem gemeinsamen Log Analytics workspace bei green/brownfield-Deployments. |
| 2.2.0 | Minor | Virtual WAN. Bastion im hub (einmal in prod deployt statt zweimal). ExpressRoute circuit. DNS-Proxy auf der Azure Firewall, der an den Private DNS Resolver weiterleitet. Spoke-Deployment. Eine eigene firewall-rule-pipeline wegen Zeitlimits. Optionaler DDoS-Protection-Plan. Ein Resource-Health-Alert. |
Version 3.x: Terraform¶
| Version | Typ | Highlights |
|---|---|---|
| 3.0 | Major | Terraform ersetzt die bisherige Infrastructure-as-Code-Sprache. Deployments ändern nur, was sich geändert hat, mit besserer Entra-ID-Unterstützung und mehr Automatisierungsmöglichkeiten. Verbesserte Azure-DevOps-Agents mit neuer pipeline. Der Bootstrapper wurde entfernt. Optionale Overrides der Namenskonvention. Bessere generische Firewallregeln. Eine neue Methode für Disk-Alerts von virtuellen Maschinen. Fixes, damit das zentrale Bastion für spokes funktioniert. |
| 3.1 | Minor | Alerting auf Basis von Azure Policy, auch für spokes. Eine WAF-policy-Ressource ersetzt das Inline-WAF. Die canary-Umgebung kann nach einem erfolgreichen Produktions-Deployment automatisch entfernt werden, was Kosten senkt. Private Agents können Key Vaults und Storage Accounts erreichen. Mehr Namens-Overrides. |
| 3.2 | Minor | Automatische Bereitstellung des Log-Analytics-Agents für Secure Score. Einfaches Point-to-site-VPN. Ein pipeline-Template, das canary automatisch zerstört. Eine Bootstrapper-Stage für die management-group-Struktur. Private-DNS-policy für private endpoints aktualisiert und eine private DNS zone für Azure-OpenAI-Dienste. Hub Key Vaults und Storage Accounts verlieren den öffentlichen Zugriff und akzeptieren das Agent-Subnet. Sentinel und Defender for DevOps hinter feature flags. Variable für die Virtual-Hub-SKU. Terraform-Dateien verwenden Dateinamen statt vollständiger Pfade. Aktualisierte Defender-Pläne. |
| 3.2.1 | Patch | Die Soft-Delete-Aufbewahrung des Key Vault ist eine Variable. Root-Zertifikate in den Backend-HTTP-Settings des Application Gateway. |
Für die Versionen 3.3 bis 4.3 existieren keine Release Notes.
Version 4.x: Remote Sync, Policy as Code und GitHub¶
4.4: Das Code-Repository übernimmt policy und Monitoring¶
Version 4.4.0 verlagerte einen großen Teil der policy- und Monitoring-Konfiguration aus dem Parameter-Repository des Kunden in das Code- Repository. Sie brauchte manuelles Aufräumen.
| Bereich | Änderung |
|---|---|
| Code-Verteilung | Kundenkopien des Code-Repositorys werden bei einem Release automatisch synchronisiert, mit Authentifizierung per service principal (Code-Synchronisation) |
| Compliance-policy | Compliance-policy-Sets werden direkt aus dem Code-Repository zugewiesen. Einige Ressourcentypen sind von der Diagnostic-policy ausgenommen, um False Positives zu vermeiden |
| Diagnostics-policy | Das integrierte Diagnostic-policy-Set ersetzt das benutzerdefinierte Set. Logs gehen an einen Log Analytics workspace in derselben Region wie die Ressource |
| Exemptions | Automatische Exemption-Verwaltung für den hub, basierend auf dem Standard-Deployment, mit Decision Records |
| Defender for Cloud | Mit Azure Policy statt mit Terraform-Code konfiguriert |
| Monitoring | Azure Monitor Baseline Alerts (AMBA), aus dem Code-Repository deployt (So funktioniert Alerting) |
| Compliance der management layer | Storage Accounts: kein öffentlicher Zugriff, nur HTTPS, kein Shared-Key-Zugriff, Infrastructure Encryption, kein öffentlicher Zugriff auf verschachtelte Elemente, Customer-managed Keys |
Die Patch-Versionen 4.4.1 bis 4.4.12 behoben meist vier Bereiche:
| Bereich | Versionen | Was |
|---|---|---|
| Application-Gateway-Zertifikate | 4.4.1, 4.4.8 bis 4.4.10 | Zertifikate können ein in einem Key Vault gespeichertes Passwort verwenden. Fixes für Let's-Encrypt-Zertifikate (Account Key, Private Key, Ausstellung und ein Gateway, das versuchte, ein Zertifikat zu lesen, bevor es gespeichert war) |
| Selbst gehostete Agent Pools | 4.4.1, 4.4.6, 4.4.7, 4.4.11 | Getrennte Pools für canary und Produktion. Jeder layer verwendet den angegebenen Pool statt öffentlicher Agents. Option, eine statische öffentliche IP für den Key-Vault-Data-Plane-Zugriff aus dem Pool zuzulassen |
| Policy | 4.4.1 bis 4.4.5 | Policy-Reference-IDs werden anhand der Anzeigenamen gefunden. Policy-Deployments wegen Abhängigkeiten in einen anderen layer verschoben. Automatische Remediation im Post-Deployment-layer. Exemption-Referenzen korrigiert |
| Aufräumen und Automatisierung | 4.4.2, 4.4.3 | Veraltetes Security-Center-Auto-Provisioning entfernt. Automatisierte Dokumentation mit Pre-commit-Hooks. Bessere canary-destroy-pipeline. Dokumentation für Standardänderungen (4.4.1) |
Version 4.4.12 ergänzte eine Option, mit der private-link-DNS-zones auf Internet-Auflösung zurückfallen können, eine Alert Processing Rule für die verwaltende Partei, eine Firewallregel für Agents während des Firewall-Deployments und eine erzwungene Neu-Authentifizierung des Apply- Schritts, damit Federated Credentials verwendet werden können.
4.5 und 4.6: GitHub-Unterstützung¶
| Version | Typ | Highlights |
|---|---|---|
| 4.5.0 | Minor | Die Plattform-Konfiguration kann aus GitHub kommen. Forced Tunnelling für Point-to-site-VPN. Brauchte eine pipeline-Änderung. |
| 4.5.1 | Patch | AzureRM-Provider 4.37.0. Aktualisierte AMBA-Alert-policies (brauchte Aufräumen im Portal). Eine Einstellung, um die automatische Remediation von policy assignments zu steuern. Die Plan-Stage läuft während der pull-request-CI. Ein Skript, das Resource Provider für neue Implementierungen registriert. Mehrere WAF-policies werden korrekt deployt. Activity-Log-Alerts verwenden die globale Location. |
| 4.5.2 bis 4.5.5 | Patch | Fixes: Properties für virtual network und BGP-Peering in tfvars, eine WAF-Property request_body_enforcement, eine falsche Modulabhängigkeit, VPN-Verbindungs-DPD-Timeout. Ein feature flag, um Azure-Firewall-Regeln zu überspringen, wenn eine Firewall eines Drittanbieters verwendet wird. Ein längeres Timeout für das erste Deployment des connectivity layer. Private DNS zones für alle Static-Web-App-Instanzen. |
| 4.6.0 | Minor | Ein zusätzlicher layer mit dem Netzwerk für GitHub-gehostete Runner. GitHub-Workflows zum Deployen aus GitHub. Eine doppelte Alert-Action-Zuweisung entfernt. Eine private DNS zone für Azure-AI-Dienste. Brauchte eine neue tfvars-Datei. |
| 4.6.1 | Patch | Eine fehlende Bedingung ließ das Deployment fehlschlagen, wenn der GitHub-Runner-layer nicht gewünscht war. |
4.7 bis 4.12¶
Für diese Versionen gibt es keine Release Notes. Was die Upgrade-Leitfäden und der aktuelle Code zeigen:
| Version | Was sich geändert hat |
|---|---|
| 4.7.0 | Die Defender-for-Cloud-v2-policy-assignments der Scopes connectivity, identity und management wurden aus der Plattform entfernt (Leitfaden) |
| 4.9.0 | Dateipfade in tfvars beginnen nicht mehr mit dem Checkout-Ordner des Konfigurations-Repositorys. Der firewall layer hat eine Variable für den globalen Regelordner. Die Umgebung ist kein Parameter der Entry-pipeline-Templates mehr (Leitfaden) |
| 4.11.x | Die alten private-DNS-policy-definitions und -initiatives sowie die benutzerdefinierte BIO-initiative werden nicht mehr im Konfigurations-Repository gehalten. Ihre Dateien werden gelöscht, und ein altes Alerting- sowie ein altes DNS-assignment samt initiative werden im Portal entfernt (Leitfaden) |
| 4.12.x | Die private-DNS-zones-initiative wurde ersetzt, und das Application-Gateway-JSON braucht eine gültige firewall_policy_id (Leitfaden) |
Spätere Änderungen sind im aktuellen pipeline-Layout sichtbar: Entry-pipelines hub, spoke, infrastructure und
container, GitHub-Actions-Workflows neben Azure-DevOps-pipelines und Multi-Region-hubs. Siehe
Pipelines und Workflows.
Spoke-canvas-Versionen¶
Das spoke canvas war früher ein eigenes Produkt mit eigenen Versionen (v2.x). Heute ist es Teil des Code-Repositorys (Glossar). Die folgenden Notizen stammen vom eigenständigen Produkt.
| Version | Typ | Highlights |
|---|---|---|
| 2.5.7, 2.5.8 | Patch | Key-Vault-Crypto-Officer-Rolle für den Deployment-Principal (Customer-managed Key auf dem Storage Account). Die vollständige Liste der PIM-Gruppen wird verwendet, nicht nur die neueste. Eine Private-Endpoint-Netzwerk-policy, damit private endpoints die Routen vom hub nutzen. Ein Dateinamen-Fix für die Drift-pipeline |
| 2.6.0 | Minor | Federated Credentials mit Workload Identity Federation. Eine spoke-Konfiguration kann aus einem anderen Repository ausgecheckt werden (zum Beispiel GitHub). Der Terraform-State-Container wird erstellt, wenn er fehlt. |
| 2.7.0, 2.7.1 | Minor, Patch | Eine zentrale Entra-ID-Gruppe wird erstellt und verwaltet, um Zugriff auf gemeinsame Ressourcen zu geben. Ein Fix: Entra-Gruppen wurden gefiltert, statt nach ihrem exakten Namen gesucht |
| 2.8.0 bis 2.8.2 | Minor, Patch | Mehrere private endpoints pro Storage Account. Bessere pipeline-Templates für Dateipfade mit Leerzeichen. EasyPIM-Skript-Update. Ein Skript und ein Leitfaden für die Konfiguration des Billing Export. Benutzerdefinierte DNS-Server-Einstellungen (optional, listenbasiert). Änderungen an required_resource_access des spoke service principal werden ignoriert |
| 2.9.0, 2.9.1 | Minor, Patch | GitHub-Workflows. Spoke-Erweiterungen für Azure Container Registry, Communication Services, API Management, Service Bus und Event Hub (später auch GitHub-Integration), an Versions-tags fixiert. Die alte IPAM-Konfiguration wurde entfernt (Leitfaden). private_link_service_network_policies_enabled kann pro Subnet gesetzt werden. Ein Fix für die Drift-Erkennung |
| 2.10.0 | Minor | PIM-Konfigurationen werden in der gemeinsamen Konfiguration definiert (Leitfaden) |
Spoke-canvas-Fähigkeiten, die nach v2.10.0 dokumentiert sind¶
Die Dokumentation des spoke canvas beschreibt auch die folgenden Fähigkeiten. Die Version, die sie jeweils eingeführt hat, ist nicht festgehalten. Prüfe die release notes der Code-Version, die du fixiert hast, bevor du dich darauf verlässt.
| Fähigkeit | Was sie bewirkt |
|---|---|
| Schalter für Key Vault und Storage Account | deploy: false lässt das Key Vault oder den Storage Account weg. Der Storage Account erzwingt immer ein Key Vault (Spoke canvas) |
| Federated Credentials für die Azure-DevOps-Service-Connection | useFederatedCredentials: true vermeidet ein Secret für den Service Principal |
| GitHub-Extension | Ein GitHub-Repository mit Federated Credentials für den spoke, mit GitHub-App-Authentifizierung |
| PIM-Rollenzuordnung für Key Vault und Storage | Standing Read-Zugriff und PIM-eligible erhöhte Rollen, zugewiesen auf subscription-Ebene, mit Overrides (Spoke canvas) |
| IPAM-Pools | Spoke-Dateien können Adressraum aus Azure-Virtual-Network-Manager-IPAM-Pools zuweisen statt aus festen Präfixen |
| Subscription-Provisioning | Ein separater Schritt, der die subscription vorbereitet (Design) |
| Bericht zur Konfigurations-drift | Ein geplanter Plan pro spoke, der Abweichungen meldet (Design) |