Voraussetzungen¶

Diese Seite listet auf, was vorhanden sein muss, bevor das Portal in einer Umgebung deployt werden kann. Sie richtet sich an das Plattform-Team und an die Personen, die die einzelnen Punkte auf Kundenseite erfüllen. Im Betriebsmodell Eigenbetrieb erfüllt das Plattform-Team alle Punkte selbst, siehe Betriebsmodelle.

Dies ist ein Referenzdesign: Bestätige die Werte mit dem Engineer, der deployt, denn deine Umgebung kann abweichen. Mit (für: Feature) markierte Punkte werden nur gebraucht, wenn dieses Feature im Umfang ist.

Zusammenfassung¶

Bereich	Punkt
Azure	Zwei subscriptions (Nicht-Produktion und Produktion), eine Deployment-Identität mit Owner auf jeder
Netzwerk	VNet und Subnets pro Umgebung, ausgehendes HTTPS zur Azure Control Plane und zu Microsoft Graph
Identität	Entra-App-Registrierung pro Umgebung, Graph-Anwendungsberechtigungen für die Managed Identity
Zugriff	Reader-Rollen für die Managed Identity des Portals
Repositories	Lesezugriff auf die einzulesenden Repositories, Contribute-Zugriff auf die Konfigurations-Repositories
Provider	Resource Provider registriert, wo AI Foundry oder Kosten-Exporte genutzt werden
Optional	DNS-Zone und Zertifikat, WAF, GitHub App, private Module Registry

Azure-subscriptions und Deployment-Identität¶

Zwei Azure-subscriptions, eine für die Nicht-Produktions- und eine für die Produktionsumgebung.
Ein Deployment-Service-Principal für jede subscription mit der Rolle Owner. Federated Credentials werden Client Secrets vorgezogen (Deployment und Umgebungen).
(für: KI-Agenten) Diese Resource Provider auf der subscription registriert, die AI Foundry hostet: Microsoft.App, Microsoft.ContainerService, Microsoft.CognitiveServices, Microsoft.KeyVault, Microsoft.Network, Microsoft.Search, Microsoft.Storage. Das Terraform-Modul für Foundry registriert ebenfalls Resource Provider, siehe KI-Einrichtung.
(für: Cost Insights) Microsoft.CostManagement auf jeder subscription im Scope registriert. Das Portal registriert keine Provider. Ohne Registrierung überspringt es diese subscription und versucht es beim nächsten Lauf erneut.

az provider register --namespace Microsoft.CostManagement --subscription <subscription-id>

Netzwerk¶

Erstelle pro Umgebung und Region ein virtuelles Netzwerk mit einem nicht überlappenden Adressbereich. In einer Managed Platform ist das ein spoke (Spoke canvas).

Subnet	Beispielbereich	Zweck
default	`10.x.x.0/26`	Private Endpoints, zum Beispiel für Storage und Key Vault
app service (delegiert)	`10.x.x.64/26`	VNet-Integration der Web-App
agents (delegiert an `Microsoft.App/environments`)	`10.x.x.128/27`	Nur für KI-Agenten, die Bring-your-own-Foundry-Ressourcen nutzen
PostgreSQL (delegiert)	`10.x.x.160/28`	PostgreSQL Flexible Server

Regeln:

Halte die Zwecke getrennt. Lege die Web-App-Integration und PostgreSQL nicht in dasselbe Subnet.
Eine Container-Apps-Umgebung mit workload profiles braucht ein eigenes delegiertes Subnet von mindestens /27.
Reserviere freien Adressraum für Wachstum und für Netzwerk-Kontrollen, die der Kunde verlangt.
In einem Hub-and-Spoke-Netzwerk müssen Routen und Firewall-Regeln dem Web-App-Subnet erlauben, Folgendes zu erreichen:
- ausgehendes HTTPS zu den Service-Tags AzureResourceManager, AzureActiveDirectory und AzureMonitor
- ausgehendes HTTPS zu graph.microsoft.com

Subnet-Namen unterscheiden sich zwischen den Quellen

Das Referenz-Terraform nennt seine Subnets default, appsvc, postgresql und containerapp. Die menschenlesbare Anleitung verwendet andere Namen. Nutze die Namen, die dein Terraform erwartet, und prüfe sie mit dem Engineer.

Rollenzuweisungen für die Managed Identity des Portals¶

Gib der Managed Identity des Portals nach dem ersten Deployment Lesezugriff auf den Azure-Bestand. Die folgenden Scopes gehen von einer Hierarchie von management groups aus, die dem Cloud Adoption Framework folgt. Engere Scopes sind möglich.

