Containerbeveiliging tijdens runtime

Standaard worden processen in een Docker-container uitgevoerd als de gebruiker root, die binnen de container volledige beheerdersrechten heeft.

• Risico: Als een aanvaller controle krijgt over een container met root-rechten, kan die mogelijk kwetsbaarheden in de Docker-daemon of kernel misbruiken om root-toegang op het hostsysteem te verkrijgen.
• Best practice: Voer uw containerprocessen altijd uit als een niet-rootgebruiker.

U kunt met de vlag --user bij docker run een gebruiker (op naam of UID) voor uw containerproces opgeven. Hier voert u de opdracht id uit in een Alpine-container als gebruiker 1000.

Als gebruiker 1000 niet bestaat, gebruikt Docker die UID nog steeds.

Traditionele Linux-systemen hebben een rootgebruiker met alles-of-nietsrechten. Linux Capabilities splitsen de krachtige rootrechten op in kleinere, afzonderlijke eenheden.

Hierdoor kan een proces alleen de specifieke, op root lijkende bevoegdheden krijgen die het nodig heeft (bijvoorbeeld binden aan lage poorten of toegang tot het onbewerkte netwerk), zonder volledige rootrechten te hebben.

Docker-containers worden standaard uitgevoerd met een grote set mogelijkheden. U kunt onnodige mogelijkheden verwijderen met --cap-drop om verder te beperken wat een container kan doen.

Hier verwijderen we de mogelijkheid NET_RAW. De opdracht ping, die NET_RAW vereist, mislukt vervolgens. Daarmee wordt de beperking gedemonstreerd.

Containers delen de kernel en resources van de host. Ongecontroleerd resourcegebruik door één container kan leiden tot een Denial of Service (DoS) voor andere containers of zelfs voor de host zelf.

• CPU-limieten: Voorkom dat een container CPU-cycli monopoliseert.
• Geheugenlimieten: Voorkom dat een container al het beschikbare RAM-geheugen gebruikt en zo instabiliteit van het systeem veroorzaakt.

U kunt rechtstreeks met docker run limieten instellen voor CPU en geheugen. In dit voorbeeld wordt het geheugen beperkt tot 128 MB en het CPU-gebruik tot 0,5 (de helft van één CPU-kern).

Zo gedraagt uw container zich netjes en verhongeren andere processen niet.

Veel toepassingen hoeven na het opstarten niet naar hun rootbestandssysteem te schrijven. Door het bestandssysteem alleen-lezen te maken, krijgt u aanzienlijke beveiligingsvoordelen:

• Voorkomt manipulatie: Een aanvaller kan bestaande bestanden niet wijzigen en geen nieuwe schadelijke bestanden schrijven.
• Beperkt persistentie: Alle aangebrachte wijzigingen zijn tijdelijk en gaan verloren wanneer de container opnieuw wordt gestart.
• Dwingt onveranderlijkheid af: Bevordert een ontwerp waarbij containers wegwerpbaar zijn en de configuratie extern wordt beheerd.

Gebruik de vlag --read-only wanneer u een container uitvoert. Elke poging om naar het bestandssysteem van de container te schrijven (buiten expliciet aangekoppelde volumes) mislukt.

Probeer een bestand te maken in deze alleen-lezencontainer:

Goed gedaan! U hebt geleerd hoe u de beveiliging van containers tijdens het uitvoeren ervan kunt verbeteren:

• Minimale bevoegdheden: Ken alleen noodzakelijke machtigingen toe.
• Niet-rootgebruikers: Voorkom dat processen als root worden uitgevoerd.
• Mogelijkheden: Verwijder onnodige Linux-mogelijkheden.
• Resourcelimieten: Beperk het CPU- en geheugengebruik.
• Alleen-lezen: Maak bestandssystemen onveranderlijk om schrijven te voorkomen.

Deze werkwijzen verkleinen het aanvalsoppervlak en de gevolgen van mogelijke compromittering aanzienlijk. Blijf oefenen!