TYPO3 on Kubernetes under IT-Grundschutz, part 1: Which modules actually apply

01 — Protection needs first, technology second

IT-Grundschutz does not start with the cluster, it starts with the information. For every application, the protection need is assessed for three basic values: confidentiality, integrity and availability. The categories are normal, high and very high.

For a TYPO3 platform it often looks like this:

The maximum principle shapes the cluster

A cluster carries several applications. Under the maximum principle it takes on the highest protection need of every application running on it. A single website with a high need therefore lifts the whole platform. That is why tenant separation gets so much room in this series.

The opposite is the distribution effect. If an application is spread across several independent nodes, the availability need of a single node can drop. That only holds if the distribution really is independent.

A typical pitfall

In practice, availability is often set to high by reflex. That is expensive. High availability pulls in high availability for the control plane, the nodes and the database. Clarify early how long an outage is really acceptable. For a CMS holding personal data, confidentiality and integrity are almost always high.

02 — Modelling: which modules for TYPO3 on Kubernetes

Modelling assigns each object the matching modules from the IT-Grundschutz Compendium. This series refers to the 2023 edition. For TYPO3 on Kubernetes a fairly stable core emerges:

On top come the process modules such as ISMS.1 and the ORP layer. They apply to the whole organisation and are not the subject of this series.

With Grundschutz++ the BSI is rebuilding IT-Grundschutz, with a machine-readable catalogue instead of modules. How an ISMS can be checked against it today is the subject of the series Grundschutz++ as code.

SYS.1.6 and APP.4.4 belong together

A common mistake is to model only one of the two. SYS.1.6 deals with the individual container. It explicitly excludes orchestration, virtual networks and registries and points to APP.4.4 for them. Running Kubernetes means you need both modules.

TYPO3 is more than a container

APP.3.1 is easily overlooked because the focus is on the platform. Yet backend access, multi-factor login, extensions and TYPO3 security updates are application topics. A perfectly hardened cluster helps little if the backend is open to the internet. Part 13 shows how TYPO3 itself is hardened. More on the typical misconceptions in five misconceptions about TYPO3 on Kubernetes.

03 — What a high protection need adds

Every module distinguishes three levels: basic (B), standard (S) and requirements for increased protection needs (H). Basic and standard together form the standard protection. The H requirements come into consideration as soon as a basic value is high or very high.

The H requirements for Kubernetes and containers

• APP.4.4.A13 Automated auditing of the configuration
• APP.4.4.A14 Use of dedicated nodes
• APP.4.4.A15 Separation of applications at node and cluster level
• APP.4.4.A17 Attestation of nodes
• APP.4.4.A18 Use of micro-segmentation
• APP.4.4.A19 High availability of Kubernetes
• APP.4.4.A20 Encrypted data storage for pods
• APP.4.4.A21 Regular restart of pods
• SYS.1.6.A21 Extended security policies
• SYS.1.6.A22 Provisions for investigations
• SYS.1.6.A23 Immutability of containers
• SYS.1.6.A24 Host-based intrusion detection
• SYS.1.6.A25 High availability of containerised applications
• SYS.1.6.A26 Further isolation and encapsulation of containers

The list does not contain every H requirement of the modules, but the ones that change operations the most. The titles are translated from the German original.

Suggestions, not a checklist

H requirements are suggestions. Which of them get implemented is decided by a risk analysis following BSI standard 200-3. It looks specifically at the objects with high or very high protection needs. Anything not implemented needs a justification and a consciously accepted residual risk.

The IT-Grundschutz check as evidence

The IT-Grundschutz check records for every requirement whether it is met: yes, partially, no or dispensable. Only this check turns a good platform into a demonstrably secure one. In practice it pays to maintain it with every change rather than writing it at the end. The following parts therefore name the requirement each measure fulfils.

04 — The series at a glance

The series follows the path of a request and a release through the platform. Each part stands on its own and names the requirements it covers.

1. Which modules actually apply: protection needs, modelling, high protection needs. This post.
2. The hardened TYPO3 image: minimal base, FrankenPHP, runtime privileges.
3. Code as a signed artefact: OCI artefact, signature, verification before start.
4. No CVEs above 7: a scan gate that actually blocks.
5. mTLS on every hop: a CA per tenant, short-lived certificates.
6. Network and tenant separation: NetworkPolicies and admission rules.
7. Secrets without Git: External Secrets and workload identity.
8. Making TYPO3 stateless: sessions, fileadmin, caches and locks.
9. Autoscaling and probes: HPA, PodDisruptionBudget, rolling updates.
10. Database, backup and restore: MariaDB in the cluster or as a service, immutable backups.
11. Evidence and operations: logging, audit, CIS checks, runtime detection.
12. Availability with a high protection need: high availability for control plane, nodes and database.
13. Hardening TYPO3 itself: backend access, permissions, WAF, headers and updates.
14. The reference chart: every building block as an open Helm chart, and why it is not an operator.

The parts are published one after another. Links to parts not yet published become active once the post is online.

Conclusion

IT-Grundschutz for TYPO3 on Kubernetes starts with the protection need. It decides whether standard protection is enough or whether H requirements are added. SYS.1.6 and APP.4.4 form the core, and APP.3.1 keeps TYPO3 itself in view. The IT-Grundschutz check makes the implementation verifiable.

Continue with part 2: the hardened TYPO3 image.