Docker containers worden steeds vaker in productie gebruikt. Het is in een productie omgeving van groot belang dat je je containers goed beveiligd. Draai je je applicates met Docker of Docker Swarm? Dan is het verstandig om in ieder geval onderstaande security best practices voor Docker op te volgen.

Beveilig je Docker host

Of je nu Docker containers op een server draait of gebruik maakt van een container orchestration tool zoals Kubernetes of Docker Swarm: het is van belang dat het platform waarop je containers draaien veilig zijn. Is het onderliggende platform lek, dan zijn je containers niet veilig. Je containers zijn weliswaar geïsoleerd, maar het onderliggende platform regelt onder andere de manier waarop containers communiceren, de storage afhandeling, networking en het isoleren van je containers. Bestaan er security issues in de node of host waar je containers op draaien, dan kan je container nog zo veilig zijn, het houdt kwaadwillenden niet buiten de deur. Het is daarom belangrijk dat de onderliggende infrastructuur up-to-date blijft.

Haal je images van een betrouwbare bron

In veel gevallen zal je zelf je container images willen maken. Bestaat er al een image dat je graag wil gebruiken, zorg dan dat dit image afkomstig is van een betrouwbare bron. Er zijn heel veel registries waar iedereen zonder verdere kwaliteitseisen images kan plaatsen. Dat kan leiden tot images met kwaadaardige code waardoor je gehacked kan worden, maar het kan ook zijn dat de software niet stabiel en daardoor niet production-ready is.

Docker Store is een repository die veel gecontroleerde software bevat. Deze images zijn door Docker geautomatiseerd getest op bekende kwetsbaarheden. Ook de images van Bitnami zijn doorgaans van goede kwaliteit.

Gebruik image signing & vulnerability scanning

Docker best practices

Vanaf Docker Engine versie 1.8 is het mogelijk om signed images te gebruiken, ook wel bekend als Docker Content Trust. Docker Content Trust garandeert de integriteit van de uitgevers en de content van de container image. Dit is in het leven geroepen om vertrouwen te vestigen tussen de uitgevers van software en de gebruikers. Op dit moment

is Docker Content Trust standaard uitgeschakeld in Docker. Wij raden je aan om dit in te schakelen. Hierdoor ben je ervan verzekerd dat de images daadwerkelijk van de uitgever komen. Zie het artikel op blog.docker.com voor meer informatie hierover.

Wil je toch gebruik maken van een container image waar je de bron niet helemaal kan achterhalen, dan kan je de container image zelf scannen op zwakheden. Op deze manier probeer je te voorkomen dat (bekende) zwakheden en kwaadaardige pakketten uitgevoerd/ingezet gaat worden als je de container image gaat gebruiken. Er zijn ook verschillende tools voor om te controleren op zwakheden zoals: Clair, Docker Bench for Security en Anchore.

Draai de applicatie in je container niet als root

Het principle of least privilege schrijft voor dat je een gebruiker of applicatie nooit meer rechten moet geven dan strict noodzakelijk. Dat maakt het systeem kwetsbaarder dan noodzakelijk is. Om die reden is het onwenselijk om processen of applicaties in je container als de gebruiker root te draaien. Als er dan een veiligheidslek in je applicatie zit waardoor kwaadwillenden onbedoelde toegang krijgen, dan zijn de in ieder geval nog gelimiteerd door de gebruikersrechten. In je Dockerfile kan je aangeven dat je aan applicatie als een bepaalde gebruiker wilt starten. Onderstaand een eenvoudig voorbeeld:

FROM ubuntu:18.04

RUN useradd appuser

USER appuser

CMD [“bash”]

In dit voorbeeld wordt de gebruiker “appuser” aangemaakt met het commando “RUN useradd”. Om vervolgens te zorgen dat het nieuwe gebruikersaccount gebruikt worden om de gewenste applicatie mee te starten, geef je de regel “USER appuser” in. Alle acties die na het commando “USER appuser” worden uitgevoerd, hebben de rechten van de gebruiker appuser. Mocht de container gehacked worden, dan wordt met deze stap privilege-escalation voorkomen.

Het is soms niet te voorkomen dat een container toegang nodig heeft om de resources van de Docker host te gebruiken. Denk hierbij aan mounts in gebieden van het bestandssysteem dat de systeemgebruiker niet kan schrijven. Vanuit een security standpunt kan je er het beste naar streven dat je deze situaties voorkomt. Voor een uitgebreid artikel met meer voorbeelden over waarom je je applicatie niet als root wilt draaien, verwijzen we je graag naar dit artikel op Medium.com.

Gebruik aanvullende beveiligingstools

In iedere Docker-update zijn weer security issues opgelost of worden nieuwe veiligheidsfeatures geïntroduceerd. Dat beschermt niet tegen onjuiste configuratie van Docker of je Docker containers. Je kunt je eigen huis nog zo goed beveiligen, als je zelf een dief binnenlaat is het snel afgelopen met je waardevolle bezittingen. Daarom kan het zinvol zijn om gebruik te maken van aanvullende security tools zoals grsecurity, AppArmor en SELinux. Elk van deze beveiligingstools biedt een extra beveiligingslaag om je Docker host verder te beveiligen.

  • grsecurity geeft een uitgebreide beveiligingsverbetering voor de Linux-kernel die bescherming biedt tegen intelligent access control, geheugenbeschadiging gebaseerde exploitatie preventie en een groot aantal andere systeem verhardingen die over het algemeen geen configuratie vereisen.
  • Met AppArmor kan een systeembeheerder een beveiligingsprofiel aan elke applicatie koppelen om de toegang tot de onderliggende systeem te beperken. De beveiligingsprofielen kunnen toegang geven tot netwerktoegang, onbeperkte socket toegang en permissies tot lezen, schrijven en uitvoeren op overeenkomende paden.
  • SELinux is een zeer geavanceerde toel om je data te beschermen. Als je dit goed configureerd, dan kan je ervoor zorgen dat je data niet gelezen of aangepast kan worden door Docker. In het geval van een groot veiligheidslek of privilege escalation, kan dan geen schade worden toegebracht aan je docker host. SELinux werkt met labels die worden gegeven aan processen, bestanden en resources van het systeem. Je kunt specifieren welke labels door Docker gelezen of aangepast mogen worden. SELinux heeft subjecten zoals een gebruiker die een command, applicatie, proces uitvoert en objecten zoals bestand, map, apparaat en interface. SELinux heeft een set van regels die bepalen tot welke objecten een subject toegang heeft. Standaard wordt de toegang geweigerd, tenzij de regels die de toegang autoriseren expliciet zijn gedefinieerd.

 

Security & Kubernetes

Maak je gebruik van Docker images op Kubernetes? Volg dan de Kubernetes Security Best Practice.