Docker Hardened Images - Sicherheit ab Werk für moderne Container-Infrastrukturen

Containerisierte Anwendungen sind längst ein zentraler Bestandteil moderner IT-Architekturen. Doch je mehr Unternehmen auf Docker setzen, desto deutlicher wird: Sicherheit und Compliance sind nicht optional, sondern essenziell für einen stabilen und vertrauenswürdigen Betrieb. Oft liegt der entscheidende Unterschied zwischen einem sicheren und einem verwundbaren System bereits in der Basis — dem Docker-Image, auf dem alles aufbaut.

Docker Hardened Images liefern hier die Lösung. Sie bieten nicht nur die gewohnte Funktionalität standardisierter Container, sondern eine gehärtete, auditierbare und Compliance-konforme Grundlage, die Sicherheitslücken minimiert und branchenspezifische Anforderungen automatisch erfüllt.

Was sind Docker Hardened Images (DHI)?

Ein Hardened Image ist eine sicherheitstechnisch gehärtete Version eines regulären Docker-Images. Ziel ist es, potenzielle Schwachstellen (CVEs) frühzeitig zu eliminieren und das Image so abzusichern, dass es regulatorischen und unternehmensinternen Sicherheitsrichtlinien entspricht.

Diese Images werden anhand gängiger Security-Benchmarks überprüft und angepasst. Dazu gehören z. B.:

• CIS Benchmarks (Center for Internet Security): Empfehlungen für sichere Systemkonfigurationen.
• FIPS (Federal Information Processing Standards): Vorschriften zur kryptografischen Sicherheit, z. B. für den US-amerikanischen Regierungssektor.
• STIG (Security Technical Implementation Guide): Richtlinien des US-Verteidigungsministeriums zur Härtung von Systemen.

Konkret bedeutet das:

• Unnötige Pakete und Dienste werden entfernt.
• Nur geprüfte und signierte Pakete werden eingebunden.
• Standard-Nutzer (root) wird deaktiviert oder durch nicht privilegierte Nutzer ersetzt.
• Logging, Monitoring und Konfigurationsparameter werden sicherheitsoptimiert.
• Regelmäßige Schwachstellen-Scans und Updates sind fester Bestandteil des Prozesses.

Vergleichbar ist der Unterschied zwischen einem normalen Image und einem gehärteten Image mit dem zwischen einer frisch aufgesetzten Linux-VM und einer produktionstauglich abgesicherten Server-Instanz – dieselbe Grundlage, aber mit viel mehr Schutzmaßnahmen.

Hier sehen wir ein Spielspiel vom offiziellen Keycloak DHI Container:

Im Screenshot sehen wir direkt welche Compliance-Audits durchgeführt wurden, welche Pakete installiert sind, welche CVEs gefunden wurden und wie die Härtung des Images aussieht. Die dev Version des Keycloak Images beinhaltet immer einen Package Manager (z.B. apt) und root Zugang, damit Entwickler schnell und einfach Pakete installieren können. Das hardened Image hingegen enthält keinen Package Manager und keinen root Zugang, damit Angreifer nicht so leicht Schwachstellen ausnutzen können. Die Version ohne dev ist für die Produktion gedacht, die Version mit dev ist für die Entwicklung gedacht. Beide Images werden regelmäßig aktualisiert, um neue Schwachstellen zu beseitigen und die Sicherheit zu gewährleisten.

Warum man Docker Hardened Images verwenden sollte

1. Sicherheit von Anfang an

Ein Großteil der Sicherheitsvorfälle in Containern lässt sich auf kompromittierte Images oder unsichere Basiskonfigurationen zurückführen. Durch den Einsatz gehärteter Images baut man eine Sicherheitskette von der Basis aus auf – “Shift Left Security” in Reinform. Schwachstellen werden reduziert, bevor die Anwendung überhaupt deployt wird. Weniger Image Schwachstellen bedeuten weniger Angriffsflächen, was die Sicherheit der gesamten Container-Infrastruktur erheblich verbessert.

2. Compliance und Regulierung

Viele Branchen müssen strenge Compliance-Anforderungen erfüllen (z. B. Finanzwesen, Gesundheitswesen, Regierung). Hardened Images, die nach Standards wie CIS, FIPS oder STIG zertifiziert sind, liefern den Nachweis für Audits und erfüllen regulatorische Anforderungen automatisch.

3. Weniger Aufwand für Security-Teams

