Kubernetes security: een cluster dat standaard dicht staat

Secrets horen niet plat in Git en niet in een values.yaml. Voor alles wat we deployen via GitOps kiezen we tussen twee routes. External Secrets Operator (ESO) leest secrets uit een externe kluis en schrijft ze als gewone Kubernetes Secret in de namespace. In Git staat dan alleen een ExternalSecret-resource met een verwijzing, geen waarde. Sealed Secrets doet het omgekeerde: je versleutelt een secret lokaal met kubeseal en zet de versleutelde SealedSecret in Git. Alleen de controller in het cluster kan hem ontsleutelen.

Onze voorkeur is ESO zodra er een kluis is, of zodra je meerdere clusters of omgevingen hebt. Rotatie gebeurt dan op één plek. Je kunt toegang per secret regelen in de kluis, met auditlog. Op AWS koppelen we ESO via IRSA of EKS Pod Identity, op Azure via Workload Identity, zodat er geen statische cloudsleutels in het cluster staan. Sealed Secrets past bij een klein platform zonder cloudkluis, bijvoorbeeld een k3s-cluster op eigen servers.

Eerlijk over het onderhoud. ESO pauzeerde in augustus 2025 alle releases omdat er te weinig maintainers waren. Daarna kwamen er nieuwe maintainers bij en verschijnen er weer releases in de 2.x-reeks, met external-secrets.io/v1 als API-versie. Sealed Secrets komt van Bitnami, dat bij Broadcom hoort. Broadcom verplaatste in 2025 een groot deel van de gratis Bitnami-images naar een legacy-repository zonder updates. Sealed Secrets bleef daar buiten, maar controleer welk image en welke tag je trekt. Een image uit bitnamilegacy krijgt geen patches meer.

Wat in de secrets zit, verdient net zoveel aandacht. Bij Magento is dat de encryptiesleutel uit env.php, waarmee betaalgegevens en tokens in de database zijn versleuteld. Bij Laravel is het APP_KEY. Raak je die kwijt of lekt die, dan heb je een ander probleem dan een gewijzigd wachtwoord. Zet daarnaast encryptie at rest voor Secrets in etcd aan. Bij de meeste managed aanbieders is dat een instelling, bij een zelfgebouwd cluster een EncryptionConfiguration.

De Pod Security Standards kennen drie profielen. Privileged mag alles. Baseline blokkeert de bekende escalaties, zoals hostPath-volumes, privileged containers en hostNetwork. Restricted gaat verder: non-root verplicht, geen privilege escalation, alle Linux capabilities weg en een seccomp-profiel. Je zet per namespace een label als pod-security.kubernetes.io/enforce: restricted, en daarnaast warn en audit om eerst te zien wat er zou breken.

Voor Magento en Laravel betekent restricted een paar aanpassingen in het image. PHP-FPM draait als vaste non-root user. Nginx luistert op 8080 in plaats van 80, want een poort onder 1024 vraagt een capability. Met readOnlyRootFilesystem moeten schrijfbare paden expliciet een volume krijgen: voor Magento var/ en generated alleen als je ze niet in het image bakt, voor Laravel storage/framework en bootstrap/cache.

Varnish, Valkey en OpenSearch krijgen hetzelfde profiel waar het kan. Waar een component echt meer nodig heeft, zoals een CNI-agent of een log-collector op de node, staat die in een eigen namespace met een ruimer profiel.

Pod Security Admission dekt de podconfiguratie. Voor de rest gebruiken we Kyverno, een policy engine die als admission controller elke resource controleert voordat die het cluster in gaat. Kyverno is in maart 2026 CNCF graduated geworden, de hoogste volwassenheidsstatus van de CNCF. Policies schrijf je als Kubernetes-resources, dus ze staan in Git en deployen via Argo CD.

Onze standaardset: geen images met de tag latest of zonder tag, alleen images uit je eigen registry, verplichte resource requests en limits, verplichte labels voor eigenaar en omgeving, en geen Services van het type LoadBalancer of NodePort buiten de Gateway om. Kyverno kan ook muteren, bijvoorbeeld een standaard securityContext toevoegen, en genereren, zoals automatisch een default-deny NetworkPolicy in elke nieuwe namespace.

De belangrijkste policy voor de supply chain is verifyImages: Kyverno controleert de cosign-handtekening of attestatie van een image en weigert images die niet uit jouw pipeline komen. Elke nieuwe policy zetten we eerst in Audit-modus. Kyverno meldt dan overtredingen in policy reports zonder iets te blokkeren. Pas als die rapporten leeg zijn, gaat de policy naar Enforce. Wie direct op Enforce begint, blokkeert binnen een uur zijn eigen deploy.