Supply Chain Security für Platform Teams

Lernziele

Nach dieser Lektion kannst du erklären, warum die Software-Supply-Chain das größte Angriffsvektor einer Kubernetes-Plattform ist und welche Rolle SBOMs, Image-Signing, Admission Policies und Artifact-Trust dabei spielen. Du kennst einen pragmatischen Aufbau von der Build-Pipeline bis zum laufenden Pod und kannst erklären, wie du Sicherheit einführst, ohne jedes Team einzeln zu bremsen. Du weißt, wo Sigstore/cosign in modernen Setups einordnet und welche Trade-offs bei Enforcement-Strenge und Betriebsaufwand entstehen.

Das Problem: Du vertraust, was du nicht kennst

Deine Plattform startet täglich tausende Container. Woher kommen die Images? Aus Docker Hub, aus einem privaten Registry-Mirror, aus der CI-Pipeline des Teams — und manchmal aus einem Dockerfile, das seit zwei Jahren niemand angefasst hat. Jede Schicht in jedem Image ist Code, den du nicht geschrieben hast: Base-Image, npm-Pakete, Python-Wheels, Helm-Chart-Dependencies.

Der Angriff funktioniert nicht mehr über das Front-End, sondern über die Lieferkette: Ein kompromittiertes Base-Image, ein typosquattes npm-Paket, ein geleaktes CI-Token, das ein Angreifer nutzt, um ein signiert aussehendes Image in eure Registry zu pushen. Sobald dieses Image in Produktion läuft, ist es inside the perimeter — und in einem flachen Cluster-Netz (Lektion 42) ein Sprungbrett zu allem anderen.

Supply Chain Security für Platform Teams heißt: Jeder Artefakt, der auf der Plattform landet — Container-Image, Helm-Chart, OCI-Artefakt — muss herkunftsnachweisbar, unverändert und policy-konform sein, bevor ein Pod startet.

Die vier Säulen: SBOM, Signing, Admission, Trust

SBOM (Software Bill of Materials) ist das Inventar dessen, was in einem Artefakt steckt. Nicht aus Compliance-Lust, sondern weil du ohne Inventar nicht reagieren kannst: Wenn morgen eine CVE in libssl bekannt wird, brauchst du in Minuten die Liste aller laufenden Images, die sie enthalten — nicht in Tagen manuelle Suche. SBOMs werden in der CI erzeugt (Syft, Trivy, CycloneDX-Format) und am Artefakt angehängt oder in einer zentralen Datenbank indexiert.

Image-Signing beweist, dass ein Artefakt von einer vertrauenswürdigen Quelle stammt und unterwegs nicht manipuliert wurde. Der moderne Standardweg ist Sigstore/cosign: Die CI-Pipeline signiert das Image mit einem kurzlebigen Key (Fulcio), der an die Identität der Pipeline gebunden ist (OIDC). Im Cluster prüft ein Admission-Controller (Kyverno, Gatekeeper/conftest, Ratify) die Signatur, bevor das Deployment durchgeht. Ohne gültige Signatur: abgelehnt, mit klarer Fehlermeldung ans Team.

Admission Policies sind der Enforcement-Punkt — hier trifft Supply Chain Security auf Policy-as-Code (Lektion 28). Typische Regeln: Nur Images aus der internen Registry; nur Images mit gültiger Signatur; kein :latest; maximale Image-Größe; keine bekannten Critical-CVEs über einen Scanner-Webhook. Admission Control ist der letzte Gatekeeper: Was die CI nicht abfängt, fängt der Cluster ab.

Artifact-Trust ist das übergeordnete Modell: Welche Quellen, Builder und Registries gelten als vertrauenswürdig? Das definierst du zentral — Root of Trust, Key-Management, Registry-Zugriffskontrolle — statt jedes Team selbst entscheiden zu lassen. In Enterprise-Setups gehören dazu auch Helm-Chart-Signing (cosign für OCI-Charts) und geprüfte Upstream-Charts über einen kuratierten Katalog.

Der End-to-End-Flow: von Git Push bis Running Pod

So sieht ein durchgängiger Supply-Chain-Flow auf einer reifen Plattform aus:

1. Entwickler pusht Code; die CI baut das Image in einer gehärteten Pipeline (kein Docker-in-Docker mit Root, isolierte Runner).
2. CI scannt das Image (CVEs, Secrets im Layer), erzeugt SBOM, signiert mit cosign, pusht in die interne Registry.
3. Registry akzeptiert nur Push von autorisierten CI-Identitäten; öffentliche Pulls laufen über einen Mirror mit Vulnerability-Scanning.
4. GitOps (Argo CD) synchronisiert das Deployment-Manifest; das Image-Tag ist fix (Digest oder semver-Tag).
5. Admission Controller prüft beim Pod-Start: Signatur gültig? Registry erlaubt? CVE-Schwellwert ok? → Pod startet oder wird abgelehnt.

