Shared services: gateway, registry, packages, API Management, build agents¶

Een platform biedt vaak shared services naast je spoke. Welke er zijn, hangt af van je platform. Deze pagina beschrijft wat ze doen en hoe teams ze gebruiken. Vraag je platformteam welke beschikbaar zijn. De kant van het platformteam (wat er is gedeployd en hoe) staat op Shared services: wat er is gedeployd en hoe. Wie het platformteam is, hangt af van je beheermodel.

Service	Wat het doet	MCP-productondersteuning
Application Gateway + WAF	Publiceert je webapp vanaf internet, met TLS-terminatie en web application firewall	Hubcomponent. Regels zijn standaardwijzigingen: Application Gateway
Shared Azure Container Registry	Centrale registry met pull-through cache voor publieke registries	`extensions.acr` in de spoke-JSON (shared service in `mcp.json`), zie Spoke-extensies
Shared API Management	Centraal API's, producten en subscriptions publiceren	`extensions.apim` in de spoke-JSON, zie Spoke-extensies. Zie ook API Management (shared).
Service Bus / Event Hub	Gedeelde messaging	`extensions.servicebus` / `extensions.eventhub`, zie Spoke-extensies, Messaging en Bekende problemen
Communication Services	E-mail (en andere communicatie) versturen vanuit je applicatie	Toegang via een groep die het platformteam beheert. Nog geen spoke-extensie. Zie Communication Services.
Package feeds (Azure DevOps Artifacts)	Private en gecachete NuGet-, npm-, Maven- en Python-packages	Azure DevOps-functionaliteit. Geen onderdeel van de platformcode.
Build agents	Pipeline-agents binnen het netwerk, om private resources te bereiken	Platformspecifiek. Geen onderdeel van het MCP-product. Zie Build agents. Platformteam: Container agent pool.
Dependency-updates (Renovate)	Pull requests voor verouderde dependencies	Platformspecifiek

Spoke-extensies: koppel je aan een shared service¶

Een spoke-extensie koppelt je spoke aan een shared service op het moment dat de spoke wordt gedeployd. De deployment geeft je groepen de juiste toegang en configureert de shared service voor je, zodat je hem direct na oplevering van de spoke kunt gebruiken. Je hoeft niet op een aparte wijziging te wachten.

Er zijn extensies voor deze shared services (als je platform ze draait):

Extensie (`extensions.<name>` in de spoke-JSON)	Wat je krijgt	Jouw toegang
`apim`	Toegang tot de shared API Management. In het centrale model op de hele instance, in het decentrale model op je eigen workspace.	Owners en Contributors kunnen API's wijzigen. Readers kunnen lezen.
`acr`	Toegang tot de shared container registry via twee groepen en twee managed identities van je spoke, één om te pullen en één om images te pushen.	Je teamgroepen krijgen via de extensie geen registrytoegang. Gebruik de managed identities in je pipelines en vraag het platformteam om andere identiteiten toe te voegen. Je kunt geen images verwijderen.
`eventhub`	Je eigen event hub in de shared namespace.	Owners krijgen data- en beheerrechten, Contributors kunnen bijdragen, Readers kunnen lezen.
`servicebus`	Toegang tot de shared Service Bus namespace.	Owners en Contributors kunnen verzenden en ontvangen. Readers kunnen de namespace lezen.
Communication Services	Momenteel niet beschikbaar.

De exacte rollen staan in Spoke-extensies.

Hoe je er een krijgt. Vraag je platformteam (Hoe je een wijziging aanvraagt) om enabled op true te zetten voor de extensie in je spoke-bestand (Spoke-JSON). Het gaat in bij de volgende spoke-deployment. Vertel het platformteam welke service je nodig hebt, in welke omgevingen en wie in je team hem gaat gebruiken.

Niet elke extensie is op elk platform beschikbaar

