TYPO3 auf Kubernetes unter IT-Grundschutz, Teil 3: Code als signiertes Artefakt
Ein gehärtetes Image nützt wenig, wenn der Code darin unbemerkt ausgetauscht werden kann. Die entscheidende Frage lautet deshalb: Woher weiß der Pod, dass er genau das ausführt, was die Pipeline gebaut hat?
Die Antwort ist eine Kette aus Artefakt, Signatur und Prüfung. Dieser Teil zeigt, wie sie funktioniert und wo sie im IT-Grundschutz verankert ist.
Teil 3 von 14 der Serie „TYPO3 auf Kubernetes unter IT-Grundschutz“. Die Übersicht aller Teile steht in Teil 1.
01 — Laufzeit und Code getrennt ausliefern
Die Laufzeit aus Teil 2 enthält PHP und FrankenPHP, aber keinen TYPO3-Code. Der Code kommt als eigenes Artefakt dazu. Die Pipeline packt das fertige Release mit vendor/ und gebauten Assets in ein Archiv. Mit oras landet es als OCI-Artefakt in derselben Registry wie die Images.
Im Pod hängt der kubelet das Artefakt als schreibgeschütztes Image-Volume ein, einmal je Node und Digest. Der Hauptcontainer startet FrankenPHP darauf. Bis Oktober 2026 hat das ein initContainer mit ORAS erledigt, der das Archiv bei jedem Pod-Start geladen und entpackt hat.
Warum sich die Trennung lohnt
- Ein PHP-Sicherheitsupdate wird ausgerollt, ohne dass jede Website neu gebaut wird.
- Ein Website-Release ändert nichts an der geprüften Laufzeit.
- Beide Teile haben eigene Versionen, eigene Signaturen und eigene Scans.
Das ist ein sauberer Weg für SYS.1.6.A4 Planung der Bereitstellung und Verteilung von Images. Wie das Artefakt aufgebaut ist, zeigt ausführlich TYPO3-Code als OCI-Artefakt. Die Architekturentscheidung dahinter beschreibt Laufzeit und Anwendung trennen.
02 — Signieren und eine SBOM anhängen
Ein Artefakt in der Registry ist noch kein vertrauenswürdiges Artefakt. Die Pipeline signiert es deshalb direkt nach dem Push. Der Signaturschlüssel liegt in einem KMS und verlässt es nie. Die Pipeline darf den Schlüssel nur benutzen, nicht auslesen.
# Artefakt pushen und per Digest referenzieren
oras push registry.example.org/typo3/site:1.4.2 release.tar.gz
# Signatur mit Schlüssel im KMS
cosign sign --key awskms:///alias/release-signing \
registry.example.org/typo3/site@sha256:<digest>
# SBOM als signierte Attestierung anhängen
cosign attest --key awskms:///alias/release-signing \
--type cyclonedx --predicate sbom.json \
registry.example.org/typo3/site@sha256:<digest>
Die SBOM listet jede Abhängigkeit mit Version. Sie ist die Grundlage für das Scan-Gate in Teil 4. Weil sie selbst signiert ist, lässt sie sich nicht nachträglich schönen.
Ohne Transparenzlog kommen --tlog-upload=false beim Signieren und --insecure-ignore-tlog=true bei der Prüfung dazu. Sonst lädt cosign die Signatur in das öffentliche Rekor-Log und verlangt dort bei der Prüfung einen Eintrag.
Die Freigabe ist die Signatur
SYS.1.6.A13 verlangt die Freigabe von Images. In dieser Kette ist die Signatur der dokumentierte Freigabeakt. Signiert wird nur, was alle Prüfungen der Pipeline bestanden hat. SYS.1.6.A12 Verteilung sicherer Images ist damit ebenfalls abgedeckt, denn verteilt wird ausschließlich per Digest.
03 — Prüfen, bevor der Pod startet
Die Signatur ist nur so gut wie ihre Prüfung. Im Pod läuft deshalb eine feste Reihenfolge:
- Signatur des Artefakts gegen den öffentlichen Schlüssel prüfen.
- Die SBOM-Attestierung prüfen.
- Erst dann startet der Container, und der kubelet hängt den Code als schreibgeschütztes Image-Volume ein, festgelegt auf denselben Digest.
initContainers:
- name: verify-signature
image: registry.example.org/tools/cosign@sha256:<digest>
args: ["verify", "--key", "/keys/release.pub",
"registry.example.org/typo3/site@sha256:<digest>"]
- name: verify-sbom
image: registry.example.org/tools/cosign@sha256:<digest>
args: ["verify-attestation", "--key", "/keys/release.pub",
"--type", "cyclonedx",
"registry.example.org/typo3/site@sha256:<digest>"]
volumes:
- name: code
image:
reference: registry.example.org/typo3/site@sha256:<digest>
pullPolicy: IfNotPresent
Bis Oktober 2026 hat an dieser Stelle ein dritter initContainer den Code mit ORAS in ein Volume geladen. Seit Kubernetes 1.36 sind Image-Volumes stabil, und auch containerd hängt sie ein. Wie der Umstieg gelang und warum ein Artefakt dabei zunächst leer eingehängt wurde, steht in der Feldnotiz zum Image-Volume.
Schlägt eine Prüfung fehl, startet der Pod nicht. Das Verhalten ist fail-closed: lieber kein neuer Pod als ein ungeprüfter. Der alte Pod läuft beim Rolling Update (mit maxUnavailable: 0) weiter. Das erfüllt APP.4.4.A6 Initialisierung von Pods.
initContainer oder Admission-Webhook
Die Alternative ist ein Admission-Webhook, etwa mit einem Policy-Controller. Er prüft Signaturen cluster-weit für alle Images. Das ist breiter, bringt aber eine neue Abhängigkeit: Fällt der Webhook aus, starten keine Pods mehr, auch keine reparierenden. Der initContainer prüft genau das Artefakt, auf das es ankommt, und fällt nur für den eigenen Pod aus. In der Praxis zeigt sich: Der initContainer ist der robustere Einstieg. Der Webhook lohnt sich, sobald alle Images signiert sind und der Controller selbst hochverfügbar läuft.
04 — Die Kette davor: Commits, Pipelines und Digests
Eine Signatur belegt, dass die Pipeline ein Artefakt gebaut hat. Sie belegt nicht, dass der Code in der Pipeline der richtige war. Die Kette beginnt deshalb früher.
Signierte Commits
Jeder Commit auf dem Hauptzweig trägt eine Signatur. Eine Liste erlaubter Schlüssel im Repository legt fest, wer signieren darf. Eine Pipeline-Prüfung lehnt unsignierte Commits ab. Wie das mit Menschen, KI-Agenten und Bots zusammen funktioniert, zeigt Wer hat diesen Commit wirklich signiert?
Pipelines als Code
Die Pipeline selbst ist versioniert und wird aus geprüften Vorlagen zusammengesetzt. Änderungen daran laufen über Merge-Requests wie jeder andere Code. Das deckt APP.4.4.A2 Planung der Automatisierung mit CI/CD und APP.4.4.A10 Absicherung von Prozessen der Automatisierung ab.
Digests statt Tags im Deployment
Im GitOps-Repository steht jede Version mit ihrem Digest. Ein Tag kann umgehängt werden, ein Digest nicht. Neue Versionen trägt ein Update-Werkzeug per Merge-Request ein, zum Beispiel pinup. So ist jede Auslieferung eine nachvollziehbare Änderung im Repository.
Häufige Fragen
Warum wird der TYPO3-Code nicht einfach ins Image gebaut?+
Weil Laufzeit und Anwendung dann denselben Lebenszyklus hätten. Jedes PHP-Update würde einen Neubau aller Websites erzwingen, jedes Release die Laufzeit berühren. Getrennt lassen sich beide unabhängig signieren, scannen und ausrollen.
Was passiert, wenn die Signaturprüfung fehlschlägt?+
Der neue Pod startet nicht. Beim Rolling Update mit maxUnavailable: 0 bleibt der alte Pod in Betrieb, die Website bleibt erreichbar. Das fehlgeschlagene Deployment fällt im Monitoring auf und wird untersucht, bevor irgendetwas Ungeprüftes läuft.
Braucht die Signatur ein öffentliches Transparenzlog?+
Nicht zwingend. Ein Transparenzlog macht Signaturen öffentlich nachvollziehbar. Für private Artefakte und Schlüssel im eigenen KMS kann man bewusst darauf verzichten. Dann trägt der geschützte Schlüssel die gesamte Vertrauenskette, und das sollte dokumentiert sein.
Reicht ein initContainer, oder muss es ein Admission-Webhook sein?+
Für den Code der Website reicht der initContainer, er prüft genau dieses Artefakt. Ein Admission-Webhook deckt zusätzlich alle anderen Images im Cluster ab. Er ist aber selbst eine kritische Komponente und sollte erst kommen, wenn er hochverfügbar betrieben werden kann.
Fazit
Der TYPO3-Code kommt als eigenes, signiertes OCI-Artefakt mit SBOM in den Cluster. Ein initContainer prüft Signatur und SBOM vor jedem Start und bricht bei Abweichung ab. Davor sichern signierte Commits, versionierte Pipelines und Digests die Kette. Damit sind SYS.1.6.A4, A12 und A13 sowie APP.4.4.A2, A6 und A10 belegbar.
Weiter mit Teil 4: Keine CVEs über 7. Zurück zu Teil 2: Das gehärtete TYPO3-Image.
Ich richte dir eine Lieferkette ein, in der nur signierter und geprüfter TYPO3-Code in Produktion läuft.
OCI-Artefakte, Signaturen mit Schlüsseln im KMS, SBOM-Attestierungen und eine Prüfung vor jedem Pod-Start.
Plattform-Betrieb statt Beratung auf Papier: Auf Wunsch betreibe ich die Pipeline dauerhaft und halte die Kette lückenlos.
Über den Autor
Kai Ole Hartwig
Programmiert seit 2002 – autodidaktisch gelernt, 2012 mit KO-Web selbständig gemacht. Über 100 Projekte, Fokus auf Security, Performance, Automatisierung und Qualität. Heute freiberuflich: DevSecOps-Beratung, Schulungen und Softwareentwicklung.