Container Images verstehen: Aufbau, Sicherheit und Best Practices

Grundlagen von Container Images

Ein Container Image ist ein leichtgewichtiges, eigenständiges Paket, das alles enthält, was eine Anwendung zur Ausführung benötigt. Laut der Definition des NIST bietet diese Technologie eine portable, wiederverwendbare und automatisierbare Methode, um Anwendungen zusammen mit ihrem Code, ihrer Runtime, ihren Bibliotheken, ihren Systemwerkzeugen und ihren Konfigurationen zu bündeln. Anders als virtuelle Maschinen, die ein vollständiges Betriebssystem benötigen, teilen sich Container den Kernel des Hostsystems und enthalten nur eine minimale, anwendungsspezifische Betriebssystemebene.

Durch diese Architektur sind Container schneller und ressourceneffizienter als virtuelle Maschinen. Entwicklungsteams bündeln eine Anwendung einmal und führen sie überall aus, ob auf einem lokalen Rechner, einem Testserver oder einer Cloud-Plattform. So entfällt das bekannte Problem „Auf meinem Rechner funktioniert es doch" und die Anwendung verhält sich in jeder Umgebung gleich.

Unterschiede zwischen Docker Images und Containern

Docker Images und Container erfüllen in der Container-Architektur unterschiedliche Aufgaben, auch wenn die Begriffe oft synonym verwendet werden.

Ein Docker Image ist ein schreibgeschütztes Paket, das als Bauplan für die Erstellung von Containern dient. Entwicklungsteams erstellen Images aus einem vorhandenen Image oder einem Dockerfile und speichern sie in Registries wie Docker Hub oder Red Hat Quay. Diese Images bleiben statisch, bis daraus ein Container gestartet wird.

Ein Container ist eine laufende Instanz eines Docker Image. Beim Start ergänzt der Container das Image um eine beschreibbare Ebene und lässt so temporäre Änderungen zur Laufzeit zu. Container laufen direkt auf dem Hostrechner und teilen sich dessen Kernel, was sie leichtgewichtig hält. Orchestrierungswerkzeuge wie Kubernetes automatisieren Deployment, Skalierung und Vernetzung, um Container in großem Maßstab zu verwalten.

Da Container und Docker Images in containerisierten Anwendungen unterschiedliche Rollen spielen, klärt ein Blick auf ihre wichtigsten Unterschiede, wie sie zusammenspielen. Die folgende Tabelle schlüsselt diese Unterschiede auf:

Funktionsweise der Container-Architektur

Die Container-Architektur stützt sich auf diese vier Kernkomponenten, um Container effizient zu erstellen, zu speichern und auszuführen:

Container Images

Container Images nutzen eine ebenenbasierte Struktur, bei der jede Ebene eine Änderung oder Ergänzung am Dateisystem darstellt. Der Prozess beginnt mit einem Base Image, das das Betriebssystem und die grundlegenden Bibliotheken enthält, während weitere Ebenen dependencies und Anwendungscode hinzufügen.

Wichtige Merkmale von Container Images:

• Ebenenbasierte Struktur: Basisebene + dependencies + Konfigurationen + Anwendungscode;

• Unveränderlichkeit: Nach der Erstellung bleibt das Image unverändert und sorgt so für Konsistenz über alle Umgebungen hinweg;

• Wiederverwendbarkeit: Images lassen sich über verschiedene Systeme hinweg wiederverwenden und reduzieren so Redundanz.

Ein Container Image mit einem Dockerfile erstellen

Entwicklungsteams erstellen Container Images mit einem Dockerfile, also einem Skript, das definiert, wie das Image gebaut wird:

# Use an official lightweight base image
FROM python:3.9-slim

# Set the working directory inside the container
WORKDIR /app

# Copy application files into the container
COPY . /app

# Install dependencies
RUN pip install -r requirements.txt

# Command to run the application
CMD ["python", "app.py"]

Best Practices:

• minimale Base Images wie alpine verwenden, um die Angriffsfläche zu reduzieren;

• Images regelmäßig aktualisieren, um Schwachstellen zu schließen;

• Images signieren und verifizieren, um vor dem Deployment die Authentizität sicherzustellen.

Container Registries

Eine Container Registry ist eine zentrale Anlaufstelle, in der Images gespeichert und verteilt werden. Entwicklungsteams laden Images nach der Erstellung hoch (push) und rufen sie beim Deployment von Anwendungen ab (pull).

Verbreitete Container Registries

• Docker Hub: eine weit verbreitete öffentliche Registry mit einer riesigen Sammlung von Images;

• AWS Elastic Container Registry (ECR): in die AWS-Cloud-Dienste integriert;

