Waarom zouden containers standaard niet als root moeten draaien?

Het uitvoeren van containers als root is een van de meest voorkomende — en gevaarlijkste — misconfiguraties in productieomgevingen. Het vergroot stilzwijgend het aanvalsoppervlak van elke workload, en de meeste teams realiseren zich dit pas als een incident het probleem naar voren brengt.

Wat "als root uitvoeren" eigenlijk betekent

Standaard voeren veel containerafbeeldingen (vooral minimale of verouderde afbeeldingen) hun hoofdproces uit als UID 0 in de container. Omdat containers de hostkernel delen met andere containers en de host zelf, is root in een container niet hetzelfde als root op een volledig geïsoleerde virtuele machine — maar het is nog steeds veel krachtiger dan het zou moeten zijn. Als een aanvaller codeuitvoering bereikt in een container die eigendom is van root, erven zij:

• Volledige lees-/schrijftoegang tot alle bestanden die in de container zijn gekoppeld, ongeacht de beoogde machtigingen
• De mogelijkheid om pakketten te installeren, binaire bestanden te wijzigen of de toestand van de toepassing te manipuleren
• Een veel gemakkelijker pad naar containeruitbreking als een kernel- of runtime-kwetsbaarheid uit te buiten is
• Verhoogde hefboomwerking in combinatie met onjuist geconfigureerde volumes, zoals een gekoppelde Docker-socket of hostfilesystempad

Zelfs zonder een kernelexploit verhoogt roottoegana in de container drastisch de explosieradius van elke kwetsbaarheid op toepassingsniveau (SSRF, deserialisatiefouten, willekeurig bestandschrijven, enz.).

Waarom dit meer uitmaakt in gechoreografeerde omgevingen

In Kubernetes-clusters kunnen een rootcontainer in combinatie met buitensporige Linux-capabilities of een permissieve securitycontext een aanvaller:

• /proc of /sys op manieren wijzigen die de host beïnvloeden
• Privileges escaleren als hostPID, hostNetwork of hostIPC zijn ingeschakeld
• Een gekoppeld service account-token misbruiken om lateraal over het cluster te bewegen
• Naar het knooppunt ontsnappen als privileged: true is ingesteld of gevaarlijke capabilities zoals SYS_ADMIN zijn verleend

De rootgebruiker zelf is niet altijd de kwetsbaarheid — het is de combinatie van root plus buitensporig ruimhartige kernelcapabilities, host-mounts of namespace-sharing die een ingeperkte compromis in een clusterbreed compromis verandert.

Praktische versterkingsstappen

1. Stel een gebruiker zonder root in de afbeelding in

Definieer expliciet een gebruiker zonder root in je Dockerfile in plaats van op standaarden te vertrouwen:

FROM node:20-slim
RUN useradd --uid 10001 --shell /usr/sbin/nologin appuser
USER appuser

2. Dwing het af op orchestrator-niveau

Vertrouw niet alleen op de afbeelding — dwing het beleid af bij runtime. In Kubernetes, gebruik een securityContext:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

runAsNonRoot: true zorgt ervoor dat de pod afgewezen wordt bij opname als de afbeelding probeert uit te voeren als UID 0, wat je een harde garantie geeft in plaats van een best-effort-conventie.

3. Zet onnodige capabilities af

De meeste toepassingen hebben geen van de standaard Linux-capabilities die aan containers worden verleend. Zet alles af en voeg alleen het strikt vereiste terug toe (zeldzame gevallen zoals binding aan lage poorten hebben mogelijk NET_BIND_SERVICE nodig).

4. Vermijd geprivilegieerde modus en host-namespace-sharing

privileged: true, hostNetwork: true en hostPID: true moeten gereserveerd zijn voor zeer specifieke infrastructuurworkloads (zoals bepaalde CNI- of monitoringagenten) — nooit voor algemene toepassingscontainers.

5. Scan en zet beleid met beleidsgereedschappen af

Gebruik toegangscontrollers of beleidsengines (bijv. Kyverno, OPA/Gatekeeper) om implementaties die deze regels schenden automatisch af te wijzen, in plaats van op handmatige codebeoordeling te vertrouwen. Combineer dit met afbeeldingscanning in CI om root-user-afbeeldingen te vangen voordat ze een cluster bereiken.

Een gelaagde, niet perfecte, verdediging

Als niet-root uitvoeren elimineert het risico niet volledig — kernel-level container escapes bestaan onafhankelijk van de gebruiker in de container — maar het verwijdert een enorme klasse van laagdrempelige privilege escalation en lateral movement-technieken. In combinatie met alleen-lezen filesystemen, afgezette capabilities en restrictief netwerkbeleid vormt het een van de goedkoopste en meest effectieve lagen in een defense-in-depth containerveiligheidsstrategie.

Wil je dieper gaan op het verharden van cloud-native workloads? Verken gerelateerde Korra Studio-segmenten over cloudbeveiging en DevOps-pipelineverharding om de rest van je defense-in-depth strategie op te bouwen.