Ga naar inhoud

Toegang van build agents tot spokes

Pipelines die naar private resources deployen, hebben agents binnen het netwerk nodig. Deze pagina beschrijft een standaardmanier om die agents netwerktoegang tot de spokes te geven zonder een firewallaanvraag per pipeline, en de risico's die daarbij horen.

Twee soorten agents

De eigen job runners van het platform (Managed DevOps Pool, Container Apps) deployen de hub en de spokes. Als deployment_agents_private_network_range is ingesteld, maakt het platform er een eigen rule collection group voor aan (prioriteit 8999). Deze pagina gaat over de agents van workload teams, die workloads in spokes deployen. Of het platform gedeelde agents aanbiedt, verschilt per platform: zie Build agents in het netwerk en Shared services.

Het probleem

Agents staan in een eigen spoke. Standaard blokkeert de firewall hun verkeer naar de andere spokes. Daardoor:

  • heeft elke pipeline een handmatige firewallaanvraag nodig voor de poorten die ze gebruikt,
  • wachten deployments op goedkeuringen,
  • verschilt de toegang per omgeving, waardoor pipelines in de ene omgeving falen en in de andere werken,
  • groeit het probleem met elke workload die wordt onboarded.

Richtlijn

Maak eenrichtingsregels van de agents naar de workload-spokes, met IP groups aan beide kanten:

  1. Zet het agent-subnet in een IP group (bijvoorbeeld ipgrp-selfhosted-agents).
  2. Zet de spokes in IP groups per omgevingsklasse, zodat je risico's verschillend kunt behandelen:
    • één groep voor development- en testspokes,
    • één groep voor acceptatie- en productiespokes. Neem alle regio's mee.
  3. Sta alleen de poorten toe die deployments nodig hebben. Typisch: HTTPS en HTTP, SSH en de databasepoorten die je teams gebruiken. Besluit per klasse.
  4. Maak twee rule collections, één voor dev en test en één voor acceptatie en productie, in twee bestanden in de globale firewallmap (zodat ze voor elke regio gelden). Geef de bestanden, collections en regels namen volgens een herkenbaar patroon, bijvoorbeeld global_build-agent-access-devtest.json en een regel AllowBuildAgent_FromAgentIPGroup_ToDevTestSpokes_HTTPS.
  5. Pas ze toe op elke regionale firewall, zodat agents ook na een failover werken.
  6. Volg je regelorganisatie: plaats de bestanden in het globale functionele prioriteitsbereik.

Risico's en hoe je ze beperkt

Risico Beperk het met
Het aanvalsoppervlak van de agent-spoke naar alle spokes groeit Behandel de agents als zeer bevoorrecht. Update de image regelmatig.
Sommige workloads krijgen meer toegang dan nodig Gebruik aparte klassen voor niet-productie en productie, en open minder poorten richting productie
Een gecompromitteerde agent kan productie bereiken Gebruik een aparte agent pool voor deployments naar productie en houd agents kortlevend
Credentials blijven op de agent achter Breek de agent na elke job af, zodat secrets en certificaten niet achterblijven
Een team gebruikt de credentials van een ander team Een pipeline moet door het eigenaarsteam gemachtigd zijn om een service connection of service principal te gebruiken. De agent handelt alleen met de identiteit die de pipeline aanlevert.
Complexe deployments hebben extra poorten nodig De standaardregels dekken die niet. Die teams vragen een aanvullende regel aan.

Een agent pool-ontwerp dat binnen deze grenzen past: een scale set die bouwt op een regelmatig herbouwde image (bijvoorbeeld wekelijks), agents die na elk gebruik worden verwijderd, een paar agents stand-by om snel te starten, een maximumaantal machines en een firewallregel die alleen het verkeer naar Azure-resources toestaat (HTTPS en de databaseprotocollen). Mislukt de wekelijkse image-build, dan blijven de bestaande agents werken; de oorzaak is vaak een wijziging in de upstream image-repository.

Voorbeeld: op containers gebaseerde agents in een spoke-subnet

Een tweede soort agent pool draait op Azure Container Apps-jobs, in een subnet van een spoke (zie Container agent pool). Dezelfde richtlijnen gelden, en voor de firewall zijn deze beslissingen nodig:

Onderwerp Beslissing in het voorbeeld
Bron De CIDR van het Container Apps-subnet wordt toegevoegd aan de IP group van de agents. Er is geen aparte regel nodig als er al een regel voor die groep bestaat.
Uitgaande regel Eén regel van de IP group van de agents staat TCP 443 toe naar elke bestemming (*). De agents hebben het Microsoft Entra-aanmeldeindpunt, de container registry, de Azure DevOps-service en de downloadhost van de agent nodig, plus blob storage.
Poort 80 Niet toegestaan. De containerimage wordt alleen met HTTPS-downloads gebouwd (geen apt-get).
Service endpoints (optioneel) Microsoft.ContainerRegistry en Microsoft.Storage op het subnet laten image pulls en blobverkeer over de Azure-backbone en langs de firewall lopen. Dat verlaagt kosten en pull-tijd, en is niet verplicht.
Volgorde van het werk Deploy de firewallwijziging voor de agent pool. De Container Apps-omgeving test de toegang tot de registry wanneer een job wordt aangemaakt, dus de deployment van de pool mislukt als het subnet niet is toegestaan.

Controleer de IP group zoals die in Azure is uitgerold, en niet alleen in de configuratierepository, als pulls mislukken met ImagePullFailure.

Een job op deze pool wordt in het voorbeeld na 30 minuten gestopt, en de image heeft geen Docker-daemon. Zeg dat erbij als je teams toegang geeft, en houd een pool op basis van VM's voor wat hier niet in past.

Gevolgen

Positief:

  • teams vragen niet langer regels per pipeline aan,
  • deployments zijn sneller en consistent over omgevingen,
  • de regels volgen de organisatie die is beschreven in Organisatie van firewallregels.

Negatief:

  • de agent-spoke kan alle spokes bereiken, dus de beveiliging van agents wordt cruciaal,
  • workloads kunnen op meer poorten bereikbaar zijn dan strikt nodig.