• Google Container Registry: für Deployments in der Google Cloud optimiert.

Container Images wirksam verwalten

• Images korrekt taggen: aussagekräftige Tags vergeben, um Versionen nachzuverfolgen:

docker tag my-app:latest my-app:v1.0.0

• Auf Schwachstellen scannen: Sicherheitswerkzeuge wie Trivy oder Docker Scout einsetzen, um Fehler zu erkennen:

trivy image my-app:v1.0.0

• Zugriffskontrolle und Sicherheit: Berechtigungen einschränken, um unbefugte Änderungen zu verhindern.

Container Runtimes

Eine Container Runtime ist die Software, die Container Images aus einer Registry abruft, entpackt und die Anwendung in einer isolierten Umgebung ausführt.

Docker bleibt die bekannteste Container Runtime und hat maßgeblich zur Verbreitung der Container-Technologie beigetragen. Das Ökosystem ist jedoch gewachsen, und andere Runtimes decken inzwischen unterschiedliche Anforderungen ab. Viele Kubernetes-Umgebungen setzen auf containerd und CRI-O, weil diese eine leichtgewichtige, optimierte Ausführung von Containern in großem Maßstab ermöglichen.

Die Wahl der Runtime hängt vom Anwendungsfall ab. Docker bietet eine Komplettlösung mit einem einfachen Entwicklungs-Workflow, während containerd und CRI-O sich effizienter in Kubernetes für großangelegte Deployments einfügen. Unabhängig von der Runtime bleibt das Ziel dasselbe: Container zuverlässig und sicher auf jedem System auszuführen.

Workflow eines Container Image (Quelle: Docker)

Union-Dateisysteme und der Copy-on-Write-Mechanismus

Container stützen sich auf ein Union-Dateisystem (UnionFS) und den Copy-on-Write-Mechanismus (CoW), um Speicher effizient zu verwalten und leichtgewichtige, schnelle Deployments zu gewährleisten. Statt ganze Dateisysteme zu duplizieren, teilen sich Container über diese Technologien gemeinsame Ebenen und lassen zugleich Änderungen zu, die das ursprüngliche Image nicht berühren.

• UnionFS: stapelt mehrere Ebenen zu einer einzigen, einheitlichen Ansicht. Jede Ebene steht für eine andere Stufe des Container Image, beginnend mit der Basisebene und ergänzt um weitere Ebenen für dependencies und Anwendungscode. Diese Ebenen bleiben schreibgeschützt, um Konsistenz über mehrere Container hinweg zu sichern, die dasselbe Image ausführen.

• CoW-Mechanismus: greift, sobald ein Container eine Datei ändern muss. Statt die ursprüngliche Ebene zu verändern, legt das System eine neue beschreibbare Ebene über den bestehenden an. Der Container arbeitet mit dieser Ebene, lässt das zugrunde liegende Image aber unberührt. Dieser Ansatz optimiert den Speicher, beschleunigt die Startzeiten von Containern und stellt sicher, dass mehrere Container dasselbe Base Image ohne Konflikte nutzen.

Gemeinsam machen UnionFS und der CoW-Mechanismus Container Images hocheffizient, portabel und skalierbar. Sie reduzieren Redundanz und erhalten zugleich die Flexibilität. Das ist besonders wertvoll in Container-Orchestrierungsplattformen wie Kubernetes, in denen die effiziente Verwaltung vieler Container Priorität hat.

Die Bedeutung von Container Images

Container Images verändern, wie Teams Anwendungen in der Cloud bereitstellen und verwalten. Der Nutzen geht über reine Bequemlichkeit hinaus und bietet deutliche Vorteile bei Geschwindigkeit, Konsistenz, Skalierbarkeit und Sicherheit. Hier einige dieser Vorteile:

Schnellere, effizientere Deployments

Container Images bündeln Anwendungen mit all ihren dependencies und machen die manuelle Einrichtung der Umgebung überflüssig. So wechseln Entwicklungsteams nahtlos vom Coding über das Testen bis zum Deployment, ohne durch Kompatibilitätsprobleme ausgebremst zu werden. Dieser schlanke Ablauf beschleunigt die Softwareentwicklung und reduziert Ausfallzeiten.

Konsistenz über alle Umgebungen hinweg

Mit Container Images laufen Anwendungen in jeder Umgebung gleich, ob in der Entwicklung, im Test oder in der Produktion. Das verhindert Fehler durch Konfigurationsunterschiede und sorgt dafür, dass Anwendungen sich vorhersehbar verhalten, egal ob sie auf einem lokalen Rechner oder in der Cloud laufen.

FROM python:3.9-slim
WORKDIR /app
COPY . /app
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Nahtlose Skalierbarkeit für microservices

