Eine Azure Container Registry braucht 2026 mehr als nur Netzwerkschutz

In vielen Azure-Umgebungen, die ich betreue, gehört die Azure Container Registry (ACR) längst fest zum Backend für Kubernetes-Workloads, CI/CD-Pipelines und Container Apps. Bei der Absicherung hapert es trotzdem noch oft. Mal bleiben Standardkonfigurationen unangetastet und Risiken werden unterschätzt, mal gehen aktuelle Best Practices und Neuerungen im Tagesgeschäft unter. Wer eine ACR heute absichern will, muss neben der Netzwerksicherheit auch das Identitätsmanagement, den Schutz vor versehentlichem Löschen und klare Governance-Regeln im Blick haben.

Der Admin-Benutzer wird abgeschaltet und Entra ID zum Standard

Einer der Schwachpunkte, die mir am häufigsten begegnen, ist ein noch aktiver Admin-Benutzer der Registry. Seinen klassischen, statischen Zugangsschlüssel verwenden oft CI/CD-Systeme oder einzelne Entwickler. Damit öffnet man Angriffen auf Zugangsdaten eine bequeme Hintertür, und dem Stand der Technik entspricht das schon lange nicht mehr. Die Abhilfe ist schnell erledigt: den Admin-Benutzer in der Registry-Übersicht deaktivieren (Azure-Portal → Container Registries → Registry auswählen → Zugriffsschlüssel). Für den Zugriff sollten heute ausschließlich Workload-Identitäten auf Basis von Microsoft Entra ID zum Einsatz kommen. Die meisten Produktions-Deployments, vor allem mit AKS oder Azure Container Apps, sollten Managed Identities verwenden, denen man die Rolle „AcrPull“ (und bei Bedarf „AcrPush“) direkt auf der Registry zuweist. Das geht im Azure-Portal unter Zugriffssteuerung (IAM) oder mit der Azure CLI:

# Azure CLI, angemeldet als Besitzer oder User Access Administrator
az acr update --name <acr-name> --admin-enabled false
az role assignment create --assignee <managed-identity-id> --role AcrPull --scope $(az acr show --name <acr-name> --query id -o tsv)

Für CI/CD-Workflows gilt das ebenso. Wenn sich Service Principals nicht vermeiden lassen, bekommen sie nur den Scope, den sie tatsächlich brauchen. Über Scope Maps vergibt man granulare Token, etwa für einzelne Repositories oder bestimmte Aktionen. Details dazu stehen in der Dokumentation von Microsoft.

Private Endpoints ersetzen den öffentlichen Netzwerkzugriff

Mit der Premium-SKU lässt sich die ACR vollständig vom öffentlichen Azure-Netz abschotten, was inzwischen fast jede Compliance-Richtlinie verlangt. Dazu legt man im gewünschten VNet einen Private Endpoint an (Azure-Portal → Container Registry → Netzwerk → Private Endpoints) und schaltet danach den öffentlichen Netzwerkzugriff der Registry ab. Bestehende Build- und CI-Systeme sowie AKS-Cluster müssen die Registry dann aus demselben VNet oder per Peering erreichen können.

Das folgende Flussdiagramm zeigt, wie Managed Identity, Private Endpoint und Rollenzuweisung bei AKS idealerweise zusammenspielen:

flowchart TD
  DevOps["DevOps Pipeline"] --> CIUser["CI Service Principal oder MI"]
  CIUser --> Token["ACR Token (Scope Map)"]
  AKS["AKS oder Container App"] --> MI["Managed Identity"]
  MI --> AcrPull["Role: AcrPull"]
  AcrPull --> ACR["ACR (Private Endpoint)"]
  Token --> ACR

Abbildung: Zugriffswege auf eine gehärtete Azure Container Registry mit Private Endpoint und Managed Identities.

Wer mit DNS und Private Endpoints in Azure kämpft, findet Hilfe in meinem Praxisartikel über typische DNS-Fehler bei Azure Private Endpoints.

