TYPO3 on Kubernetes under IT-Grundschutz, part 11: Evidence and operations

01 — Logs belong in one central place

Containers are short-lived. Their logs disappear with them unless someone collects them. That is why SYS.1.6.A7 requires container logging data to be stored persistently. The module OPS.1.1.5 “Protokollierung” sets the framework around it.

A collector on every node, Grafana Alloy for example, reads the container logs and ships them to a central store such as Loki. The retention period is defined and documented there. For a high protection need, one year is a common value. The application itself writes nothing to local files. It writes to stdout.

On top of that comes the audit log of the Kubernetes API. It records who changed which resource and, with a suitable policy, who read which secret. The API server enables it with --audit-policy-file and --audit-log-path, in k3s through the corresponding server arguments. It comes with its own policy and its own retention. On managed Kubernetes services it is enabled in the provider's configuration. Without it, nobody can reconstruct after an incident who read a secret or changed a deployment.

02 — Alerts that react to the right things

Prometheus collects metrics, Alertmanager routes alerts. The real work is in the rules. An alert on high CPU load often wakes someone for nothing. Rules on symptoms are worth more: pods that keep restarting. Certificates close to expiry. Failed backup jobs. Secrets that stopped syncing. And 5xx responses at the ingress. APP.4.4.A11 sums this up as monitoring of the containers.

An external availability check complements the monitoring inside the cluster. It calls the real domains from outside. If the whole cluster goes down, internal monitoring goes quiet. The external check still reports.

In practice there is a pattern: the most dangerous outages are the silent ones. A check that was never scheduled never reports anything. So every alert needs a test that shows it actually fires.

03 — Checking the hardening, detecting attacks

kube-bench checks the cluster against the CIS benchmark for Kubernetes. Run as a scheduled job, it produces recurring evidence instead of a one-off snapshot. For a high protection need, APP.4.4.A13 asks for exactly this automated audit of the configuration.

Falco detects at runtime what happens inside containers. A shell in a pod that does not need one. Writes to system paths. Unexpected network connections. That covers host-based intrusion detection under SYS.1.6.A24 and feeds events into detection under DER.1. Uploaded files are checked by ClamAV twice: on upload, before they are delivered, and again at night with current signatures. The nightly run finds files that still counted as clean when they were uploaded.

The cloud layer belongs in the picture too. An audit trail of the cloud API, stored with object lock, records every access. A threat detection service reports access that bypasses the cluster.

04 — Patches, incidents and the evidence

The node operating system installs security updates automatically. Reboots are orchestrated by a job that drains and restarts one node after the other. k3s itself is upgraded by the system-upgrade-controller, driven by a plan resource in the GitOps repository. With other distributions, the respective upgrade path takes over, such as kubeadm upgrade or the version field in the infrastructure code of a managed service. That keeps every version traceable, as OPS.1.1.3 requires for patch and change management.

Incidents need a fixed procedure: detect, contain, fix, follow up. Only the written retrospective turns an incident into an improvement. For a high protection need, SYS.1.6.A22 asks for preparation for investigations. That includes being able to preserve the state of a container before it gets deleted.

In the end, an audit is about evidence. Logs, alert history, kube-bench results, restore records from part 10 and retrospectives prove that the controls are not just configured. They show that they work.

Conclusion

Operating under IT-Grundschutz mostly means that the cluster tells you itself what happens inside it. Central logs, an API audit log, alerts on symptoms and regular checks make controls visible. Add automated patching and incident follow-up, and you have something to show in the audit.

The next part deals with the hardest protection goal: part 12: Availability with a high protection need. Back to part 10: database, backup and restore.