Sicherheit in Azure Kubernetes Service (AKS): Worauf es wirklich ankommt

Container haben die Art verändert, wie Software ausgeliefert wird: portabel, ressourceneffizient, schnell skalierbar und ideal für Microservices. Kubernetes orchestriert diese Container im Maßstab und Azure Kubernetes Service (AKS) nimmt Ihnen den Betrieb der Steuerungsebene ab. Microsoft verwaltet die Control Plane, Sie verwalten die Nodes und alles, was darauf läuft.

Genau in dieser Aufteilung liegt das Missverständnis: AKS reduziert den Betriebsaufwand, nicht aber Ihre Verantwortung für die Sicherheit des Clusters. Die folgenden Bereiche entscheiden in der Praxis darüber, ob ein AKS-Cluster hält.

Wo die Verantwortungsgrenze verläuft

Bevor es um Einstellungen geht, lohnt die nüchterne Aufteilung. Sie erklärt, warum ein „managed“ Kubernetes trotzdem Arbeit macht.

Die Zeilen, in denen Microsoft nichts beiträgt, sind die, in denen reale Vorfälle entstehen. Das ist dasselbe Muster wie bei Object Storage, wo nicht die Plattform versagt, sondern die Konfiguration: siehe S3 Bucket Security.

1. Zugriff auf die Control Plane absichern

• Entra ID (Azure AD) für die Authentifizierung integrieren: keine lokalen Cluster-Credentials
• Role-Based Access Control (RBAC) konsequent nach dem Least-Privilege-Prinzip konfigurieren
• TLS-Verschlüsselung für die gesamte Kommunikation erzwingen
• Den Zugriff auf den API-Server auf autorisierte IP-Bereiche beschränken (authorized IP ranges / privater Cluster)

Zwei Punkte verdienen eine Erläuterung.

Lokale Konto-Credentials sind der stille Umweg. Ein Cluster kann so konfiguriert sein, dass neben Entra ID weiterhin ein lokales Admin-Konto funktioniert. Damit existiert ein Zugang, der weder Conditional Access noch MFA noch zentralem Entzug unterliegt. Wer Entra ID einführt, sollte den lokalen Weg im selben Schritt deaktivieren, sonst ist die Einführung eine Ergänzung statt einer Ablösung.

Privater Cluster ist wirksam, aber nicht kostenlos. Ein nicht öffentlich erreichbarer API-Server nimmt einen ganzen Angriffsweg vom Tisch. Er verlangt aber Netzanbindung für Build-Agents, Verwaltungswerkzeuge und Notfallzugriffe. Wer das nicht vorher plant, baut sich Ausnahmen, die den Gewinn wieder auffressen. Wo ein privater Cluster nicht in Frage kommt, sind autorisierte IP-Bereiche das Minimum.

2. Worker Nodes härten

• Betriebssystem-Updates für Linux-Nodes automatisiert und zeitnah einspielen
• Standard-VM-Schutz anwenden: Azure Policy, Firewalls, Endpoint-Schutz
• Windows-Nodes regelmäßig patchen. Sie werden gern vergessen

Bei Nodes gilt eine Besonderheit gegenüber klassischen Servern: Sie sollten nicht gepflegt, sondern ersetzt werden. Node-Image-Upgrades tauschen die Knoten gegen frische Instanzen aus, statt Pakete auf laufenden Systemen nachzuziehen. Das beseitigt den Konfigurations-Drift, der sich sonst über Monate ansammelt, und macht den Aktualisierungsstand reproduzierbar.

Daraus folgt der zweite Grundsatz: kein interaktiver Zugang zu Nodes. Wer sich per SSH auf einen Knoten verbindet, um „kurz etwas zu prüfen“, erzeugt genau den Zustand, den das Ersetzungsmodell verhindern soll. Diagnose gehört in Protokolle und Metriken, nicht auf die Kommandozeile des Knotens.

Wie sich Aktualisierungsstände über verteilte Systeme hinweg überhaupt zuverlässig nachhalten lassen, steht in Cloud Patch Management.

3. Pods und Container absichern

• Resource Limits setzen, damit ein kompromittierter Pod nicht die Ressourcen des gesamten Nodes an sich reißt
• Container-Images aus vertrauenswürdigen Quellen beziehen und auf Schwachstellen scannen: idealerweise schon in der CI/CD-Pipeline, nicht erst zur Laufzeit
• Pod Security Standards durchsetzen; privilegierte Container vermeiden

Zu den Pod Security Standards: Die früheren PodSecurityPolicies wurden mit Kubernetes 1.25 entfernt. An ihre Stelle tritt Pod Security Admission mit drei Stufen, privileged, baseline und restricted, die je Namespace gesetzt werden. Ein sinnvoller Einstieg ist, restricted zunächst im Warn- und Audit-Modus zu aktivieren: Sie sehen, welche Workloads durchfallen würden, ohne den Betrieb zu unterbrechen.

Was ein restriktives Profil praktisch bedeutet: kein privilegierter Modus, keine Host-Namespaces, kein Schreibzugriff auf das Root-Dateisystem des Containers, Ausführung als Nicht-Root-Benutzer, Linux-Capabilities auf das Nötige reduziert. Jede dieser Einschränkungen verkleinert das, was ein Angreifer nach einer erfolgreichen Ausführung im Container überhaupt tun kann.

