Container Hardening 2026: Angriffsfläche im Image senken

Robin Werner, Head of Azure & Kubernetes bei Pexon Consulting | 9 Min. Lesezeit | 10.09.2026

TL;DR: Container Hardening kurz erklärt

Container Hardening reduziert die Angriffsfläche im Image: kein Root, keine offenen Ports, keine Pakete und Build-Tools, die im Betrieb niemand braucht. Cluster-Härtung filtert viel ab, die Restlücken sitzen im Container. Pexon Consulting prüft das im Kubernetes Security Assessment und setzt danach eigene oder fertig gehärtete Basis-Images auf. Nebeneffekt: kleinere Images starten schneller.

Das Problem: „secure by default“ gibt es nicht

Wer mit Kubernetes unterwegs ist, hört und denkt oft: Ist doch alles secure by default. Ist es nicht. Vieles davon steckt bereits direkt im Container, im Image, das Sie benutzen. Und dorthin schaut kaum jemand.

Das Muster, das wir in Projekten sehen: Man nimmt die Helm-Charts und Container, die mitkommen, unverändert. Oder man baut selbst etwas auf Ubuntu-Basis und denkt gar nicht daran, was danach noch zu tun wäre. Beides ist verständlich. Beides ist der Normalzustand in gewachsenen Umgebungen.

Unsere klare Position: Cluster-Härtung ohne Blick ins Image ist halbe Arbeit. Sie sperren die Tür und lassen den Nachschlüssel im Schloss.

Container Hardening bedeutet, sich diese Ebene einmal bewusst anzusehen. Wie offen ist dieser Container eigentlich? Läuft er als Root? Sind Ports offen? Stecken Pakete darin, die im Betrieb niemand mehr braucht?

Genau diese Fragen stellen wir im Kubernetes Security Assessment. Nicht als Theorie, sondern am laufenden Cluster.

Warum Kubernetes selbst neue Angriffsfläche mitbringt

Ein Punkt, den viele nicht auf dem Schirm haben: Mit Kubernetes holt man sich durchaus zusätzliche Angriffsfläche ins Haus.

Sie bekommen ein sehr mächtiges Tooling an die Hand. Und mächtiges Tooling, das schlecht konfiguriert und schlecht genutzt wird, bringt eben auch Sicherheitslücken mit. Die Kubernetes-API, Service Accounts, die Netzwerkkommunikation zwischen Namespaces, Admission-Mechanismen: all das sind Fähigkeiten, die in der falschen Konfiguration zu Wegen werden.

Deshalb funktioniert Kubernetes-Sicherheit nur zweistufig. Kubernetes Hardening auf Cluster-Ebene ist der beliebte und wirksame Einstieg: RBAC sauber schneiden, Netzwerk-Policies setzen, Pod Security Standards durchsetzen, den API-Zugang begrenzen. Das filtert wirklich viel ab. Restricted gilt laut Kubernetes als Production-Default, nicht Baseline.

Aber um Lücken tatsächlich zu schließen und die Umgebung noch einmal spürbar besser zu bekommen, muss man auf den Container selbst hinuntergehen. Das ist der Teil, den man nicht überspringen kann.

Wir raten aktuell davon ab, erst ein Jahr Cluster-Policies zu pflegen und das Image-Thema „später“ zu machen. Später heißt in der Praxis: nie. Die Images laufen weiter als Root, APT bleibt drin, und die nächste CVE im Paketmanager trifft eine Umgebung, die auf dem Papier gehärtet ist.

Typische Schwachstellen bei Container Hardening

Der Klassiker ist das Ubuntu-Image, das unverändert betrieben wird. Das ist streng genommen kein Fehler. Ein Container ist ohnehin deutlich schlanker als eine VM, damit ist der erste Schritt gemacht. Aber in einem vollständigen Ubuntu-Image stecken sehr viele Tools und Bestandteile, die für den Betrieb des Containers gar nicht gebraucht werden.

Konkret sind das die Punkte, die wir im Assessment regelmäßig finden:

