Shared Services: Gateway, Registry, Pakete, API Management, Build-Agents¶

Eine Plattform bietet neben deinem Spoke oft Shared Services an. Welche es gibt, hängt von deiner Plattform ab. Diese Seite beschreibt, was sie leisten und wie Teams sie nutzen. Frag dein Plattform-Team, welche verfügbar sind. Die Seite des Plattform-Teams (was deployt ist und wie) steht unter Shared Services: was deployt ist und wie. Wer das Plattform-Team ist, hängt von deinem Betriebsmodell ab.

Dienst	Was er leistet	MCP-Produktunterstützung
Application Gateway + WAF	Veröffentlicht deine Web-App aus dem Internet, mit TLS-Terminierung und Web Application Firewall	hub-Komponente. Regeln sind Standardänderungen: Application Gateway
Shared Azure Container Registry	Zentrale Registry mit Pull-through-Cache für öffentliche Registries	`extensions.acr` im Spoke-JSON (Shared Service in `mcp.json`), siehe Spoke-Erweiterungen
Shared API Management	APIs, Produkte und Subscriptions zentral veröffentlichen	`extensions.apim` im Spoke-JSON, siehe Spoke-Erweiterungen. Siehe auch API Management (shared).
Service Bus / Event Hub	Gemeinsames Messaging	`extensions.servicebus` / `extensions.eventhub`, siehe Spoke-Erweiterungen, Messaging und Bekannte Probleme
Communication Services	E-Mails (und andere Kommunikation) aus deiner Anwendung senden	Zugriff über eine Gruppe, die das Plattform-Team verwaltet. Noch keine Spoke-Erweiterung. Siehe Communication Services.
Paket-Feeds (Azure DevOps Artifacts)	Private und gecachte NuGet-, npm-, Maven-, Python-Pakete	Azure-DevOps-Funktion. Nicht Teil des Plattform-Codes.
Build-Agents	Pipeline-Agents im Netzwerk, um auf private Ressourcen zuzugreifen	Plattformspezifisch. Nicht Teil des MCP-Produkts. Siehe Build-Agents. Plattform-Team: Container Agent Pool.
Abhängigkeits-Updates (Renovate)	pull requests für veraltete Abhängigkeiten	Plattformspezifisch

Spoke-Erweiterungen: mit einem Shared Service verbinden¶

Eine Spoke-Erweiterung verbindet deinen Spoke beim Deployment mit einem Shared Service. Das Deployment gibt deinen Gruppen den passenden Zugriff und konfiguriert den Shared Service für dich, sodass du ihn direkt nach der Auslieferung des Spokes nutzen kannst. Du wartest nicht auf eine separate Änderung.

Erweiterungen gibt es für diese Shared Services (wenn deine Plattform sie betreibt):

Erweiterung (`extensions.<name>` im Spoke-JSON)	Was du bekommst	Dein Zugriff
`apim`	Zugriff auf das Shared API Management. Im zentralen Modell auf die ganze Instanz, im dezentralen Modell auf deinen eigenen Workspace.	Owners und Contributors können APIs ändern. Readers können lesen.
`acr`	Zugriff auf die Shared Container Registry über zwei Gruppen und zwei Managed Identities deines Spokes, eine zum Pullen und eine zum Pushen von Images.	Deine Team-Gruppen bekommen durch die Erweiterung keinen Registry-Zugriff. Nutze die Managed Identities in deinen pipelines und bitte das Plattform-Team, weitere Identitäten hinzuzufügen. Du kannst keine Images löschen.
`eventhub`	Dein eigener Event Hub im Shared Namespace.	Owners bekommen Daten- und Verwaltungsrechte, Contributors können beitragen, Readers können lesen.
`servicebus`	Zugriff auf den Shared Service-Bus-Namespace.	Owners und Contributors können senden und empfangen. Readers können den Namespace lesen.
Communication Services	Derzeit nicht verfügbar.

Die genauen Rollen stehen unter Spoke-Erweiterungen.

So bekommst du eine. Bitte dein Plattform-Team (So änderst du etwas), enabled für die Erweiterung in deiner Spoke-Datei (Spoke-JSON) auf true zu setzen. Sie wirkt ab dem nächsten Spoke-Deployment. Sag dem Plattform-Team, welchen Dienst du brauchst, in welchen Umgebungen und wer in deinem Team ihn nutzen wird.

Nicht jede Erweiterung ist auf jeder Plattform verfügbar

Die Erweiterungen brauchen den Shared Service und seine Einstellungen in der Plattformkonfiguration. Frag dein Plattform-Team, welche es gibt und in welchen Regionen. Einige Felder der Erweiterungen lassen sich noch nicht setzen (Bekannte Probleme).

