Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Lernprogramm können Sie Ihre Azure Enklavenarchitektur für die Bereitstellung von Azure Virtual Desktop und Azure Kubernetes Service (AKS) Workloads planen. Die richtige Planung gewährleistet optimale Sicherheit, Netzwerkisolation und Ressourcenorganisation.
In diesem Tutorial erfahren Sie, wie:
- Planen Sie Ihre Enklaven-Topologie für die Isolierung von Workloads
- Berechnen von Subnetzgrößesanforderungen für Azure Virtual Desktop und AKS
- Identifizieren erforderlicher Netzwerkendpunkte und Konnektivität
- Konzipieren von Enklavenverbindungen für die Kommunikation zwischen Enklaven
- Workload-Ressourcengruppen effektiv organisieren
Voraussetzungen
In diesem Lernprogramm wird davon ausgegangen, dass Sie konzepte aus diesen Lernprogrammen verstehen:
- Lernprogramm 1-1: Bereitstellen einer Community
- Lernprogramm 1-2: Erstellen von Enklaven in einer Community
- Lernprogramm 1-3: Erstellen von Workloads in einer Enklave
- Lernprogramm 1-4: Verwenden des Dienstkatalogs
- Lernprogramm 1-5: Erstellen von Enklavenendpunkten und Verbindungen
- Grundlegendes zu Azure Virtual Desktop
- Grundlegendes zu Azure Kubernetes Service
Architekturübersicht
Das folgende Diagramm zeigt die Architekturlernprogramme 2-1 bis 2-4. Die Architektur umfasst einen Community-Hub mit Firewall, separate Enklaven für Azure Virtual Desktop- und AKS-Workloads sowie die erforderlichen Endpunkte und Verbindungen.
Wichtige Planungsentscheidungen
Enklaventopologie
Sie müssen entscheiden, ob Sie Azure Virtual Desktop und AKS in separaten Enklaven oder in einer gemeinsamen Enklave bereitstellen.
| Auswahl | Benefits | Considerations |
|---|---|---|
| Separate Enklaven | • Maximale Isolation zwischen Workloadtypen • Unabhängige Netzwerkrichtlinien • Einfachere Verwaltung unterschiedlicher Complianceanforderungen • Löschen von Sicherheitsgrenzen |
• Komplexere Enklavenverbindungen • Weitere Enklavenressourcen • Potenzial für doppelte gemeinsame Dienste |
| Eine Enklave | • Vereinfachtes Netzwerk • Gemeinsame Dienste • Weniger Enklavenverbindungen erforderlich • Geringerer Verwaltungsaufwand |
• Weniger Isolation zwischen Arbeitslasten • Gemeinsame Netzwerkrichtlinien |
| Hybrid mit Enklave für gemeinsame Dienste | • Arbeitslasten isolieren und gleichzeitig gemeinsame Ressourcen nutzen • Zentrale Dienste wie Key Vault, Domain Name System (DNS) • Das Beste aus beiden Ansätzen |
• Anfangs am komplexesten einzurichten • Erfordert sorgfältige Planung von Enklavenverbindungen |
Empfehlung: Verwenden Sie für Produktionsumgebungen mit strengen Sicherheitsanforderungen separate Enklaven für Azure Virtual Desktop und AKS und eine dritte Enklave für gemeinsame Dienste und gemeinsame Ressourcen. Diese Lernprogrammreihe führt durch den separaten Enklavenansatz.
Subnetzgröße für Azure Virtual Desktop
Azure Virtual Desktop erfordert mindestens zwei Subnetze in der Enklave:
| Subnet | Purpose | Empfohlene Größe | Berechnung |
|---|---|---|---|
| Verwaltungssubnetz | Hostpool, Arbeitsbereich, Anwendungsgruppen, private Endpunkte | /26 (64 IPs) | Fünf reservierte Azure IPs + Managementressourcen + Wachstum |
| Subnetz der Sitzungshosts | Azure Virtual Desktop-Sitzungshosts – Virtual Machines (VMs) | Hängt von der VM-Anzahl ab | (Number of VMs + 5 reserved) + 20% growth |
Beispielberechnung für das Subnetz für Sitzungshosts:
- 50 geplante Sitzungshosts
- Formel:
(50 + 5) × 1.2 = 66 IPs needed - Empfohlen:
/26(64 IPs) oder/25(128 IPs) für Wachstum
Important
Sie können die Größe eines Subnetzes nicht ändern, nachdem Ressourcen bereitgestellt wurden. Planen für Wachstum.
Subnetzgröße für AKS
AKS erfordert mindestens drei Subnetze in der Enklave:
| Subnet | Purpose | Empfohlene Größe | Berechnung |
|---|---|---|---|
| Knotensubnetz | AKS-Arbeitsknoten | Hängt von der Anzahl der Pods ab | (max nodes + 1) + ((max nodes + 1) × max pods per node) |
| API-Server-Subnetz | Endpunkt für private API-Server | /28 (16 IP-Adressen) | Kleines Subnetz für API-Server |
| Subnetz für private Endpunkte | Private Endpunkte für AKS-Dienste | /26 (64 IPs) | Private Endpunkte für verschiedene AKS-Dienste |
Beispielberechnung für ein Knotensubnetz (30 Pods pro Knoten, max. 3 Knoten):
- Formel:
(3 + 1) + ((3 + 1) × 30) = 4 + 120 = 124 IPs needed - Empfohlen:
/25(mindestens 128 IPs)
Important
Planen Sie Upgradevorgänge, für die ein zusätzlicher Knoten erforderlich ist.
Netzwerkanforderungen
Azure Virtual Desktop: Erforderliche Endpunkte
Azure Virtual Desktop erfordert eine Verbindung mit den folgenden Endpunkten über Communityendpunkte:
| Purpose | Endpunktname | Ports | Protocol |
|---|---|---|---|
| Azure Virtual Desktop Control Plane | *.wvd.microsoft.com*.prod.warm.ingest.monitor.core.windows.net |
443 | HTTPS |
| Authentication | login.microsoftonline.comlogin.windows.net |
443 | HTTPS |
| Azure Resource Manager | management.azure.com |
443 | HTTPS |
| Agent-Aktualisierungen | mrsglobalstb2prod.blob.core.windows.netgcs.prod.monitoring.core.windows.net |
443 | HTTPS |
| Gastkonfiguration | *.guestconfiguration.azure.com |
443 | HTTPS |
| Windows Update | *.prod.do.dsp.mp.microsoft.comwww.msftconnecttest.com |
443/80 | HTTPS/HTTP |
Referenz: Azure Virtual Desktop erforderliche URLs
Erforderliche AKS-Endpunkte
AKS erfordert Konnektivität mit den folgenden Endpunkten über Community-Endpunkte:
| Purpose | Endpunktname | Ports | Protocol |
|---|---|---|---|
| Containerregistrierung | mcr.microsoft.com*.data.mcr.microsoft.com |
443 | HTTPS |
| Clusterverwaltung | *.hcp.<region>.azmk8s.io |
443 | HTTPS |
| Azure Resource Manager | management.azure.com |
443 | HTTPS |
| Authentication | login.microsoftonline.com |
443 | HTTPS |
| Paket-Repository | packages.microsoft.comacs-mirror.azureedge.net |
443 | HTTPS |
Referenz: Für AKS erforderliche ausgehende Netzwerkregeln
Kommunikation zwischen Enklaven
Wenn Sie separate Enklaven verwenden, benötigen Sie Enklavendpunkte und Verbindungen für:
| Quelle | Bestimmungsort | Purpose | Ports |
|---|---|---|---|
| Azure Virtual Desktop Enklave | Bereich für gemeinsame Dienste | Key Vault, DNS, Überwachung | 443, 53 |
| AKS Enklave | Bereich für gemeinsame Dienste | Key Vault, DNS, Überwachung | 443, 53 |
| Azure Virtual Desktop Enklave | AKS Enklave | Optional: Direkte Kommunikation | Hängt von den Anforderungen ab |
Ressourcenorganisation
Ressourcengruppen für Workloads
Jede Workload sollte über eine oder mehrere Ressourcengruppen verfügen. Berücksichtigen Sie diese Organisation:
Azure Virtual Desktop Workload-Ressourcengruppen:
-
rg-avd-controlplane- Hostpools, Arbeitsbereiche, Anwendungsgruppen -
rg-avd-sessionhosts– Sitzungshost-VMs und zugehörige Ressourcen -
rg-avd-storage- FSLogix Speicherkonten -
rg-avd-shared– Freigegebene Ressourcen wie Key Vault, verwaltete Identitäten
AKS-Workload-Ressourcengruppe:
-
rg-aks-cluster- AKS-Clusterbenutzerressourcengruppe -
rg-aks-nodes- AKS Managed Resource Group (automatisch erstellt) -
rg-aks-shared– Freigegebene Ressourcen wie Key Vault, verwaltete Identitäten
Ressourcengruppen für gemeinsame Dienste (bei Verwendung der Enklave für gemeinsame Dienste):
-
rg-shared-security– Key Vaults, verwaltete Identitäten, Datenträgerverschlüsselungssätze -
rg-shared-network- Privates DNS Zonen -
rg-shared-monitoring- Log Analytics-Arbeitsbereiche
Allgemeine Abhängigkeitenplanung
Sowohl Azure Virtual Desktop als auch AKS erfordern diese allgemeinen Abhängigkeiten:
| Resource | Purpose | Gemeinsam oder pro Workload |
|---|---|---|
| Vom Benutzer zugewiesene verwaltete Identität | Auf Key Vault für Verschlüsselungsschlüssel zugreifen | Kann gemeinsam genutzt werden oder pro Workload |
| Schlüsseltresor | Speichern von Verschlüsselungsschlüsseln, geheimen Schlüsseln, Zertifikaten | Empfohlen: geteilt |
| Kundenseitig verwalteter Schlüssel (CMK) | Verschlüsseln von Datenträgern und Daten | Kann gemeinsam genutzt oder pro Workload verwendet werden |
| Datenträgerverschlüsselungssatz | Anwenden von CMK auf verwaltete Datenträger | Workloadspezifisch |
| Privates DNS-Zonen | DNS-Auflösung für Private Endpoints | Enklavenübergreifend freigegeben |
| Log Analytics-Arbeitsbereich | Zentralisierte Protokollierung und Überwachung | Enklavenübergreifend freigegeben |
Empfehlung: Reduzieren Sie doppelte Ressourcen, indem Sie gemeinsame Abhängigkeiten in einer Enklave oder einem Workload für gemeinsame Dienste bereitstellen.
Sicherheitsüberlegungen
Netzwerkisolation
- Verwenden separater Subnetze für verschiedene Ressourcentypen
- Anwenden von NSG-Regeln (Network Security Group) auf Subnetze
- Verwenden privater Endpunkte für Azure PaaS-Dienste
- Reduzieren Sie Community-Endpunkte auf die Endpunkte, die Sie benötigen.
Encryption
- Aktivieren Sie kundenseitig verwaltete Schlüssel (CMK) für alle gespeicherten Daten
- Verwenden von Datenträgerverschlüsselungssätzen für VM-Datenträger
- Aktivieren der Verschlüsselung auf host für AKS-Knoten
- Speichern Sie alle Schlüssel in Azure Key Vault, und weisen Sie Zugriffsberechtigungen nach dem Prinzip der geringsten Rechte zu.
Zugriffskontrolle
- Verwenden von Azure Rollenzuweisungen für den Ressourcenzugriff
- Implementieren des Just-in-Time-Zugriffs (JIT) für administrative Vorgänge
- Verwenden von verwalteten Identitäten anstelle von Dienstprinzipalen, sofern möglich
- Anwenden des Prinzips der geringsten Berechtigung auf alle Rollenzuweisungen
Überwachung
- Aktivieren von Diagnoseeinstellungen für alle Ressourcen
- Konfigurieren Azure Virtual Desktop Insights für die Sitzungshostüberwachung
- Konfigurieren Sie Container Insights für die AKS-Überwachung
- Senden aller Protokolle an einen zentralen Log Analytics Arbeitsbereich
Nächste Schritte
Nachdem Sie Ihre Architektur geplant haben, führt Sie das nächste Lernprogramm durch die Erstellung der Azure Enklave-Umgebung für Ihre Workloads.