TYPO3 on Kubernetes under IT-Grundschutz, part 5: mTLS on every hop

01 — Which hops get encrypted

A typical TYPO3 installation in a cluster has four internal hops:

1. from the ingress to the tenant's reverse proxy,
2. from the reverse proxy to the PHP runtime, for example FrankenPHP,
3. from the application to the database,
4. from the application to the cache, for example Valkey.

The public certificate ends at the ingress. From there, an internal one takes over. mTLS means that not only the server presents a certificate, but the client does too. A pod without a matching certificate cannot establish a connection, even if the network would allow it.

mTLS does not replace the NetworkPolicies from part 6, it complements them. The policy decides who can reach whom. The certificate proves who is talking.

02 — A CA per tenant

cert-manager issues the certificates. Each tenant gets its own CA, modelled as an Issuer in the tenant's namespace. A certificate from tenant A is not accepted by tenant B's services. The separation therefore reaches all the way into cryptography.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: app-mtls
  namespace: tenant-a
spec:
  secretName: app-mtls
  duration: 24h
  renewBefore: 8h
  privateKey:
    algorithm: ECDSA
    size: 256
    rotationPolicy: Always
  usages: [server auth, client auth]
  dnsNames:
    - app.tenant-a.svc.cluster.local
  issuerRef:
    name: tenant-a-ca
    kind: Issuer

Why only 24 hours

A short-lived certificate quickly loses its value if the key leaks. Revocation lists or OCSP are not needed for that. Renewing after 16 hours leaves an eight-hour buffer. And the short lifetime forces automation that works. If renewal depends on a manual step, that shows up by the next day at the latest.

With rotationPolicy: Always, every renewal also creates a new key. With cert-manager, private keys live only as a secret in the cluster and are mounted into the pod, never baked into the image.

Since Kubernetes 1.37, without a secret

Kubernetes 1.37 ships pod certificates. The kubelet generates the key itself, fetches the certificate from a signer and writes both into a volume, so the key never sits in a secret. You do have to provide the signer yourself, because cert-manager cannot issue these certificates yet (cert-manager#8378). A signer of its own per tenant keeps the separation just as a CA per tenant does. How I built one and moved a whole cluster's mesh onto it is covered in two field notes: Pod certificates instead of shared secrets and The whole mesh on pod certificates. For most installations, cert-manager remains the mature default.

03 — Reloading without a restart

cert-manager renews the secret. The process that uses the certificate still has to load it again. This is the typical pitfall: renewal works, reloading does not, and after 24 hours the connection fails.

Each component has its own way:

• Caddy and FrankenPHP reload their configuration through the admin API. A small sidecar notices the new certificate and triggers it.
• MariaDB rereads its certificates with FLUSH SSL, without dropping connections.
• Valkey picks up new certificate files when its TLS settings are set again with CONFIG SET.
• Where no such path exists, a tool like Stakater Reloader restarts the pods on a changed secret, in a rolling fashion.

The other side verifies the client certificate. In Caddy it looks like this:

tls /tls/tls.crt /tls/tls.key {
    client_auth {
        mode require_and_verify
        trust_pool file /tls/ca.crt
    }
}

The database demands encrypted connections with require_secure_transport=ON, and the application user additionally needs a certificate via REQUIRE X509. Valkey listens only on its TLS port and demands a client certificate with tls-auth-clients yes.

Monitoring expiry

Monitoring the secret is not enough. What matters is the certificate the service actually serves. A probe that opens the connection and measures the remaining lifetime alerts before the buffer runs out.

04 — Service mesh or explicit mTLS

A service mesh like Istio or Linkerd handles mTLS automatically, through sidecars or an ambient mode. Policies and telemetry come on top. The price is an additional control plane, more moving parts and harder debugging.

Explicit mTLS is the leaner option. Every hop is configured visibly, and there is no layer in between. In return, each component needs its own setup. With few services per tenant, as in a TYPO3 installation, the explicit model is usually enough. With many services and changing connections, a mesh pays off sooner.

How it maps to IT-Grundschutz

Algorithms, key lengths and lifetimes belong in the cryptography concept under CON.1. Encryption between pods supports network separation (APP.4.4.A7) and micro-segmentation for an increased protection need (APP.4.4.A18). Keeping keys only as mounted secrets and never in the image contributes to secure storage of credentials (SYS.1.6.A8) and to protecting configuration data (SYS.1.6.A20).

Conclusion

mTLS in a cluster is not a service mesh project but a matter of a clean chain: a CA per tenant, short-lived certificates, a reliable reload in every component and monitoring of the certificate that is actually served. The short lifetime is not a risk but a test. It shows every day whether the automation works.

The series continues with part 6: network and tenant separation. Back to part 4: no CVEs above 7.