Container Images schaffen moderne, skalierbare Architekturen, indem sie Anwendungen in kleinere, unabhängige Dienste zerlegen. Diese Flexibilität erleichtert es, einzelne Komponenten je nach Bedarf zu skalieren, ohne das gesamte System zu beeinträchtigen. Cloud-Plattformen und Orchestrierungswerkzeuge wie Kubernetes nutzen diese Fähigkeit, um Ressourcenzuteilung und Leistung zu optimieren. Um einen Webdienst zu skalieren, lassen sich zum Beispiel mehrere Replikate einer containerisierten Anwendung ausführen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web-container
        image: myapp:latest
        ports:
        - containerPort: 80

Diese Flexibilität erleichtert es, Lastspitzen abzufangen und Ressourcen zugleich effizient zu nutzen.

Mehr Sicherheit durch unveränderliche Images

Nach der Erstellung bleiben Container Images unverändert, um unbefugte Änderungen zu verhindern, die Schwachstellen einschleusen könnten. Sicherheitsteams scannen Images vor dem Deployment und stellen so sicher, dass nur vertrauenswürdige und verifizierte Versionen in die Produktion gelangen.

Gängige Praxis ist es, Images vor dem Deployment mit Werkzeugen wie Trivy auf Schwachstellen zu scannen:

trivy image myapp:latest

Diese Unveränderlichkeit stärkt die Cloud-Sicherheit, senkt das Risiko von Manipulationen und vereinfacht ein Rollback, falls ein Problem auftritt.

Container Images bilden den Kern der cloud-native Entwicklung und machen Anwendungen schneller im Deployment, einfacher in der Verwaltung und sicherer. Ihre Bedeutung für moderne Infrastrukturen wächst weiter, da Organisationen auf skalierbare, widerstandsfähige Deployment-Strategien setzen.

Häufige Sicherheitsrisiken bei Container Images

Container Images vereinfachen das Deployment, bringen aber auch Sicherheitsrisiken mit sich. Angreifer nutzen Schwachstellen aus, sobald ein Container läuft. Deshalb ist es entscheidend, Images in jeder Phase abzusichern.

• Anfällige dependencies: Viele Container Images stützen sich auf Bibliotheken von Drittanbietern, die Sicherheitslücken enthalten können. Ohne regelmäßige Updates werden diese Schwachstellen zu Einfallstoren für Angreifer.

• Fehlkonfigurationen: Schlecht konfigurierte Images setzen Anwendungen unbefugtem Zugriff, Datenlecks oder privilege escalation aus. Das OWASP Top 10 führt Fehlkonfigurationen in der Sicherheit und fehlerhafte Zugriffskontrolle als weit verbreitete Risiken auf, die sich in microservices-Umgebungen oft als zu weitreichende Berechtigungen oder offene Netzwerkports zeigen.

• Kompromittierte Images: Verschafft sich ein Angreifer Zugang zu einer Container Registry, ersetzt er vertrauenswürdige Images durch bösartige. Zudem kann ein kompromittiertes Image Malware, Backdoors oder das Risiko einer data exfiltration einschleusen.

• Fest codierte secrets: Anmeldedaten, API-Schlüssel oder sensible Daten in einem Image zu speichern, ist ein schwerwiegender Sicherheitsfehler. Gelangen Angreifer an diese offengelegten secrets, greifen sie auf kritische Systeme zu und nutzen sie weiter aus.

Best Practices für Verwaltung und Sicherheit von Container Images

Container Images zu verwalten und abzusichern ist entscheidend für zuverlässige, effiziente und sichere Deployments. Mit diesen Best Practices lassen sich Sicherheitsrisiken von Containern reduzieren, die Leistung optimieren und die Konsistenz über alle Umgebungen hinweg wahren:

1. Images aktuell und sicher halten

Container Images regelmäßig zu aktualisieren, beugt Sicherheitsschwachstellen vor und sorgt für Stabilität. Veraltete Images enthalten häufig bekannte Exploits und werden so zu potenziellen Angriffsvektoren. Ein Neubau der Images mit den aktuellen Basisversionen mindert diese Risiken.

Ein Upgrade von FROM alpine:3.19 auf FROM alpine:3.20 übernimmt zum Beispiel die Sicherheits-Patches der Upstream-Maintainer.

Sicherheitsscans spielen eine zentrale Rolle für die Sicherheit von Images. Werkzeuge wie Trivy, Grype und Docker Scout in die CI/CD pipeline zu integrieren, ermöglicht die automatische Erkennung veralteter Pakete und Schwachstellen vor dem Deployment.