Wie du einen Shared Service erreichst¶

Im Referenzdesign sind die Shared Services auf dieselbe Weise abgesichert:

Kein öffentlicher Zugriff. Die Services erreichst du über einen private endpoint im Shared-Services-Spoke. Dein Verkehr läuft über die hub-firewall. Wenn eine Verbindung blockiert wird, beantrage eine Firewallregel.
Keine Keys. Lokale Authentifizierung (Shared Keys, SAS) ist bei Service Bus und Event Hubs abgeschaltet, und bei der Registry ist der Admin-User aus. Du meldest dich mit Microsoft Entra ID an, mit einer Managed Identity für Anwendungen und pipelines.
Zugriff über Gruppen. Rollen werden an Entra-ID-Gruppen vergeben (und, bei der Registry, an Managed Identities). Um Zugriff zu bekommen, bitte um die Mitgliedschaft in der richtigen Gruppe oder nutze eine Spoke-Erweiterung.
Privates DNS. Nutze den normalen Hostnamen des Services. Er muss aus deinem Spoke zur privaten Adresse aufgelöst werden.

Das sind Eigenschaften des Referenzdesigns. Frag dein Plattform-Team, was auf deiner Plattform gilt.

Eine Web-App veröffentlichen (Application Gateway)¶

Voraussetzungen: Der Security Officer hat die Veröffentlichung genehmigt und deine Anwendung erfüllt deine Sicherheitsstandards.

Anfrage mit:

Anwendungsname und Umgebung,
Backend-Adresse (IP oder FQDN) und Service-Port,
die externe URL (zum Beispiel myapp.example.com) und das Listener-Protokoll,
das TLS-Zertifikat (für HTTPS) bzw. Anforderungen an eine eigene Domain,
eine Health Probe (Pfad, Protokoll, Intervall),
ein Security-Ansprechpartner.

Hinweise:

HTTPS ist der Standard. Ein HTTP-Listener leitet normalerweise auf HTTPS um.
Mehrere Apps können mit pfadbasiertem Routing hinter einer URL liegen.
Die Priorität der Routing-Regeln ist pro Gateway eindeutig. Eine niedrigere Zahl wird zuerst ausgewertet.
Deine Plattform bietet möglicherweise Self-Service: Du bearbeitest eine JSON-Datei für deine App im Ordner mit den Gateway-Definitionen und öffnest einen pull request, den das Plattform-Team prüft und ausrollt. Frag nach, ob das bei dir zutrifft.
Zur Untersuchung blockierter Anfragen siehe Application-Gateway-Logs.

Eine berechtigte Anfrage wird von der WAF blockiert. Die WAF blockiert Anfragen, die zu ihren Managed Rules passen (zum Beispiel dem OWASP- Regelsatz), auch wenn deine Anwendung in Ordnung ist. Beantrage eine Ausnahme oder einen Ausschluss und bringe die Belege mit:

Liefere	Wo du es findest
Die Regel-ID und die Regelgruppe	Der Eintrag im firewall-Log (Application-Gateway-Logs)
Die URI und das Argument oder den Header, der die Regel auslöst	Derselbe Log-Eintrag oder deine eigene Anfrage
Warum die Anfrage berechtigt ist	Dein Anwendungsteam
Wie eng die Ausnahme sein kann: ein Header-Wert, eine Client-Adresse, eine URI	Dein Anwendungsteam

Security genehmigt die Ausnahme. Das Plattform-Team fügt die engstmögliche Regel hinzu und führt eine Liste aller Ausnahmen. Es gibt Grenzen für die Anzahl und für die Art der Werte (zum Beispiel nur einzelne IPv4-Adressen bei einem Adressabgleich), die das Plattform-Team prüft (WAF-Ausnahmen). Eine deaktivierte Regel oder eine breite Ausnahme wird normalerweise abgelehnt.

Container: Shared Azure Container Registry¶

Eine gemeinsame Registry im hub kann öffentliche Registries cachen (Microsoft Container Registry, Docker Hub, Quay), sodass Builds schneller, günstiger und unabhängig vom Internet sind.

Ursprüngliches Image	Über die Shared Registry
`mcr.microsoft.com/dotnet/aspnet:8.0`	`<registry>.azurecr.io/mcr/dotnet/aspnet:8.0`
`docker.io/library/nginx:latest`	`<registry>.azurecr.io/dockerhub/library/nginx:latest`
`quay.io/coreos/etcd:latest`	`<registry>.azurecr.io/quay/coreos/etcd:latest`