Zum Image-Scanning: Es gehört in die Pipeline, weil ein Fund dort noch eine Entscheidung ist und zur Laufzeit nur noch ein Alarm. Ergänzen Sie es um eine Regel, die nur Images aus der eigenen Registry zulässt. Ohne diese Regel bleibt das Scanning eine Empfehlung, die sich mit einer Zeile im Manifest umgehen lässt.

Ein Scanner findet dabei bekannte Schwachstellen in Paketen, nicht aber fehlerhafte Berechtigungen oder Logikfehler. Wo diese Grenze verläuft, ist in Schwachstellenscan: Was er leistet beschrieben.

4. Netzwerk segmentieren

• Bewusst zwischen den Netzwerkmodellen (kubenet vs. Azure CNI) wählen
• Network Policies definieren, um Ost-West-Verkehr zwischen Pods zu beschränken
• Eine Web Application Firewall vorschalten und Cluster-Verbindungen absichern

Der wichtigste Satz zu diesem Abschnitt: Kubernetes erlaubt standardmäßig jede Verbindung zwischen allen Pods. Ohne Network Policies ist ein Cluster ein flaches Netz. Ein kompromittierter Pod in einer unwichtigen Anwendung erreicht damit jede andere Anwendung im Cluster, einschließlich Datenbanken und internen Diensten.

Der übliche Einstieg ist eine Default-Deny-Regel je Namespace, gefolgt von expliziten Freigaben für die Verbindungen, die tatsächlich gebraucht werden. Das ist Arbeit, aber es ist die Maßnahme, die aus einer Kompromittierung einen begrenzten Vorfall statt eines Clusterweiten macht.

Ebenso wichtig und häufig übersehen: ausgehender Verkehr. Ein Cluster, der beliebig ins Internet telefonieren darf, erleichtert sowohl den Nachschub von Werkzeugen als auch den Datenabfluss. Kontrollierte Egress-Pfade sind kein Luxus.

5. Identitäten und Secrets

Dieser Bereich fehlt in vielen Härtungs-Checklisten und verursacht überproportional viele Befunde.

• Workload Identity statt hinterlegter Zugangsdaten. Pods sollten sich über föderierte Identitäten gegenüber Azure-Diensten ausweisen, statt langlebige Schlüssel im Manifest oder im Image zu tragen.
• Kubernetes-Secrets sind nicht verschlüsselt, sondern base64-kodiert. Wer sie ohne zusätzliche Maßnahmen nutzt, hat sie lesbar abgelegt. Für schützenswerte Werte gehört ein externer Tresor mit Rotation davor.
• Keine Zugangsdaten in Images. Ein Image wandert durch Registries, Caches und Entwicklerrechner. Was einmal darin liegt, ist praktisch nicht mehr zurückzuholen.

6. Protokollierung und Erkennung

Härtung verhindert einen Teil der Angriffe. Den Rest müssen Sie sehen.

Aktivieren Sie die Diagnoseprotokolle der Control Plane, insbesondere das Kubernetes-Audit-Log. Es zeigt, wer welche Ressource wann verändert hat, und ist damit die einzige belastbare Quelle für die Frage, was in einem Vorfall tatsächlich passiert ist.

Diese Protokolle sind nur nützlich, wenn sie dort landen, wo korreliert wird, und lange genug vorgehalten werden. Welche Quellen sich für die Erkennung lohnen und welche nur Kosten erzeugen, steht in Welche Log-Quellen braucht ein SIEM wirklich.

Achten Sie besonders auf: Änderungen an RBAC-Bindings, das Anlegen privilegierter Pods, Zugriffe auf Secrets und exec-Aufrufe in laufende Container. Das sind die Ereignisse, die bei einer Kompromittierung fast immer auftauchen.

Der eigentliche Punkt: Kubernetes-Sicherheit ist kein Häkchen

AKS senkt die Einstiegshürde, aber eine umfassende Kubernetes-Absicherung bleibt komplex und verlangt bewusste Arbeit. Fehlkonfigurationen in RBAC, offene API-Server, ungescannte Images und fehlende Network Policies gehören zu den häufigsten Einfallstoren in Container-Umgebungen. Das Tückische: Vieles davon ist unsichtbar, bis es jemand ausnutzt.

Als Prüfrahmen eignet sich der CIS Kubernetes Benchmark. Er ersetzt keine eigene Risikobetrachtung, liefert aber eine belastbare Ausgangsliste, gegen die sich der Ist-Zustand messen lässt.

Wer prüfen lassen will, ob die Konfiguration einem echten Angriff standhält, findet die Regeln und Grenzen dafür in Penetrationstests in der Public Cloud.

Wie Cloud Cape unterstützt

Container- und Cloud-Fehlkonfigurationen sind ein klassischer Fall für Continuous Threat Exposure Management: kontinuierlich erkennen, nach echtem Risiko priorisieren und durch reale Angriffstechniken validieren, statt einmal im Jahr zu hoffen. Unser Continuous Threat Exposure Management deckt AKS-Cluster, Images und Cloud-Konfigurationen mit ab; wo es tiefer gehen muss, prüft unser Red Team die Cluster auch offensiv.

Sprechen Sie mit uns über Exposure Management. Wir machen die Fehlkonfigurationen sichtbar, bevor es ein Angreifer tut.