In einem Node.js-Projekt aktualisieren diese Befehle veraltete dependencies und verringern so die Angriffsfläche für Schwachstellen:

npm outdated
npm update

Minimale Base Images reduzieren ebenfalls die Angriffsfläche. Leichtgewichtige Images wie Alpine Linux enthalten weniger Komponenten und minimieren so potenzielle Risiken gegenüber vollwertigen Distributionen.

2. Robuste Versionskontrolle und Rollback-Strategien umsetzen

Eine wirksame Versionskontrolle erleichtert es, Image-Änderungen nachzuverfolgen, unerwartete Updates zu verhindern und bei Bedarf ein Rollback durchzuführen. Vage Tags wie latest sind zu vermeiden, da sie zu ungewollten Updates in der Produktion führen. Stattdessen kommen versionierte und umgebungsspezifische Tags zum Einsatz:

• Semantische Versionierung (MAJOR.MINOR.PATCH):

  • Major: tiefgreifende Änderungen (v2.0.0 → v3.0.0);

  • Minor: neue Funktionen (v1.1.0 → v1.2.0);

  • Patch: Sicherheitskorrekturen (v1.2.1 → v1.2.2).

• Branch-basiertes Tagging:

  • feature-xyz;

  • hotfix-123;

  • release-v1.0.0.

So lassen sich Images wirksam taggen und hochladen:

# Build the image
docker build -t myapp:1.2.3 .

# Tag for production
docker tag myapp:1.2.3 mydockerhubuser/myapp:prod

# Push tags to registry
docker push mydockerhubuser/myapp:1.2.3
docker push mydockerhubuser/myapp:prod 

3. Image-Builds, Sicherheitsscans und Deployments automatisieren

CI/CD pipelines für Image-Builds, Sicherheitsscans und Deployments zu nutzen, verbessert die Konsistenz, verringert menschliche Fehler und beschleunigt die Auslieferung. Plattformen wie GitHub Actions, Jenkins und GitLab CI/CD lassen Rollouts schlanker ablaufen und binden sich zugleich in Orchestrierungswerkzeuge wie Kubernetes ein.

Ein gut strukturiertes Dockerfile stärkt die Sicherheit zusätzlich, indem es Build-dependencies von den Runtime-Komponenten trennt. Ein mehrstufiger Build (multi-stage build) hilft dabei:

# First stage: Build the application
FROM node:18 AS builder
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
RUN npm run build

# Second stage: Create a lightweight runtime image
FROM node:18-slim
WORKDIR /app
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/server.js"]

Dieser Ansatz stellt sicher, dass nur die notwendigen Dateien im finalen Image landen, und hält es leichtgewichtig und sicher.

Um Image-Builds und Sicherheitsscans bei Code-Commits zu automatisieren, könnte ein GitHub-Actions-Workflow so aussehen:

name: Build and Push Docker Image
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - name: Build, scan, and push image
        run: |
          docker build -t myapp:latest .
          trivy image --exit-code 1 myapp:latest  # Security scan before push
          docker tag myapp:latest mydockerhubuser/myapp:latest
          docker push mydockerhubuser/myapp:latest

Dieser Workflow baut, scannt und deployt Images automatisch, sobald neue Änderungen nach main gepusht werden, und stellt sicher, dass nur sichere, aktuelle Images in die Produktion gelangen.

Der Ansatz von Wiz für die Sicherheit von Container Images

Containerisierte Anwendungen abzusichern erfordert eine proaktive Strategie, und Wiz vereinfacht diesen Prozess mit seiner einheitlichen Sicherheitsplattform. Wiz bietet cloud security posture management, Container- und Kubernetes-Sicherheit, vulnerability management und data protection für vollständige Transparenz in AWS, Azure, Google Cloud und Kubernetes-Umgebungen.

Wiz stellt über WizOS zudem abgesicherte Container Images bereit, die kontinuierlich auf nahezu null CVEs gepflegt werden. Das reduziert vererbte Schwachstellen und das Risiko in der supply chain security und hilft Teams, agil zu bleiben, ohne den Schutz zu beeinträchtigen.

Indem Wiz Sicherheit direkt in die Entwicklungs-Workflows einbindet, erkennt es Schwachstellen früh, scannt infrastructure as code auf Fehlkonfigurationen und verwaltet secrets sicher. Dieser Ansatz senkt das Risiko, vereinfacht die Compliance und stärkt die Sicherheit auf jeder Ebene der Cloud-Infrastruktur.

Bereit, Ihre Container Images abzusichern? Entdecken Sie WizOS, holen Sie sich das kostenlose Cheatsheet mit Best Practices für container security oder vereinbaren Sie eine Demo, um Wiz in Aktion zu erleben.