Rolle	Scope	Warum
Reader	Management group der landing zones (oder die Gruppe, die die einzulesenden workloads enthält)	Erkennt subscriptions und Ressourcen sowie die aus tags abgeleiteten Gruppierungen nach workload, Team, Domäne und Organisation. Neue subscriptions unter dem Scope werden automatisch übernommen.
Reader	Scope, der die Azure-Firewall-Ressourcen enthält	Erkennt Firewalls, deren Logs das Portal abfragt
Monitoring Reader	Derselbe Scope wie in der vorherigen Zeile	Log-Analytics-Abfragen für Firewalls
Reader	Scope, der die Application Gateways enthält	Erkennt Gateways
Monitoring Reader	Derselbe Scope wie in der vorherigen Zeile	Log-Analytics-Abfragen für Gateways
Cost Management Contributor (für: Cost Insights)	Management group der landing zones oder der Scope mit den subscriptions im Scope	Erstellt und führt pro subscription einen Cost-Management-Export aus

Die Terraform-Module weisen den Identitäten des Portals außerdem Rollen auf den eigenen Ressourcen der Umgebung zu (Key Vault Secrets User, Registry Pull, Storage-Rollen für den Kosten-Export).

Entra-App-Registrierung¶

Erstelle pro Umgebung eine App-Registrierung (zum Beispiel Acceptance und Produktion).

Element	Wert
Delegierte Graph-Berechtigungen	`email`, `offline_access`, `openid`, `profile`, `User.Read`, mit Admin Consent
Redirect-URI	`https://<portal-domain>/api/auth/microsoft/handler/frame`

Wähle, wie das Secret und die Redirect-URI verwaltet werden:

Empfohlen: Mach den Deployment-Service-Principal zum Owner der App-Registrierung und ihrer Enterprise Application und gib ihm die Graph-Anwendungsberechtigung Application.Read.All. Das Deployment rotiert dann das Secret und fügt Redirect-URIs automatisch hinzu.
Alternative: Erstelle das Client Secret von Hand und füge die Redirect-URI selbst hinzu.

Nach dem ersten Deployment erteilt ein Entra-Administrator der Managed Identity des Portals diese Graph-Anwendungsberechtigungen mit Admin Consent, damit der Catalog Benutzer und Gruppen einlesen kann:

User.Read.All
GroupMember.Read.All

Übergib ein Skript

Dieser Schritt braucht Administratorrechte im Tenant. Gib dem Entra-Administrator ein Skript statt einer Liste.

Repositories¶

Lesezugriff der Portal-Identität auf die Azure-DevOps-Repositories, deren catalog-info.yaml-Dateien eingelesen werden sollen.
Contribute-Zugriff auf die Konfigurations-Repositories, die Agenten ändern (Spoke- und Integrationskonfiguration). Der Zugriff muss das Lesen von main, das Erstellen von Branches und das Öffnen von pull requests umfassen. Die Identität braucht außerdem eine Basic-Zugriffsstufe in der Azure-DevOps-Organisation.
(für: GitHub-Integration) Eine GitHub App auf Organisations- oder Enterprise-Ebene, mit Lese- und Schreibzugriff auf contents und pull requests. Siehe Konfiguration.

Optionale Punkte¶

Punkt	Wann
DNS-Zone, CNAME- oder A-Record und ein TLS-Zertifikat	Eigene Domain (WAF und eigene Domain)
Web Application Firewall vor dem Portal	Vor Beginn des Deployments vorhanden, wenn der Kunde eine möchte
Ressourcen-tags auf workloads, mit vereinbarten Schlüsseln	Immer. Der Catalog wird aus tags aufgebaut (Catalog und Entity-Modell)
Private Module Registry	Module Registry
Private Verbindungen aus dem Netzwerk des Anbieters	Wenn der Anbieter aus seinem eigenen Netzwerk deployt (Einen Kunden onboarden)

Wer macht was¶

Rolle	Verantwortung
Delivery Manager (Anbieter)	Kundenkommunikation, Kick-off, Nachverfolgung, Abnahme
Engineer (Anbieter oder Plattform-Team des Kunden)	Bereitet die Umgebungsdefinition vor, deployt, demonstriert bei der Übergabe
Zweiter Engineer	Validiert das Deployment, eine andere Person als die, die deployt hat
Solution Lead	Entscheidet, ob eine Anfrage zur gemeinsamen Code-Basis passt
Projektmanager des Kunden	Einziger Ansprechpartner, besitzt den Fragebogen, unterschreibt die Abnahme
Cloud-Plattform-Administrator	subscriptions, Service Principals, Netzwerk, Rollenzuweisungen
Entra-Administrator	App-Registrierungen, Admin Consent, Graph-Berechtigungen
Azure-DevOps- und GitHub-Administrator	Repository-Zugriff, GitHub App
Security-Kontakt	Prüft Datenresidenz und Zugriffsmodell
Entwickler-Vertretung (optional)	Nimmt am MCP-Walkthrough teil

Im Modell Eigenbetrieb kann ein Team mehrere dieser Rollen übernehmen.