Soft Delete und Aufbewahrung schützen vor dem Verlust von Images

Oft unterschätzt wird das Risiko, dass Images versehentlich verschwinden, sei es durch fehlerhafte Skripte oder unachtsame Nutzer. Mit der Premium-SKU lassen sich für die ACR Aufbewahrungs- und Soft-Delete-Richtlinien aktivieren (Azure-Portal → Container Registry → Datenmanagement → Soft-Löschung & Aufbewahrung). Gelöschte Images kann man dann innerhalb eines festgelegten Zeitraums wiederherstellen. Für das Recovery und als Sicherheitsnetz gegen menschliche Fehler ist das ausgesprochen hilfreich.

Mein Tipp: Die Aktivierung lohnt sich auch dann, wenn das Aufbewahrungsintervall kurz wirkt. So mancher Pipeline-Fehler, bei dem „falsche“ Images entfernt wurden, ließ sich damit schon ausbügeln.

Die Funktionen sind mittlerweile so ausgereift, dass sie standardmäßig eingeschaltet gehören und nicht nur in Ausnahmefällen.

Defender for Containers scannt jedes Image auf Schwachstellen

Zur Absicherung einer Azure Container Registry gehört auch die Integration mit Defender for Containers (früher Defender for Container Registries). Sie prüft jedes neue oder aktualisierte Image automatisch auf Schwachstellen (CVEs), samt CVSS-Bewertung und konkreten Hinweisen zur Behebung. Ihr aktiviert die Integration im Azure-Portal unter Defender for Cloud → Umgebung → Container Registry → Sicherheitscenter-Einstellungen. Achtet darauf, dass die Lizenz für Defender for Containers korrekt zugewiesen ist und ihr für Auswertungen mindestens die Rolle „Security Reader“ habt.

Die gefundenen Schwachstellen gehen in den Secure Score ein und lassen sich direkt ins SOC-Playbook einbinden. Wer den Ablauf in der Praxis durchspielen möchte, findet Anregungen in den Best Practices für Defender und Container Registries.

Azure Policy setzt die Standards für alle Registries durch

In größeren Azure-Umgebungen ist Azure Policy praktisch gesetzt, und gerade bei Container Registries erreicht man schon mit wenigen Policies verbindliche Standards:

• Es dürfen nur Premium-Registries mit Private Endpoint erstellt werden
• Admin-Benutzer sind grundsätzlich deaktiviert
• Soft Delete und Retention müssen aktiv sein
• Netzwerksicherheitsstandards gelten für alle neuen Registries

Wer eigene Definitionen braucht, findet sie im Policy-Katalog des Azure-Portals unter „Definitionen“ → „Azure Container Registry“. Weist man sie auf Ebene der Management Groups zu, gelten die Regeln einheitlich im ganzen Unternehmen, und „Shadow-Registries“ mit unsicheren Einstellungen fallen früh auf.

Ohne Standardisierung bleibt die Absicherung Flickwerk

Mit „einmal einrichten und vergessen“ ist es bei der Absicherung einer Azure Container Registry längst nicht mehr getan. Die technische Basis – Admin-Benutzer weg, Entra ID überall, Private Endpoints, Soft Delete – steht nach wenigen Handgriffen. Wirkliche Sicherheit und Governance kommen aber erst mit Azure Policy und laufendem Monitoring (Defender, Log Analytics) zustande. In den letzten Monaten hat sich für mich gezeigt, dass vor allem die konsequente Durchsetzung per Policy und der identitätsbasierte Zugriff den Unterschied ausmachen. Zugleich fallen selbst erfahrene Teams bei DNS, privaten Zugriffswegen und Scope Maps oft noch in alte Muster zurück. Wer die ACR heute professionell betreibt, bekommt eine zukunftssichere und auditierbare Plattform, die sich im Alltag bewährt.