Security-Teams müssen sich nicht mehr ständig um manuelles Patchen oder Nachhärten kümmern. Die Pflege und Aktualisierung erfolgt zentral und automatisiert über den Anbieter der gehärteten Images. Das spart Zeit, reduziert Kosten und minimiert menschliche Fehler. Das heisst jedoch nicht das man sich nicht um Containerupdates selbst kümmern muss, natürlich muss das Image regelmäßig aktualisiert werden, um neue Schwachstellen zu beseitigen und die Sicherheit zu gewährleisten

4. Einheitliche Sicherheits- und Entwicklungsbasis

Teams in großen Organisationen profitieren von standardisierten, geprüften Basis-Images, die überall gleich sicher sind – egal, ob im Dev-, Staging- oder Produktionsumfeld. So entstehen reproduzierbare, vertrauenswürdige Deployments.

Keycloak 26.x als Beispiel für Hardened Images

Ein konkretes Beispiel für Docker Hardened Images sind die Keycloak 26.x Varianten (Siehe Screenshot), die du auf Docker Hub unter Hardened Images Catalog findest. Sie zeigen, wie feingliedrig und transparent Sicherheitsniveaus konfiguriert werden können. Gerade bei einem Identity Provider wie Keycloak, der sensible Daten verwaltet, ist die Härtung des Images von entscheidender Bedeutung. Die Keycloak DHI Images bieten verschiedene Sicherheitsstufen, von “dev” für die Entwicklung bis “hardened” für die Produktion, und erfüllen dabei die Anforderungen von CIS, FIPS und STIG.

Hauptvarianten im Überblick

1. Keycloak 26.x (Standard, nonroot)

• Basis: Debian 13
• Tags: 26, 26-debian13, 26.5, 26.5-debian13, 26.5.6, 26.5.6-debian13
• Compliance: CIS
• User: nonroot

Diese Variante bietet eine solide gehärtete Grundlage, erfüllt CIS-Benchmarks und läuft nicht als Root-User – ein wichtiger Schritt zur Container-Isolation. Sie ist ideal für Produktionsumgebungen, bei denen standardisierte Sicherheit gefragt ist.

2. Keycloak 26.x (fips)

• Basis: Debian 13
• Tags: 26-debian13-fips, 26-fips, 26.5-debian13-fips, 26.5-fips, 26.5.6-debian13-fips, 26.5.6-fips
• Compliance: CIS, FIPS, STIG (100 %)
• User: nonroot (UID 65532)

Diese Version richtet sich an Organisationen mit höchsten Sicherheitsanforderungen – etwa Regierungsbehörden oder kritische Infrastrukturen. FIPS-Unterstützung bedeutet, dass alle kryptografischen Operationen nur validierte Algorithmen nutzen. STIG sorgt zusätzlich für strenge Systemkonfigurationen.

3. Keycloak 26.x (dev)

• Basis: Debian 13
• Tags: 26-debian13-dev, 26-dev, 26.5-debian13-dev, 26.5-dev, 26.5.6-debian13-dev, 26.5.6-dev
• Compliance: CIS
• User: root
• Ziel: Entwicklungsumgebungen

Diese Variante ist zwar gehärtet, aber in bestimmten Bereichen lockerer konfiguriert, um Entwicklung und Debugging zu erleichtern. Sie eignet sich nicht für Produktion, aber ideal für lokale Tests oder Build-Pipelines.

4. Keycloak 26.x (fips-dev)

• Basis: Debian 13
• Tags: 26-debian13-fips-dev, 26-fips-dev, 26.5-debian13-fips-dev, 26.5-fips-dev, 26.5.6-debian13-fips-dev, 26.5.6-fips-dev
• Compliance: CIS, FIPS, STIG (100 %)
• User: root
• Ziel: Secure Development Environments

Diese Mischung aus Dev-Komfort und maximaler Compliance ermöglicht es, Sicherheitsfeatures schon im Entwicklungsprozess mitzudenken – perfekt für DevSecOps.

Root vs. Nonroot: Ein unterschätzter Unterschied

Ein kleiner, aber entscheidender Punkt in der Sicherheitsarchitektur ist, ob Container als Root oder Non-root-User laufen.

• Root-Container besitzen innerhalb des Containers vollen Zugriff und könnten bei Exploits ins Host-System ausbrechen.
• Nonroot-Container hingegen laufen mit minimalen Privilegien, wodurch Lateral Movement und Privilege Escalation verhindert werden.

Hardened Images fördern automatisch die Nonroot-Nutzung – ein einfacher, aber hocheffektiver Sicherheitsgewinn.

Wie kann ich in klassischen Docker Container nonroot User erzwingen?

In klassischen Docker-Containern kannst du einen Non-root-User erzwingen, indem du in deinem Dockerfile die folgenden Schritte ausführst. In diesen Beispiel Dockerfile nutzen wir das Basis Image von Python und konfigurieren non-root User:

FROM python:3.13

WORKDIR /python-docker

# Erstelle einen neuen Benutzer
RUN useradd -m nonroot

RUN apt-get update && \
    apt-get install -y libgl1 && \
    rm -rf /var/lib/apt/lists/*

# Installiere Abhängigkeiten
COPY requirements.txt requirements.txt
RUN pip install --upgrade pip
RUN pip3 install -r requirements.txt

# Kopiere den Anwendungscode und setze die Berechtigungen
COPY . .
RUN chown -R nonroot:nonroot /python-docker

# Wechsle zum neuen Benutzer
USER nonroot

# Starte die Anwendung
CMD ["python3", "main.py"]

Das Problem mit diesem Ansatz ist, dass er nicht so robust und sicher ist wie ein von Grund auf gehärtetes Image. Es erfordert zusätzliche Schritte, um sicherzustellen, dass alle Pakete und Dienste sicher konfiguriert sind, und es besteht die Gefahr das Sicherheitslücken bereits im Basis-Image vorhanden sind, diedurch die Härtung nicht beseitigt werden können. Ein Docker Hardened Image hingegen bietet von Anfang an eine sichere Basis, die speziell dafür entwickelt wurde, um Schwachstellen zu minimieren und die Sicherheit zu maximieren. Es ist eine umfassendere Lösung, die nicht nur den User-Status, sondern auch die gesamte Systemkonfiguration berücksichtigt.

Debian 13 als Basis: Stabilität trifft Sicherheit

Zurück zum Keycloak Beispiel: Alle Varianten basieren auf Debian 13, einem der stabilsten und sichersten Linux-Distributionen. Debian 13 gilt als eine Distribution, die für Stabilität, Security-Updates und lange Support-Zyklen bekannt ist. Debian bildet eine verlässliche Grundlage, insbesondere bei der Implementierung von CIS- und STIG-Richtlinien.

Ein auf Debian 13 basierendes Hardened Image profitiert von:

• Aktuellen Sicherheits-Patches
• LTS-Unterstützung (Long Term Support)
• Kompatibilität mit gängigen Tools und Frameworks
• Nachvollziehbarem, transparentem Sicherheitsprozess

Health, Vulnerabilities und Type Compliance

Jedes gehärtete Image wird regelmäßig hinsichtlich Vulnerability Management und Type Compliance überwacht.

Das bedeutet:

• Bekannte CVEs (Common Vulnerabilities and Exposures) werden laufend gescannt.
• Abweichungen von CIS/FIPS/STIG-Vorgaben werden sofort erkannt.
• Health-Checks werden integriert, um Laufzeit- und Integritätsprobleme frühzeitig zu melden.

Dadurch entsteht ein kontinuierlicher Sicherheitskreislauf – vom Build bis zur Laufzeit. Den aktuellen CVE Score sieht man direkt im Docker Hub Catalog.

Wie man Hardened Images einsetzt

Die Nutzung ist denkbar einfach. Grundsätzlich ersetzt du in deinem Dockerfile oder deiner docker-compose.yml das Standard-Base-Image durch das gehärtete Pendant aus dem offiziellen Katalog.

• Wähle das passende Hardened Image aus dem offiziellen Katalog (z. B. das FIPS-nonroot-Image von Keycloak).
• Ersetze in deinem Dockerfile oder docker-compose.yml das Standard-Base-Image durch das gehärtete Pendant.
• Teste deine Anwendung gründlich, um sicherzustellen, dass sie mit dem neuen Image kompatibel ist.
• Automatisiere zukünftige Updates über CI/CD-Pipelines.

Ein Beispiel-Snippet:

FROM registry.hardened-images.local/keycloak:26.5.6-debian13-fips
COPY ./config /opt/keycloak/config
USER 65532
ENTRYPOINT ["start-keycloak.sh"]

So erhältst du von Anfang an eine sicherheitszertifizierte Umgebung – ohne nachträgliche Härtung.

Sicherheit ist kein Add-on – sie ist das Fundament

Docker Hardened Images sind kein Luxusprodukt, sondern ein logischer Schritt zur Vertrauensbildung in der Software-Lieferkette. Sie schaffen Sicherheit, bevor die ersten Container live gehen, reduzieren Angriffsflächen und erleichtern Compliance-Management erheblich.

Unternehmen, die Cloud-native und containerbasiert arbeiten, sollten diese Images als Standardbasis in ihren Entwicklungs- und Produktionsumgebungen etablieren – insbesondere, wenn Datenschutz, Sicherheit und Nachvollziehbarkeit Priorität haben.