TYPO3 on Kubernetes under IT-Grundschutz, part 14: The reference chart

01 — What the chart contains

The chart installs TYPO3 with the building blocks that belong to the application. It deliberately leaves out the database. That runs externally, as a managed service or with an operator of its own.

• TYPO3 on FrankenPHP as a Deployment with Service and Ingress, the code mounted read-only (part 2, part 8).
• Code as a signed artefact: cosign verifies, oras pulls, both in init containers (part 3).
• Valkey as the store for cache and sessions, with TLS and client certificates. Wiring it into TYPO3 is up to your configuration (part 5).
• A CA per tenant through cert-manager, with a configurable certificate lifetime.
• Secrets through the External Secrets Operator, in the pod only as files (part 7).
• NetworkPolicies with default deny and one allow per connection (part 6).
• Autoscaling, PodDisruptionBudget and spread across zones and nodes (part 9, part 12).
• The scheduler as a CronJob and an optional database backup (part 10).

Three profiles to compare

The ci/ directory holds three sets of example values. minimal is the smallest release that runs. full switches on every option. ha shows several TYPO3 replicas spread across zones. Valkey still runs as a single instance there, and the database lives outside the chart. Real high availability needs both to be resilient (part 12). The pipeline renders all three and validates them against the Kubernetes schemas. Anyone adapting the chart sees straight away what changes.

What a tenant brings

The chart does not ship a TYPO3 image. It expects a runtime image with PHP and FrankenPHP but without application code. The code arrives as the signed artefact. Configuration comes through environment variables, credentials come as files. The README describes this contract variable by variable, together with a short additional.php that implements it.

02 — How the code reaches the pod

Before PHP runs a single line, three init containers run one after the other. The first verifies the artefact's signature. The second pulls it into an empty volume. The third sets TYPO3 up against the database. If one of them fails, the pod does not start.

To check the SBOM attestation from part 3 in the cluster as well, switch on code.verify.attestation. That adds a fourth init container.

helm install tenant-a oci://ghcr.io/ohartwig/charts/typo3-kubernetes-chart \
  --version 0.2.0 --namespace tenant-a \
  --set image.repository=registry.example.org/tenant-a/typo3-runtime \
  --set code.artifact=registry.example.org/tenant-a/typo3-code@sha256:... \
  --set-file code.verify.publicKey=cosign.pub \
  --set ingress.host=typo3.example.org

Digest, not tag

The artefact is referenced by its digest, not by a tag. A tag can move between verification and download. cosign would then verify different bytes from the ones oras pulls. With a digest, both steps see the same thing. The chart warns at install time if a tag is used anyway.

One setup at a time

The setup runs in every pod. It has to, because extension:setup also publishes the public assets into that pod's own volume. A single job could not do that for every replica. But when several pods start together, for instance on a fresh install, they would work on the schema in parallel.

So the setup holds an advisory lock in the database. One pod sets up, the others wait. The lock belongs to the connection. If a pod dies mid-setup, the lock goes with it, and there is nothing to clean up.

The chart is signed too

Anyone recommending a signed supply chain should not ship the chart unsigned. Every version is signed at release through Sigstore, without a key of its own. The signature is bound to the repository's release workflow. Checking it takes cosign 3, because cosign 2 does not find the newer signature format:

cosign verify ghcr.io/ohartwig/charts/typo3-kubernetes-chart:0.2.0 \
  --certificate-identity-regexp '^https://github\.com/ohartwig/typo3-kubernetes-chart/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer token.actions.githubusercontent.com

03 — Privileges, network and keys

Every container in the chart runs with the same restrictions. That includes the init containers, the scheduler and the test pod. No root, a read-only file system, no capabilities, the RuntimeDefault seccomp profile. Service account tokens are not mounted, because TYPO3 never talks to the Kubernetes API. The chart therefore passes the restricted Pod Security Standard.

Default deny and individual allows