1. Root-Kontext. Der Container läuft als Root, obwohl die Applikation das nicht braucht.
2. Paketmanager. APT ist nach dem Build im Container weiterhin vorhanden. Gerade über Paketmanager sind in der Vergangenheit Sicherheitslücken aufgekommen. Die mitigiert man schlicht dadurch, dass man sie deinstalliert.
3. Offene Ports. Der Container exponiert Ports, die die Applikation nicht bedient.
4. Übernommene Helm-Chart-Defaults. Werte, die für eine Testumgebung gedacht waren, laufen produktiv weiter.
5. Debug- und Diagnosetools. Shells, Netzwerk-Tools, Editoren. Praktisch beim Entwickeln, ein Geschenk für jeden, der einmal drin ist.

Ein Befund, der im Scan als gelb oder rot landet, sieht in der Spec oft so aus:

# Illustrativ: Spec, die im Scan als gelb oder rot landet.
apiVersion: v1
kind: Pod
spec:
  containers:
    - name: app
      securityContext:
        runAsNonRoot: false
        allowPrivilegeEscalation: true
      ports:
        - containerPort: 22
        - containerPort: 8080

Root, Privilege Escalation, ein SSH-Port, den die Fachanwendung nicht braucht. Kein Zero-Day. Eine Konfiguration, die niemand nach dem Go-Live noch einmal angefasst hat.

Das Deployment ist „grün“. Die Angriffsfläche sitzt trotzdem im Container.

Die Königsklasse: Build-Tools raus

Der wirksamste Schritt kommt danach: sämtliche Build-Tools aus dem Laufzeit-Image entfernen.

Bei Python oder Node ist das der große Hebel. Statt die komplette Runtime samt Compiler-Kette im Container mitzuschleppen, bauen Sie fertige Pakete und liefern nur diese aus. Der nächste Schritt ist eine Slim-Variante des Basis-Images. Der beste Fall ist eine vollständig lauffähige Binary, die überhaupt keine Abhängigkeiten mehr braucht.

Wenn man es wirklich perfekt macht, läuft im Container am Ende nur noch genau die eine kleine Applikation, für die der Container da ist. Nichts sonst.

Ein Multi-Stage-Build, der das umsetzt, sieht ungefähr so aus. Build-Tools bleiben im Builder, das Laufzeit-Image bekommt nur die fertige Auslieferung:

# Multi-Stage: Compiler und pip bleiben im Builder.
FROM python:3.12-slim AS builder
WORKDIR /build
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

FROM gcr.io/distroless/python3-debian12
COPY --from=builder /install /usr/local
COPY app.py /app/app.py
USER 65532:65532
EXPOSE 8080
ENTRYPOINT ["python", "/app/app.py"]

Kein APT. Keine Shell. Kein Root. Distroless ist nicht die einzige richtige Antwort, aber es macht die Richtung sichtbar: Was im Betrieb niemand braucht, gehört nicht ins Image. Nach Angaben der Maintainer liegt genau darin der Punkt: kein Paketmanager, keine Shell, kein Root-Login.

Das geht ein Stück über das reine Container-Thema hinaus und berührt die Softwareentwicklung: Wie liefere ich meine Applikation aus? Das ist die richtige Stelle für die Frage. Und es ist der Grund, warum Container Hardening ein gemeinsames Thema von Betrieb und Entwicklung ist und nicht allein an der Security hängt.

Unsere Empfehlung: Wer Container selbst baut, plant Hardening von Tag eins in die Pipeline. Nachträglich jedes Image von Hand zu schleifen, hält niemand durch.

Der Nebeneffekt, den niemand erwartet

Container Hardening ist nicht nur ein Security-Thema. Es ist auch ein Performance-Thema. Und das ist das Interessante daran.

Wenn Sie Pakete herauswerfen und Angriffsflächen reduzieren, wird der Container kleiner. Kleinere Images bedeuten kürzere Pull-Zeiten, schnellere Starts, geringeren Registry-Speicher und flotteres Verhalten beim Skalieren. Der Container wird insgesamt responsiver.

Ein volles Ubuntu-Image mit Build-Chain liegt schnell bei mehreren hundert Megabyte. Ein Distroless- oder Scratch-Image mit einer statischen Binary oft bei wenigen Dutzend. Beim Rolling Update auf 40 Nodes merken Sie den Unterschied in Minuten, nicht in Folien.

Das ist selten das Argument, mit dem ein Hardening-Projekt startet. Häufig ist es aber das Argument, mit dem es intern durchgeht. Sicherheit und Geschwindigkeit ziehen hier ausnahmsweise in dieselbe Richtung.