Registry-Name, Cache-Regeln und Rollen sind plattformspezifisch, und eine Registry bietet die oben genannten Cache-Pfade nur an, wenn das Plattform-Team die Cache-Regeln konfiguriert hat. Typischer Aufbau:

Im Referenzdesign ist die Registry Premium, nur über einen private endpoint erreichbar, mit abgeschaltetem Admin-User und abgeschaltetem anonymem Pull, und mit einem Customer-Managed Key verschlüsselt.
Mit der Erweiterung acr läuft der Zugriff über Gruppen: AcrPull und AcrPush werden einmal den Hauptgruppen der Registry zugewiesen, und dein Spoke bekommt von jeder eine Untergruppe, mit einer Managed Identity pro Untergruppe. Mitglieder, die das Plattform-Team den Untergruppen hinzufügt, bleiben erhalten. Wie deine eigenen Identitäten (App Service, AKS, Container Apps) AcrPull bekommen, ist plattformspezifisch. Frag nach.
Die firewall erlaubt den Zugriff aus allen Spokes bereits.
Nutze Managed Identities zum Pullen. Verwende keine Admin-Keys.

Pakete: Azure-DevOps-Feeds¶

Nutze den Feed der Organisation, damit Abhängigkeiten gecacht, gescannt und nachvollziehbar sind.

Authentifiziere dich in einer pipeline mit den integrierten Tasks (NuGetAuthenticate, npmAuthenticate, PipAuthenticate) und nutze den Feed als Quelle. Die Build-Service-Identität der pipeline authentifiziert sich innerhalb derselben Organisation.
Öffentliche URLs sind von der firewall standardmäßig blockiert. Nutze die Upstream-Quellen des Feeds, statt Regeln anzufragen.

Build-Agents im Netzwerk¶

Private Ressourcen (private endpoints, VMs ohne öffentliche IPs) sind nur aus dem Netzwerk heraus erreichbar. Wenn die Plattform gemeinsame Agent-Pools anbietet, nutze sie für Deployments in deinen Spoke:

Pool-Typ	Geeignet für	Einschränkung
VM-basierter Pool	Alles, einschließlich Root-Installationen (Docker CLI)	Startet langsamer
Container-basierter Pool	Schnelle Builds, ein frischer Container pro Job	Kein Root, daher kein Docker-Daemon. Nutze `dotnet publish` Container-Unterstützung, Podman rootless, Kaniko oder `ko`, um Images zu bauen. Der Beispiel-Pool beendet einen Job nach 30 Minuten und hat einen Kaltstart von einigen Minuten (Build-Agents).

Die Pool-Namen und der Weg zum Zugriff sind plattformspezifisch. Die Berechtigungen kommen von der Service Connection, die deine pipeline nutzt. Frag dein Plattform-Team nach Zugriff. Wie ein solcher Pool typischerweise aufgebaut ist, wie du ihn nutzt und was zu tun ist, wenn sich sein OS-Image ändert: Build-Agents. Empfohlene Azure-DevOps-Einstellungen: Azure DevOps.

Messaging: Service Bus und Event Hubs¶

Zur Integration Platform (Queues und Topics aus JSON-Dateien, Gruppen pro Entity, Event Hubs und API-Management-Design) siehe Integration Platform, Service Bus und Shared Services der Integration Platform.

Wenn deine Plattform gemeinsames Messaging betreibt, bekommst du Zugriff auf einen Shared Namespace, nicht auf einen eigenen. Im Referenzdesign:

	Service Bus	Event Hubs
Was geteilt wird	Ein Namespace (Premium SKU, private endpoint, optional Customer-Managed Key). Queues und Topics werden nicht vom Shared-Services-Code angelegt.	Ein Namespace mit einem oder mehreren Event Hubs
Anmeldung	Nur Microsoft Entra ID	Nur Microsoft Entra ID
Zugriff	Über die Spoke-Erweiterung oder über eine Contributors-Gruppe auf dem Namespace	Über die Spoke-Erweiterung. Pro Event Hub gibt es eine Sender-Gruppe und eine Receiver-Gruppe.

Nutze in deiner Anwendung eine Managed Identity und gib ihr die Data-Rollen (Sender, Receiver) über die Gruppen. Frag dein Plattform-Team, wie du einen Event Hub oder eine Queue anlegen lässt und welche Einstellungen für Namen und Aufbewahrung gelten. Wie du diese Services als Teil einer Integrationslösung nutzt, steht in der Integration Platform.

Communication Services¶

Wenn deine Plattform Communication Services betreibt, kannst du aus deiner Anwendung E-Mails über eine gemeinsame Communication-Services- und Email-Communication-Services-Ressource senden. Im Referenzdesign:

E-Mails können von einer Azure-managed Domain (wenn das Plattform-Team sie aktiviert hat) oder von einer vom Kunden verwalteten Domain gesendet werden, die das Plattform-Team der Ressource hinzufügt. Frag, welche Absender-Domains es gibt, oder beantrage eine neue.
Der Zugriff läuft über eine Contributors-Gruppe des Plattform-Teams. Für diesen Service gibt es noch keine Spoke-Erweiterung.
Delivery-Logs (Versand, Status, Engagement) gehen in den Log-Analytics-Workspace des Shared-Services-Spokes.

Frag dein Plattform-Team nach Zugriff und nach der Absender-Domain.

API Management (shared)¶

Wenn deine Plattform ein Shared APIM anbietet, veröffentlichst du eine API, indem du sie beschreibst (Name, path, Backend service_url, OpenAPI- Datei, Produkte, Subscriptions), entweder per pull request auf die API-Definitionen der Plattform oder per Anfrage. Committe keine Subscription Keys: referenziere stattdessen Key-Vault-Secrets. Im Referenzdesign ist die gemeinsame Instanz privat (ein internes Netzwerk oder ein private endpoint), ihr Developer Portal ist aus, solange das Plattform-Team es nicht aktiviert (dann ist eine Anmeldung erforderlich), und die Telemetrie geht an Application Insights, das eine Monitoring-Reader-Gruppe lesen kann. Wie du API Management als Teil einer Integrationslösung nutzt, steht in der Integration Platform.

Eine eigene API-Management-Instanz in einem Spoke¶

Wenn du API Management in deinem eigenen Spoke deployst, braucht das Netzwerk Sorgfalt, denn der Spoke-Verkehr läuft über die hub-firewall und du kannst NSGs und Route Tables nicht selbst ändern (Einschränkungen). Beantrage die Änderungen über eine Änderungsanfrage.

Ein verbreitetes sicheres Design ist eine Referenzarchitektur mit API Management im internen Modus hinter einem Application Gateway mit WAF:

Das Application Gateway hat die öffentliche IP-Adresse und veröffentlicht die APIs auf einer eigenen Domain, in einem eigenen Subnetz.
API Management (Premium) liegt in einem separaten Subnetz im internen Modus und ist nicht direkt aus dem Internet erreichbar.
Private endpoints verbinden API Management mit Backends, die nur für das Virtual Network erreichbar sind.
Logs und Telemetrie gehen an Log Analytics und Application Insights.

DNS. Im internen Modus bringst du deinen eigenen DNS mit. Registriere eine eigene Domain an der API-Management-Instanz: Sie akzeptiert nur Anfragen, deren Host-Header zur Standard-Gateway-Domain oder zu einer konfigurierten eigenen Domain passt. Dieselbe eigene Domain kann mehr als einer Instanz zugewiesen werden, sodass du Instanzen durch Ändern eines DNS-Eintrags wechseln kannst. Clients müssen die private IP-Adresse von API Management über das Netzwerk erreichen, was eine Firewallregel erfordert (Firewallregeln).

Klassische Tiers. Weil der gesamte Verkehr durch die hub-firewall gezwungen wird, ergänze:

Element	Was
User Defined Route	`0.0.0.0/0` zur firewall (Next Hop Virtual Appliance) und der Service Tag `ApiManagement` mit Next Hop Internet. Ohne die zweite Route wird der Management-Verkehr nicht auf seine Quelladressen zurückgeführt und der Management-Endpunkt wird unerreichbar.
Service Endpoints am Subnetz	Azure SQL, Azure Storage, Azure Event Hubs, Azure Key Vault
NSG	Die Regeln für den internen Modus aus dem Microsoft-Learn-Leitfaden. Eingehender Management-Verkehr auf Port 3443 nur vom Service Tag `ApiManagement`.

v2-Tiers. Diese haben im Vergleich zu den klassischen Tiers Einschränkungen: Prüfe die Funktionsverfügbarkeit.

Element	Was
Subnetz	Wird nur von einer API-Management-Instanz genutzt. Mindestens ein `/27`, empfohlen ein `/24`, damit es skalieren kann. Delegiert an `Microsoft.Web/serverFarms`. Die deployende Identität braucht `Microsoft.Network/virtualNetworks/read` und `Microsoft.Network/virtualNetworks/subnets/join/action`.
NSG	Erforderlich. Minimum: ausgehend `Tcp` 443 von `VirtualNetwork` zum Service Tag `Storage` erlauben (Priorität 110), plus ausgehende Regeln für deine Backends.
Öffentlicher Zugriff	Kann erst deaktiviert werden, wenn ein private endpoint existiert. Deploye mit aktiviertem öffentlichem Zugriff und deaktiviere ihn danach.