De extensies hebben de shared service en de bijbehorende instellingen in de platformconfiguratie nodig. Vraag je platformteam welke er zijn en in welke regio's. Sommige extensievelden kunnen nog niet worden ingesteld (Bekende problemen).

Hoe je een shared service bereikt¶

In het referentieontwerp zijn de shared services op dezelfde manier beveiligd:

Geen publieke toegang. Services zijn bereikbaar via een private endpoint in de shared services spoke. Je verkeer loopt via de hub firewall. Als een verbinding wordt geblokkeerd, vraag dan een firewallregel aan.
Geen keys. Lokale authenticatie (shared keys, SAS) staat uit op Service Bus en Event Hubs, en bij de registry staat de admin user uit. Je meldt je aan met Microsoft Entra ID, met een managed identity voor applicaties en pipelines.
Toegang via groepen. Rollen worden aan Entra ID-groepen gegeven (en, voor de registry, aan managed identities). Vraag voor toegang lidmaatschap van de juiste groep aan, of gebruik een spoke-extensie.
Private DNS. Gebruik de gewone hostnaam van de service. Die moet vanuit je spoke naar het private adres resolven.

Dit zijn eigenschappen van het referentieontwerp. Vraag je platformteam wat op jouw platform geldt.

Een webapp publiceren (Application Gateway)¶

Randvoorwaarden: de security officer heeft de blootstelling goedgekeurd en je applicatie voldoet aan je securitystandaarden.

Doe een aanvraag met:

applicatienaam en omgeving,
backend-adres (IP of FQDN) en servicepoort,
de externe URL (bijvoorbeeld myapp.example.com) en het listenerprotocol,
het TLS-certificaat (voor HTTPS) of wensen voor een custom domain,
een health probe (pad, protocol, interval),
een securitycontactpersoon.

Opmerkingen:

HTTPS is de standaard. Een HTTP-listener verwijst normaal gesproken door naar HTTPS.
Meerdere apps kunnen achter één URL staan met path-based routing.
De prioriteit van routingregels is uniek per gateway. Een lager nummer wordt eerst geëvalueerd.
Je platform kan self-service bieden: je bewerkt een JSON-bestand voor je app in de map met gateway-definities en opent een pull request, die het platformteam reviewt en deployt. Vraag of dit van toepassing is.
Om geblokkeerde requests te onderzoeken, zie Application Gateway-logs.

Een legitieme request wordt door de WAF geblokkeerd. De WAF blokkeert requests die overeenkomen met zijn managed rules (bijvoorbeeld de OWASP-regelset), ook als je applicatie in orde is. Vraag een uitzondering of exclusion aan en lever het bewijs mee:

Lever aan	Waar je het vindt
De rule-ID en de rulegroep	De logregel van de firewall (Application Gateway-logs)
De URI, en het argument of de header die de regel triggert	Dezelfde logregel of je eigen request
Waarom de request legitiem is	Je applicatieteam
Hoe smal de uitzondering kan zijn: één headerwaarde, één clientadres, één URI	Je applicatieteam

Security keurt de uitzondering goed. Het platformteam voegt een zo smal mogelijke regel toe en houdt een lijst bij van alle uitzonderingen. Er gelden limieten op het aantal en op het soort waarden (bijvoorbeeld alleen losse IPv4-adressen bij een adresmatch), die het platformteam controleert (WAF-uitzonderingen). Een uitgeschakelde regel of een brede uitzondering wordt normaal geweigerd.

Containers: shared Azure Container Registry¶

Een shared registry in de hub kan publieke registries cachen (Microsoft Container Registry, Docker Hub, Quay), zodat builds sneller, goedkoper en onafhankelijk van internet zijn.