A NetworkPolicy first blocks the whole namespace. After that, each connection gets its own allow: ingress to TYPO3, TYPO3 to Valkey, TYPO3 to the database, the init containers to the registry. Valkey itself may not reach anything outside. By default, the allows for the database and the registry permit any address on the respective port. That is deliberate, because the chart does not know your addresses. Narrowing them is part of the installation.

mTLS without a service mesh

cert-manager builds a CA per namespace. Out of the box, the chart issues certificates valid for 30 days, a cautious starting value. With a high protection need, internalTls.duration lowers the lifetime to the 24 hours from part 5. Valkey requires client certificates and TLS 1.3. A sidecar reloads the server certificate after rotation, without a restart. The database can check the client certificate as well and map it to a user. This is the explicit model, without an extra control plane.

Secrets only as files

The chart does not render a single secret value. It only contains a reference to the secret store. The External Secrets Operator fetches the values and stores them as a Kubernetes Secret. In the pod they appear as files with mode 0440, never as environment variables. So a helm get values gives nothing away.

04 — Why not an operator?

The obvious question after thirteen parts: why a Helm chart and not a TYPO3 operator? An operator is a program of its own inside the cluster. It watches resources and steps in when their state drifts. That sounds like more automation. From a security point of view, it also adds attack surface.

What an operator costs

For a high protection need, APP.4.4.A16 even recommends operators for particularly critical applications. Anyone who deviates gives reasons, for example these:

• Privileges: An operator needs standing write access to Deployments and Secrets, often across several namespaces. Those are exactly the privileges APP.4.4.A3 restricts.
• Code of its own: It is software with its own release cycle. It needs scans, signatures and updates too. Any flaw in it affects every tenant.
• Less traceability: What an operator does lives in its code, not in the repository. A chart, by contrast, renders to manifests that anyone can review before deployment.

A chart with GitOps covers most of a TYPO3 installation's lifecycle. Install, upgrade and rollback are declarative. Setup and migrations run in the init container, the scheduler as a CronJob. What logic is left fits into a job.

When an operator would pay off

The line lies where the lifecycle can no longer be described declaratively. For example with a very large number of tenants that come and go through an API. Or with processes that have to react to state inside TYPO3 itself. For a manageable number of installations that a team maintains through Git, that is rarely the case. There, an operator is more burden than help.

Deliberately not included

The chart leaves out whatever differs from one platform to the next: the database, storage for fileadmin, the WAF, monitoring and the CVE scan. The scan belongs in the pipeline before signing, as described in part 4. The cluster only checks the signature.

Mapping to IT-Grundschutz

• SYS.1.6.A6 and SYS.1.6.A12 Secure images and their distribution: code only with a valid signature, referenced by digest.
• SYS.1.6.A8 Secure storage of credentials and SYS.1.6.A20 Protection of configuration data: secrets only as a reference, as a file in the pod.
• SYS.1.6.A15 Resource limits: requests and limits for every container.
• SYS.1.6.A17 Running containers without privileges: no root, no capabilities, seccomp RuntimeDefault.
• SYS.1.6.A23 Immutable containers: read-only root file system.
• APP.4.4.A4 Separation of pods and APP.4.4.A7 Separation of networks: Pod Security restricted and NetworkPolicies.
• APP.4.4.A6 Initialisation of pods: signature check, download and setup in init containers.
• APP.4.4.A9 Use of Kubernetes service accounts: no mounted token.
• APP.4.4.A16 Use of operators: deliberately no operator, reasons above. Chart and GitOps keep every step reviewable before deployment.
• APP.4.4.A18 Micro-segmentation and APP.4.4.A19 High availability: one allow per connection, PDB and spread across zones.
• CON.1 Crypto concept: a CA per tenant, limited, configurable lifetimes, TLS 1.3.

Conclusion

The reference chart condenses the series into a little over a dozen templates. Signed code, hardened containers, mTLS, network rules and secrets without Git all mesh there. Every decision is commented in the code and explained in this series. An operator would improve little of it. Above all, it would add privileges and code of its own.

The chart is on GitHub. The overview of all parts is in part 1: Which modules actually apply. Back to part 13: Hardening TYPO3 itself.