Dieser Artikel befasst sich mit der Containersicherheit in Azure Kubernetes Service (AKS), wobei der Schwerpunkt auf den früheren Phasen des Container-Lebenszyklus liegt, wo viele Sicherheitsprobleme ihren Ursprung haben.
Warum Container standardmäßig nicht sicher sind
In Entwicklungsteams gibt es eine weit verbreitete Annahme: “Wir arbeiten mit Kubernetes, also ist alles in Ordnung.” Das ist verständlich, denn Container fühlen sich isoliert an, AKS abstrahiert einen Großteil der Infrastrukturkomplexität, und Azure verwaltet die Kontrollebene. Aber Isolation ist nicht dasselbe wie Sicherheit.
Container teilen sich den Host-Kernel. Ein falsch konfigurierter Pod kann Geheimnisse aus anderen Namespaces lesen, interne Dienste erreichen, mit denen er nicht kommunizieren darf, oder als Root mit vollem Schreibzugriff auf das Dateisystem laufen. Die Angriffsfläche in einem containerisierten Workload erstreckt sich über den gesamten Lebenszyklus, von dem Moment, in dem Sie eine Dockerdatei schreiben, bis zu dem Moment, in dem ein Pod den Produktionsverkehr bedient.
Stellen Sie sich vier Phasen vor, jede mit einer eigenen Risikokategorie:
Erstellen → Registrierung → Bereitstellen → Laufzeit
Jede Stufe bringt unterschiedliche Bedrohungen mit sich. In jeder Phase gibt es auch wohlverstandene Kontrollen. Ziel ist es, sie alle durchzugehen, und zwar nicht als Checkliste für die Einhaltung der Vorschriften, sondern als praktische Karte, die zeigt, wo die Hebelwirkung liegt.
Hinweis: Die Sicherheitsvorgaben in Kubernetes sind von vornherein freizügig, da das Projekt der betrieblichen Flexibilität Vorrang vor der Absicherung gab. AKS hat dies übernommen. Die Härtung ist nicht standardmäßig aktiviert und muss konfiguriert werden.
Bildsicherheit: Die erste Verteidigungslinie
Alles beginnt mit dem Image. Ein anfälliges oder aufgeblähtes Basis-Image trägt seine Probleme bis in die Produktion hinein, unabhängig davon, was Sie auf Clusterebene tun.
Basisbild Hygiene
Die wichtigste Entscheidung ist die Wahl des Basisbildes. Je kleiner und minimaler, desto kleiner die Angriffsfläche. In Produktionsumgebungen dominieren drei Muster:
- Distroless-Images – enthalten nur Ihre Anwendung und ihre Laufzeit-Abhängigkeiten. Keine Shell, kein Paketmanager, keine unnötigen Binärdateien. Ein Angreifer, der Code ausführen kann, hat fast nichts, womit er arbeiten könnte. Google unterhält einen bekannten Satz von distroless Images für die meisten wichtigen Laufzeiten.
- Alpine-basierte Images – winzig, aber sie enthalten eine Shell und einen Paketmanager. Ein praktischer Mittelweg, wenn Sie einige Werkzeuge zur Erstellungszeit benötigen und mit etwas mehr Oberfläche leben können.
- Vollständige Betriebssystem-Images (Ubuntu, Debian) – in der Produktion vermeiden, es sei denn, Sie haben einen besonderen Grund. Jedes vorinstallierte Paket ist ein potenzielles CVE, das darauf wartet, entdeckt zu werden.
Über das Basis-Image hinaus sollten Sie mehrstufige Builds verwenden. Das bedeutet, dass Sie Ihren Build-Prozess (SDK, Compiler, Testtools) in einem Schritt durchführen und nur die kompilierte Ausgabe in ein sauberes Laufzeit-Image kopieren. Das endgültige Image sieht nie Ihre Build-Tools.
Und eine Regel, die offensichtlich klingt, aber immer wieder übersehen wird: Führen Sie Ihren Container niemals als root aus. Fügen Sie in Ihrem Dockerfile einen Nicht-Root USER hinzu. Wenn die Anwendung kompromittiert wird, hat ein Nicht-Root-Prozess deutlich weniger Möglichkeiten, sich zu bewegen.
# Stage 1: build
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app
# Stage 2: runtime only — no SDK, no build tools
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app .# Never run as root
USER 1001
ENTRYPOINT ["dotnet", "MyApp.dll"]Scannen von Bildern
Ein sauberes Image zu erstellen ist eine Sache. Zu wissen, welche CVEs in Ihren Abhängigkeiten lauern, ist eine andere. Image-Scan-Tools analysieren Schichten und Manifeste anhand bekannter Schwachstellendatenbanken – NVD, OSV, Herstellerhinweise.
Die wichtigsten Open-Source-Optionen sind hier Trivy (von Aqua Security, ausgezeichneter Allzweck-Scanner) und Grype (von Anchore, besonders stark bei SBOM-Workflows). Beide lassen sich sauber in eine CI-Pipeline einfügen und können ein Build fehlschlagen lassen, wenn kritische Schwachstellen gefunden werden. Azure Container Registry verfügt auch über ein integriertes Schwachstellen-Scanning, das von Microsoft Defender unterstützt wird. Dies ist nützlich, wenn Sie die Ergebnisse direkt im Azure-Portal ohne zusätzliche Tools anzeigen lassen möchten.
Die wichtigste Praxis: Scannen Sie bei jedem Build, nicht nur nach einem bestimmten Zeitplan. Ein CVE, das unbemerkt in einem Abhängigkeitsupdate ausgeliefert wird, ist ein Problem. Ein CVE, das die Pipeline nicht durchläuft, ist eine Aufgabe.
Register & Lieferkette
Sobald ein Abbild erstellt ist, wird es in einer Registrierung gespeichert. Die Registry ist nicht nur ein Speicher, sondern auch Teil der Vertrauensgrenze.
Azure Container Registry
ACR ist die natürliche Wahl in einer AKS-Umgebung. Es ist direkt mit AKS durch verwaltete Identität integriert, was bedeutet, dass Ihr Cluster Bilder ohne Anmeldedaten in Manifesten abrufen kann. Aktivieren Sie private Endpunkte, um sicherzustellen, dass der Datenverkehr zwischen ACR und AKS niemals das öffentliche Internet durchläuft.
Nicht mehr verwenden :latest
Das :latest Tag ist ein Anti-Muster in der Produktion. Es ist veränderlich, das Bild, auf das es verweist, kann sich zwischen Implementierungen ändern, ohne dass eine sichtbare Änderung in Ihren Manifesten erfolgt. Verknüpfen Sie Bilder mit einem bestimmten Digest (dem unveränderlichen SHA256-Hash des Bildinhalts). Dadurch wird sichergestellt, dass das, was Sie getestet haben, auch wirklich ausgeführt wird.
image: myregistry.azurecr.io/myapp@sha256:a3f2...Bildunterzeichnung
Das Abrufen eines Abbilds aus Ihrer Registrierung garantiert nicht, dass es während der Übertragung nicht manipuliert wurde oder dass die Registrierung selbst nicht kompromittiert wurde. Das Signieren von Images schafft hier Abhilfe. Tools wie Notation (der CNCF-Standard) oder Cosign (von Sigstore) ermöglichen es Ihnen, Images zum Zeitpunkt der Erstellung kryptografisch zu signieren und die Signaturen zum Zeitpunkt der Bereitstellung zu überprüfen. AKS kann mit Zulassungssteuerungen (wie Ratify) konfiguriert werden, um unsignierte oder nicht verifizierte Images zurückzuweisen, bevor sie überhaupt gestartet werden.
Software-Stückliste (SBOM)
Ein SBOM ist ein maschinenlesbares Inventar von allem, was sich in Ihrem Image befindet, einschließlich jeder Bibliothek, jeder Version und jeder Lizenz. Es klingt wie ein Compliance-Artefakt, ist aber in der Praxis wirklich nützlich: Wenn ein neues CVE auftaucht, können Sie sofort Ihre SBOMs abfragen, um zu wissen, welche Dienste betroffen sind, anstatt Abhängigkeiten manuell zu verfolgen. Trivy und Syft können beide SBOMs als Teil einer Standard-CI-Pipeline generieren.
In dieser Phase wird die Grundlage für den Prozess geschaffen: Die Teams erstellen, scannen und speichern das Bild in einem kontrollierten Register.
Die nächste Ebene von Kontrollen gilt für die Bereitstellung und die Laufzeit, wo die Konfiguration und das Laufzeitverhalten die effektive Sicherheitslage definieren.
Dies umfasst Kontrollen wie Sicherheitskontexte, Netzwerkrichtlinien, Laufzeiterkennung und Geheimhaltungsmanagement, die im nächsten Teil behandelt werden.