Oorspronkelijke image	Via de 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`

De registrynaam, de cacheregels en de rollen zijn platformspecifiek, en een registry biedt de bovenstaande cachepaden alleen als het platformteam de cacheregels heeft ingesteld. Een typische opzet:

In het referentieontwerp is de registry Premium, alleen bereikbaar via een private endpoint, met de admin user en anonymous pull uitgeschakeld, en versleuteld met een customer-managed key.
Met de acr-extensie loopt toegang via groepen: AcrPull en AcrPush worden eenmalig toegewezen aan de hoofdgroepen van de registry, en je spoke krijgt van elk een subgroep, met een managed identity per subgroep. Leden die het platformteam aan de subgroepen toevoegt, blijven behouden. Hoe je eigen identiteiten (App Service, AKS, Container Apps) AcrPull krijgen, is platformspecifiek. Vraag het na.
De firewall staat toegang vanaf alle spokes al toe.
Gebruik managed identities om te pullen. Gebruik geen admin keys.

Packages: Azure DevOps-feeds¶

Gebruik de feed van de organisatie, zodat dependencies gecachet, gescand en controleerbaar zijn.

Authenticeer in een pipeline met de ingebouwde tasks (NuGetAuthenticate, npmAuthenticate, PipAuthenticate) en gebruik de feed als bron. De build service-identiteit van de pipeline authenticeert binnen dezelfde organisatie.
Publieke URL's worden standaard door de firewall geblokkeerd. Gebruik de upstream sources van de feed in plaats van regels aan te vragen.

Build agents in het netwerk¶

Private resources (private endpoints, VM's zonder publiek IP) zijn alleen bereikbaar vanuit het netwerk. Als het platform gedeelde agent pools biedt, gebruik die dan voor deployments naar je spoke:

Pooltype	Geschikt voor	Beperking
VM-gebaseerde pool	Alles, inclusief installaties als root (Docker CLI)	Start langzamer
Containergebaseerde pool	Snelle builds, één verse container per job	Geen root, dus geen Docker daemon. Gebruik `dotnet publish` container support, Podman rootless, Kaniko of `ko` om images te bouwen. De voorbeeldpool stopt een job na 30 minuten en heeft een cold start van enkele minuten (Build agents).

De poolnamen en hoe je toegang krijgt zijn platformspecifiek. Rechten komen van de service connection die je pipeline gebruikt. Vraag je platformteam om toegang. Hoe zo'n pool meestal is opgebouwd, hoe je hem gebruikt en wat je doet als de OS-image verandert: Build agents. Aanbevolen Azure DevOps-instellingen: Azure DevOps.

Messaging: Service Bus en Event Hubs¶

Voor het Integration Platform (queues en topics uit JSON-bestanden, groepen per entity, Event Hubs en het ontwerp van API Management) zie Integration Platform, Service Bus en Shared services van het Integration Platform.

Als je platform gedeelde messaging draait, krijg je toegang tot een gedeelde namespace, niet tot je eigen namespace. In het referentieontwerp:

	Service Bus	Event Hubs
Wat wordt gedeeld	Eén namespace (Premium SKU, private endpoint, customer-managed key optioneel). Queues en topics worden niet door de shared services-code aangemaakt.	Eén namespace met één of meer event hubs
Aanmelden	Alleen Microsoft Entra ID	Alleen Microsoft Entra ID
Toegang	Via de spoke-extensie, of via een contributors-groep op de namespace	Via de spoke-extensie. Per event hub is er een sender-groep en een receiver-groep.

Gebruik een managed identity in je applicatie en geef die de datarollen (sender, receiver) via de groepen. Vraag je platformteam hoe je een event hub of queue laat aanmaken, en wat de instellingen voor naamgeving en retentie zijn. Het gebruik van deze services als onderdeel van een integratieoplossing staat beschreven in het Integration platform.

Communication Services¶

Als je platform Communication Services draait, kun je vanuit je applicatie e-mail versturen via een gedeelde Communication Services- en Email Communication Services-resource. In het referentieontwerp:

E-mail kan worden verstuurd vanaf een Azure-managed domain (als het platformteam dat heeft ingeschakeld), of vanaf een customer-managed domain dat het platformteam aan de resource toevoegt. Vraag welke afzenderdomeinen er zijn of vraag een nieuw aan.
Toegang loopt via een contributors-groep van het platformteam. Voor deze service is er nog geen spoke-extensie.
Delivery logs (verzenden, status, engagement) gaan naar de Log Analytics workspace van de shared services spoke.

Vraag je platformteam om toegang en om het afzenderdomein.

API Management (shared)¶

Als je platform een shared APIM biedt, publiceer je een API door die te beschrijven (naam, path, backend service_url, OpenAPI- bestand, producten, subscriptions), via een pull request naar de API-definities van het platform of via een aanvraag. Commit geen subscription keys: verwijs in plaats daarvan naar Key Vault-secrets. In het referentieontwerp is de gedeelde instance privé (een intern netwerk of een private endpoint), staat het developer portal uit tenzij het platformteam het inschakelt (aanmelden is dan verplicht), en gaat telemetrie naar Application Insights, die een Monitoring Reader-groep kan lezen. Het gebruik van API Management als onderdeel van een integratieoplossing staat beschreven in het Integration platform.

Je eigen API Management-instance in een spoke¶

Als je API Management in je eigen spoke uitrolt, vraagt het netwerk om aandacht, omdat spoke-verkeer via de hub firewall loopt en je NSG's en route tables niet zelf kunt wijzigen (Beperkingen). Vraag de wijzigingen aan via een wijzigingsverzoek.

Een veelgebruikt veilig ontwerp is een referentiearchitectuur met API Management in internal mode achter een Application Gateway met WAF:

De Application Gateway heeft het publieke IP-adres en publiceert de API's op een custom domain, in een eigen subnet.
API Management (Premium) staat in een apart subnet, in internal mode, en is niet rechtstreeks bereikbaar vanaf internet.
Private endpoints verbinden API Management met back-ends die alleen naar het virtuele netwerk zijn blootgesteld.
Logs en telemetrie gaan naar Log Analytics en Application Insights.

DNS. In internal mode neem je je eigen DNS mee. Registreer een custom domain op de API Management-instance: die accepteert alleen requests waarvan de host header overeenkomt met het standaard gateway-domein of een geconfigureerd custom domain. Hetzelfde custom domain kan aan meer dan één instance worden toegewezen, zodat je van instance kunt wisselen door een DNS-record te wijzigen. Clients moeten het private IP-adres van API Management via het netwerk bereiken, wat een firewallregel vereist (Firewallregels).

Klassieke tiers. Omdat al het verkeer via de hub firewall wordt geforceerd, voeg je toe:

Onderdeel	Wat
User defined route	`0.0.0.0/0` naar de firewall (next hop virtual appliance), en de service tag `ApiManagement` met next hop Internet. Zonder de tweede route wordt het managementverkeer niet teruggekoppeld naar zijn bronadressen en wordt het management-endpoint onbereikbaar.
Service endpoints op het subnet	Azure SQL, Azure Storage, Azure Event Hubs, Azure Key Vault
NSG	De regels voor internal mode uit de Microsoft Learn-handleiding. Inkomend managementverkeer op poort 3443 alleen vanaf de service tag `ApiManagement`.

v2 tiers. Deze hebben beperkingen ten opzichte van de klassieke tiers: controleer de beschikbaarheid van functies.

Onderdeel	Wat
Subnet	Wordt door slechts één API Management-instance gebruikt. Minimaal een `/27`, een `/24` aanbevolen zodat het kan schalen. Gedelegeerd aan `Microsoft.Web/serverFarms`. De deploying identity heeft `Microsoft.Network/virtualNetworks/read` en `Microsoft.Network/virtualNetworks/subnets/join/action` nodig.
NSG	Verplicht. Minimaal: sta uitgaand `Tcp` 443 toe van `VirtualNetwork` naar de service tag `Storage` (prioriteit 110), plus uitgaande regels voor je back-ends.
Public access	Kan pas worden uitgeschakeld nadat er een private endpoint bestaat. Deploy met public access ingeschakeld en schakel het daarna uit.