Zum Inhalt

Build-Agent-Zugriff auf Spokes

pipelines, die auf private Ressourcen deployen, brauchen Agents innerhalb des Netzwerks. Diese Seite beschreibt einen Standardweg, diesen Agents Netzwerkzugriff auf die Spokes zu geben, ohne pro pipeline eine Firewall-Anfrage zu stellen, und die Risiken, die damit einhergehen.

Zwei Arten von Agents

Die eigenen Job runners der Plattform (Managed DevOps Pool, Container Apps) deployen den hub und die Spokes. Ist deployment_agents_private_network_range gesetzt, legt die Plattform dafür eine eigene Rule Collection Group an (Priorität 8999). Diese Seite behandelt die Agents der Workload-Teams, die Workloads in Spokes deployen. Ob die Plattform gemeinsame Agents anbietet, ist plattformspezifisch: Siehe Build Agents im Netzwerk und Shared Services.

Das Problem

Agents leben in einem eigenen Spoke. Standardmäßig blockiert die Firewall ihren Traffic zu den anderen Spokes. Die Folgen:

  • Jede pipeline braucht eine manuelle Firewall-Anfrage für die Ports, die sie nutzt.
  • Deployments warten auf Genehmigungen.
  • Der Zugriff unterscheidet sich zwischen Umgebungen, sodass pipelines in einer Umgebung scheitern und in einer anderen funktionieren.
  • Das Problem wächst mit jedem Workload, der onboardet wird.

Empfehlung

Lege unidirektionale Regeln von den Agents zu den Workload-Spokes an, mit IP groups auf beiden Seiten:

  1. Lege das Agent-Subnet in eine IP group (zum Beispiel ipgrp-selfhosted-agents).
  2. Lege die Spokes nach Umgebungsklasse in IP groups, damit du das Risiko unterschiedlich behandeln kannst:
    • eine Gruppe für Entwicklungs- und Test-Spokes,
    • eine Gruppe für Abnahme- und Produktions-Spokes. Nimm alle Regionen auf.
  3. Erlaube nur die Ports, die Deployments brauchen. Typisch: HTTPS und HTTP, SSH und die Datenbankports, die deine Teams nutzen. Entscheide das pro Klasse.
  4. Lege zwei Rule Collections an, eine für Dev und Test, eine für Abnahme und Produktion, in zwei Dateien im globalen Firewall-Ordner (damit sie für jede Region gelten). Benenne die Dateien, Collections und Regeln nach einem wiedererkennbaren Muster, zum Beispiel global_build-agent-access-devtest.json und eine Regel AllowBuildAgent_FromAgentIPGroup_ToDevTestSpokes_HTTPS.
  5. Wende sie auf jeder regionalen Firewall an, damit die Agents nach einem Failover funktionieren.
  6. Folge deiner Regelorganisation: Lege die Dateien im globalen funktionalen Bereich der Prioritäten ab.

Beispiel: containerbasierte Agents in einem Spoke-Subnet

Eine zweite Art von Agent Pool läuft auf Azure Container Apps jobs, in einem Subnet eines Spokes (siehe Container-Agent-Pool). Es gilt dieselbe Empfehlung, und für die Firewall sind diese Entscheidungen nötig:

Thema Entscheidung im Beispiel
Quelle Das CIDR des Container-Apps-Subnets kommt in die Agent-IP-Gruppe. Eine eigene Regel ist nicht nötig, wenn für diese Gruppe schon eine Regel existiert.
Ausgehende Regel Eine Regel von der Agent-IP-Gruppe erlaubt TCP 443 zu jedem Ziel (*). Die Agents brauchen den Anmelde-Endpunkt von Microsoft Entra, die Container Registry, den Azure-DevOps-Service und den Host für den Agent-Download sowie Blob Storage.
Port 80 Nicht erlaubt. Das Container-Image wird nur mit HTTPS-Downloads gebaut (kein apt-get).
Service Endpoints (optional) Microsoft.ContainerRegistry und Microsoft.Storage am Subnet leiten Image-Pulls und Blob-Verkehr über das Azure-Backbone und an der Firewall vorbei. Das senkt Kosten und Pull-Zeit und ist nicht erforderlich.
Reihenfolge der Arbeit Deploye die Firewall-Änderung vor dem Agent Pool. Die Container-Apps-Umgebung testet den Registry-Zugriff beim Erstellen eines jobs, deshalb schlägt das Deployment des Pools fehl, wenn das Subnet nicht erlaubt ist.

Prüfe die IP-Gruppe so, wie sie in Azure deployt ist, und nicht nur im Konfigurations-Repository, wenn Pulls mit ImagePullFailure scheitern.

Ein job auf diesem Pool wird im Beispiel nach 30 Minuten beendet, und das Image hat keinen Docker-Daemon. Sag das, wenn du Teams Zugriff gibst, und behalte einen VM-basierten Pool für alles, was nicht passt.

Risiken und wie du sie begrenzt

Risiko Begrenzen mit
Die Angriffsfläche vom Agent-Spoke zu allen Spokes wächst Behandle die Agents als hochprivilegiert. Aktualisiere das Image regelmäßig.
Manche Workloads bekommen mehr Zugriff als nötig Nutze getrennte Klassen für Nicht-Produktion und Produktion und öffne zur Produktion hin weniger Ports
Ein kompromittierter Agent könnte die Produktion erreichen Nutze einen separaten Agent Pool für Deployments in die Produktion und halte Agents kurzlebig
Zugangsdaten bleiben auf dem Agent Baue den Agent nach jedem Job ab, damit Secrets und Zertifikate nicht zurückbleiben können
Ein Team nutzt die Zugangsdaten eines anderen Teams Eine pipeline muss vom besitzenden Team autorisiert sein, eine Service Connection oder einen Service Principal zu nutzen. Der Agent handelt nur mit der Identität, die die pipeline liefert.
Komplexe Deployments brauchen zusätzliche Ports Die Standardregeln decken sie nicht ab. Diese Teams beantragen eine zusätzliche Regel.

Ein Agent-Pool-Design, das zu diesen Grenzen passt: ein Scale Set, das auf einem regelmäßig neu gebauten Image aufsetzt (zum Beispiel wöchentlich), Agents, die nach jeder Nutzung entfernt werden, einige Agents in Bereitschaft für schnelle Starts, eine maximale Anzahl von Maschinen und eine Firewallregel, die nur den Traffic zu Azure-Ressourcen erlaubt (HTTPS und die Datenbankprotokolle). Schlägt der wöchentliche Image-Build fehl, funktionieren die vorhandenen Agents weiter; die Ursache ist oft eine Änderung im Upstream-Image-Repository.

Konsequenzen

Positiv:

  • Teams beantragen keine Regeln mehr pro pipeline,
  • Deployments sind schneller und über Umgebungen hinweg konsistent,
  • die Regeln folgen der Organisation, die in Organisation der Firewallregeln beschrieben ist.

Negativ:

  • der Agent-Spoke kann alle Spokes erreichen, daher wird die Sicherheit der Agents kritisch,
  • Workloads sind möglicherweise auf mehr Ports erreichbar, als streng nötig.