Wer intern gegen „Security verlangsamt uns“ argumentieren muss: Hier ist der Gegenbeweis. Härten macht in diesem Fall schneller, nicht langsamer.

Selbst härten oder gehärtete Images nutzen

Eigene Images von Grund auf zu härten ist aufwendig. Man muss viel beachten, und der Aufwand fällt bei jedem Update erneut an.

Deshalb greifen wir mit vielen Kunden auf fertig gehärtete Basis-Images zurück, statt alles selbst zu bauen. Das ist der pragmatische Weg: Sie bekommen ein minimales, gepflegtes Fundament und setzen Ihre Applikation darauf. Der Pflegeaufwand liegt beim Anbieter des Basis-Images, nicht bei Ihnen.

Das ist keine Ausrede, die eigene Auslieferung zu ignorieren. Ein gehärtetes Basis-Image plus Root-Prozess plus offener Debug-Port ist immer noch ein offenes Image. Die Basis nimmt Ihnen die Paketpflege ab. Root-Kontext, Ports und Chart-Defaults bleiben Ihre Aufgabe.

Wer Bestandscontainer oder Bestands-Helm-Charts nutzt, sollte zumindest einmal prüfen lassen, ob dort etwas zu optimieren ist und ob eine Umstellung auf eigene oder gehärtete Images sinnvoll ist. Genau das ist der Einstieg über den Security Scan, nicht über ein sechsmonatiges Umbau-Projekt.

Wer selbst Software entwickelt, gehört das in die Kubernetes-Beratung plus Pipeline: Der Build produziert das schlanke Image, das Cluster akzeptiert nichts anderes.

Häufig gestellte Fragen

Bringt Kubernetes Hardening allein nicht schon genug?

Es bringt viel. Netzwerk-Policies, RBAC und Pod-Security filtern einen großen Teil ab und sind der richtige erste Schritt. Aber sie schützen die Umgebung um den Container herum, nicht den Container selbst. Wenn im Image eine ausnutzbare Komponente liegt, verschiebt Cluster-Härtung nur die Frage, wie weit ein Angreifer danach kommt.

Verlangen ISO 27001 oder NIS2 explizit Container Hardening?

Nicht mit diesem Wortlaut. Beide fordern angemessene technische Maßnahmen zur Risikominimierung. In einer containerisierten Umgebung ist die Härtung der Images genau das. In Audits wird sie regelmäßig zum Thema, sobald der Prüfer versteht, dass die Applikation im Container läuft und nicht auf einem gehärteten Server.

Wie prüfe ich, wie gut meine Images heute sind?

Der schnellste Weg ist ein Blick von außen und von innen. Genau diese Punkte sehen wir uns im Kubernetes Security Assessment mit an: Root-Kontext, offene Ports, unnötige Pakete, übernommene Chart-Defaults. Sie bekommen eine Ampelbewertung und wissen danach, welche Images tatsächlich Priorität haben.

Wie oft muss ein gehärtetes Image erneuert werden?

So oft, wie im Basis-Image Sicherheitsupdates erscheinen. In der Praxis bedeutet das einen automatisierten Rebuild in der Pipeline, nicht einen Kalendertermin. Ein gehärtetes Image, das ein Jahr alt ist, ist kein gehärtetes Image mehr.

Lohnt sich der Aufwand bei internen Anwendungen?

Ja, weil die Annahme „intern“ in containerisierten Umgebungen selten hält. Wenn ein Angreifer irgendwo im Cluster Fuß fasst, ist die Frage nur noch, wie weit er lateral kommt. Ein schlankes Image begrenzt genau das, unabhängig davon, ob die Anwendung aus dem Internet erreichbar ist.

Nächster Schritt

Mitbringen sollten Sie drei Dinge: eine Liste der Images, die produktiv laufen, die Information, welche davon Sie selbst bauen und welche übernommen sind, und einen lesenden Zugang zum Cluster.

Damit lässt sich in einem Assessment sauber beantworten, wo die schnellen Gewinne liegen. Und welche Images tatsächlich ein Risiko darstellen statt nur unaufgeräumt zu sein.

Robin Werner, Head of Azure & Kubernetes bei Pexon Consulting, erklärt, was Container Hardening konkret bedeutet, welche Schwachstellen typisch sind und warum gehärtete Container nebenbei schneller werden. Video auf YouTube ansehen.

Verwandte Themen