Der Platform-Team-Mehrwert: Teams müssen Schritte 2–5 nicht selbst bauen. Der Golden Path (Lektion 5) enthält eine CI-Vorlage mit Scan, SBOM und Sign — wer sie nutzt, ist supply-chain-sicher ohne eigene Security-Expertise.

Trade-offs: Wie streng, wie schnell?

Supply Chain Security ist kein Binär-Schalter. Drei Entscheidungen bestimmst du als Plattform-Team:

Enforcement-Strenge: „Warn only” (Audit-Mode) vs. „Block”. Starte mit Audit, damit du siehst, wie viele Deployments scheitern würden — dann schaltest du auf Block um, wenn der Golden Path die Mehrheit abdeckt. Big-Bang-Blockierung an Tag eins erzeugt Revolte.

Scanner-Latenz vs. Sicherheit: CVE-Scanning in der CI kostet Minuten. Für kritische Pipelines akzeptierst du das; für Experiment-Umgebungen kannst du lockere Regeln erlauben — mit klarer Netzwerk-Isolation.

Build vs. Buy: Sigstore/cosign + Kyverno ist der Open-Source-Standard; kommerzielle Plattformen (Snyk, Prisma, Aqua) bündeln Scan, SBOM und Policy. Der Trade-off ist Integrationstiefe vs. Lizenzkosten — und ob du Exit-Strategie brauchst (Lektion 11).

Praxis

Baue den minimalen Supply-Chain-Loop im Lab:

# Image bauen und mit cosign signieren (nach cosign generate-key-pair)
docker build -t localhost:5000/demo:1.0 .
docker push localhost:5000/demo:1.0
cosign sign --key cosign.key localhost:5000/demo:1.0

# Deployment ohne Signatur — sollte von Policy abgelehnt werden
kubectl create deploy unsigned --image=localhost:5000/demo:1.0

# Mit Signatur-Verifikation in Kyverno/Gatekeeper-Policy aktiv
kubectl create deploy signed --image=localhost:5000/demo:1.0

Parallel: Erzeuge eine SBOM mit syft localhost:5000/demo:1.0 -o cyclonedx-json und speichere sie am Release-Artefakt. Frage dich: Wenn CVE-2024-XXXX morgen published wird — wie findest du alle betroffenen Deployments in unter einer Stunde?

Typische Stolperfallen

Nur Scanning, kein Enforcement. Ein CVE-Report, den niemand blockiert, ist eine To-do-Liste, die wächst.

Signierung ohne Key-Rotation. Statische cosign-Keys in Git sind das nächste Secret-Leak. Kurzlebige Keys über Sigstore/Fulcio sind der Standard.

:latest in Produktion. Tags sind mutable; Digests sind immutable. Policies sollten Digest oder semver erzwingen.

Upstream-Images ungeprüft. Wer Base-Images direkt von Docker Hub zieht, importiert fremde Supply Chains. Mirror + Scan + Allowlist.

Supply Chain nur für Container. Helm-Charts, Terraform-Module und npm-Pakete in Build-Pipelines sind gleichermaßen Angriffsvektoren.

Interview-Vorbereitung

Antwortstruktur für „Wie sichert ihr die Software Supply Chain?”: Problem (fremder Code in jedem Container) → Vier Säulen (SBOM, Signing, Admission, Trust) → Flow (CI scannt/signiert → Registry → Admission prüft) → Trade-off (Audit-Mode vor Block, Golden Path statt Einzel-Lösungen).

Follow-ups:

• „Was ist eine SBOM und wofür brauchst du sie?” — Inventar für Incident Response und Compliance-Nachweis.
• „cosign vs. Notary?” — cosign/Sigstore ist der aktuelle Cloud-Native-Standard mit OIDC-gebundenen Keys.
• „Wie rollst du das ein, ohne Teams zu blockieren?” — Golden Path zuerst, Audit-Mode, dann schrittweise Enforcement.

Zusammenfassung

Supply Chain Security schützt die Plattform davor, Artefakte auszuführen, deren Herkunft und Inhalt unbekannt sind. SBOMs liefern Transparenz, Image-Signing beweist Integrität, Admission Policies setzen Regeln am Cluster-Gate durch, Artifact-Trust definiert vertrauenswürdige Quellen zentral. Der Golden Path integriert Scan, SBOM und Sign in die CI — Teams werden sicher, ohne es selbst bauen zu müssen. Der zentrale Trade-off ist Enforcement-Strenge gegen Adoption: Audit first, Block when ready. Als Nächstes geht es um die andere Seite des Zugriffs: wer darf auf der Plattform was tun — Access Governance und Audit.