Säkerhet för Docker-containrar

Obs. övers.: Säkerhetstemat kring Docker är förmodligen ett av de eviga ämnena i dagens IT-värld. Utan vidare förklaringar presenterar vi here en översättning av en ny samling relevanta rekommendationer. Om du redan har intresserat dig för detta ämne kommer många av dem att vara bekanta för dig. Vi har också lagt till en lista över användbara verktyg och några resurser för fortsatt fördjupning.

Jag erbjuder här ett vägledande dokument för att säkra Docker. Feedback är välkommen, eftersom detta snarare är en samling utdrag från olika resurser, och inte alla har granskats noggrant. Rekommendationerna är indelade i tre kategorier:

1. Nödvändiga åtgärder inom värdoperativsystemet vid arbete med Docker;
2. Instruktioner relaterade till konfigurationsfilen för bygget och skapandet av containrar;
3. Verktyg för säkerhet som kan integreras med specifika funktioner i Docker Enterprise.

Grunden för vägledningen består av olika resurser, många av vilka anges nedan. Det kan inte kallas uttömmande, men det täcker alla grunder. Ytterligare information kan hittas i beskrivningen av CIS-testerna (länken finns i slutet av denna vägledning), samt i dokumentationen för Docker.

Docker Security Benchmark

Docker Bench for Security kontrollerar automatiskt din Docker för att säkerställa efterlevnad av de vanligaste bästa praxis. Skriptet fungerar som ett bra heuristiskt säkerhetstest, men bör inte betraktas som ett verktyg för en omfattande analys.

Värd-OS

Det är uppenbart att en Docker-container inte kan vara säker om själva värdsystemet inte är skyddat. Därför är det nödvändigt att följa bästa praxis för att säkra operativsystem. Det skulle dessutom vara klokt att genomföra en sårbarhetsanalys utöver följande rekommendationer.

Revisionsregler

Skapa och använd revisionsregler för filer relaterade till Docker, genom att använda auditctl.. Till exempel, du kan lägga till -w /usr/bin/dockerd -k docker till /etc/audit.rules och starta om revisionsservicen.

FIPS-läge

Aktivering av FIPS-läget får kryptografiska verktyg att växla till algoritmer som ingår i FIPS (amerikanska Federal Information Processing Standards — anm. red.), i enlighet med federala och branschstandarder och krav. Om värdoperativsystemet stöder FIPS-läge kan det aktiveras genom att köra följande kommandon:

sed -i 's\/GRUB_CMDLINE_LINUX="\/GRUB_CMDLINE_LINUX="fips=1 \/g' \/etc\/default\/grub
grub2-mkconfig -o \/boot\/grub2\/grub.cfg && reboot

FIPS måste också aktiveras i Docker Engine:

mkdir -p \/etc\/systemd\/system\/docker.service.d 2>&1; echo -e "[Service]n Environment=\"DOCKER_FIPS=1\"" > \/etc\/systemd\/system\/docker.service.d\/fips-module.conf; systemctl daemon-reload; systemctl restart docker

För mer information, se dokumentationen Docker och Red Hat.

Docker Secrets

Känslig information bör lagras som hemligheter. Den relevanta tjänsten kan startas med kommandot docker service create:

docker service create --label com.docker.ucp.access.label=\/prod --name nginx --publish 443 --secret source=orcabank_prod_mobile.ca.pem.v1,target=ca.pem nginx

Se detaljer i dokumentationen.

Docker-konfigurationsfilen

Följande inställningar kan läggas till i konfigurationsfilen /etc/docker/daemon.json:

• "icc":false — inaktiverar datakommunikation mellan containrar för att undvika onödig informationsläckage.
• log-level: "info" — fångar alla loggar utom debug-loggar.

• {
    "log-driver": "syslog",
    "log-opts": {
      "syslog-address": "udp:\/\/1.2.3.4:1111"
    }
  }

  — ansluter till fjärrloggning, vidarebefordrar loggarna till den angivna adressen. Fungerar endast om syslog-daemonen är igång. Både TCP och UDP accepteras som alternativ. Det är också möjligt att ansluta för varje specifik container. För detta ställs ett särskilt flagga vid start av Docker (--log-opt syslog-address=ADDRESS).

• "userns-remap": "Your_User" — förhindrar privilegied höjning (privilege escalation) genom att isolera namnområdet under en specifik användare.

Säkerhet på transportnivå

Anslutning till Docker-daemonen (om fjärråtkomst behövs) bör endast vara möjlig för användare med åtkomst till TLS-klientens autentiseringsuppgifter.

Autentiseringsplugins

Bestäm vilka användare som får köra vilka kommandon, och skapa motsvarande autentiseringsplugin för Docker. Starta sedan Docker-daemonen och lägg till pluginen:

dockerd --authorization-plugin=PLUGIN_ID

För att lära dig mer om skapande av autentiseringsplugins, se dokumentationen.

Daemonalternativ

Docker-daemonen kör med ett standardset av alternativ.

• --live-restore — detta alternativ hjälper till att minska stilleståndstiden för containrar vid avstängning eller omstart av systemet. Det blir enklare att patcha eller uppdatera dem med minimal stilleståndstid;
• --userland-proxy=false — när hairpin NAT används eller är tillgängligt, blir proxy i användarrummet en överflödig tjänst som bara ökar antalet potentiella angreppsvektorer;
• --no-new-privileges — förhindrar att containrar får ytterligare privilegier via suid eller sguid;
• --seccomp-profile /path/to/profile — om du har en egen seccomp-profil kan du tillämpa den med hjälp av denna flagga. Ta reda på mer om Seccomp och Docker här.

Konfiguration av containrar och byggfiler

Skapa användare

Se till att en användare har skapats för containern och kör den under denna användare (KÖR INTE containern som root).

Fjärråtkomst

Förbjud fjärråtkomst till demon. Om det är nödvändigt, skydda det med certifikat.

Isolera användarnamnsrymden

Det är särskilt viktigt att säkerställa att användarnamnsrymden i Docker är isolerad, eftersom den som standard delas med värdens namnutrymme. I vissa fall kan detta utnyttjas för att höja privilegierna eller till och med för att komma utanför containern. Användarnamnsrymden kan isoleras genom att redigera konfigurationsfilen (som beskrivits ovan i avsnittet "Docker-konfigurationsfil"). Ytterligare nämning av detta problem här har att göra med dess betydelse.

Healthchecks

Healthcheck (livskontroll) är ett kraftfullt verktyg för att kontrollera en containers integritet. Den konfigureras i Dockerfile med hjälp av instruktionen HEALTHCHECK. Healthchecks gör att vi kan säkerställa att containern fungerar korrekt. I följande exempel avslutas livskontrollen med 0 om servern fungerar och 1 om den "har kraschat":

HEALTHCHECK CMD curl --fail http://localhost || exit 1

SELinux

Om SELinux stöds av värdsystemet, skapa eller importera en SELinux-policy och kör Docker i demonläge med SELinux aktiverat:

docker daemon --selinux-enable

I det här fallet kan Docker-containrar köras med säkerhetsinställningar, till exempel:

docker run --interactive --tty --security-opt label=level:TopSecret centos /bin/bash

Nätverksgränssnitt

Som standard lyssnar Docker på alla nätverksgränssnitt. Eftersom trafik i de flesta fall förväntas endast på ett av dem, är en sådan metod oansvarig och ökar attackrisken. Därför kan portar för containern kopplas till specifika gränssnitt på värden:

docker run --detach --publish 10.2.3.4:49153:80 nginx

Cacheade versioner av bilder

När du laddar ner bilder, se till att den lokala cachen motsvarar innehållet i repositoriet. Annars kan du få en föråldrad version av bilden eller en bild som innehåller sårbarheter.

Nätverksbro

Standard nätverksmodell, docker0, sårbar för ARP-spoofing och MAC-flooding-attacker. För att lösa detta problem, skapa en nätverksbro enligt dina specifikationer, som beskrivs här.

Docker-socketvarning

Överför aldrig Docker-socketen in i containern. Annars får containern möjlighet att köra Docker-kommandon och därmed kommunicera med värdsystemet och kontrollera det. Gör inte detta.

Konfigurering av Docker Enterprise

Docker Trust

Docker Trust gör det möjligt att generera nycklar som kan användas för att verifiera den kryptografiska integriteten av bilder. Docker Trust-nycklar kan användas för att signera Docker-bilder med privata nycklar, som verifieras med offentliga nycklar på Notary Server. Mer information — här. Aktivering av Docker Trust i Enterprise Engine beskrivs i detalj i detta avsnitt av dokumentationen.

Sårbarhetsskanning

Docker Enterprise har en inbyggd sårbarhetsskanner som ger möjlighet att ladda ner CVE-databasen för offline-skanning av sårbarheter i bilder. Regelbunden skanning av bilder hjälper till att göra dem säkrare: användaren får omedelbara varningar om upptäckta sårbarheter. Mer om hur detta kan göras, se här.

Obs. övers.: Det finns även Open Source-sårbarhetsskannrar för Docker-bilder, exempel på vilka finns i slutet av materialet.

Integration av LDAP och UCP

Universal Control Plane kan integreras med LDAP. Resultatet blir ett förenklat autentiseringystem som möjliggör att undvika onödig duplicering. Mer om detta kan läsas i artikeln Integrate with an LDAP directory.

Övriga resurser

Ytterligare information om bästa praxis för säkerhet i Docker finns på docs.docker.com. Vi rekommenderar också att ladda ner Center for Internet Security:s tester för Docker.

Översättarens bonus

Som ett logiskt tillägg till denna artikel publicerar vi en lista med 10 populära Open Source-verktyg för säkerhet i Docker. Den har hämtats från en annan artikel (av Bill Doerrfeld från Doerrfeld.io).

NB: Läs mer om många av de projekt som nämns här i artikeln "33+ verktyg för Kubernetes-säkerhet».

1. Docker Bench for Security – redan nämnd i början av artikeln, är ett skript som kontrollerar Docker-containrar för att säkerställa överensstämmelse med allmänt vedertagna säkerhetsmetoder.

   

2. Clair – förmodligen det mest populära verktyget för statisk sårbarhetsanalys i containrar. Det använder en mängd CVE-sårbarhetsdatabaser (inklusive spårare från ledande Linux-distributioner som Red Hat, Debian, Ubuntu). Erbjuder ett API för utvecklare och en enkel lösning för att utöka funktioner (genom att lägga till "drivrutiner"). Används i det populära offentliga registreringssystemet för containrar (motsvarighet till Docker Hub) – Quay.io.
3. Cilium – en lösning för att säkerställa nätverkssäkerhet på kärnnivå, baserat på teknik för paketfiltrering BPF.
4. Anchore – verktyg för att analysera bildinnehåll för säkerhetssårbarheter enligt CVE-databasen. Dessutom möjliggör det tillämpning av användardefinierade policyer (baserade på olika data inklusive vita/svarta listor, filinnehåll, etc.) för att bedöma säkerheten hos containrar.
5. OpenSCAP Workbench – ett helt ekosystem för att skapa och underhålla säkerhetspolicyer på olika plattformar. För att kontrollera containrar erbjuder det verktyget oscap-docker.
6. Dagda – ett verktyg för att skanna Docker-containrar för sårbarheter, trojaner, virus och malware. Databasen CVE inkluderar kontroller för beroenden från OWASP, Red Hat Oval-databasen, samt Exploit Database-repositoriet.
7. Notary – ett ramverk för att signera Docker-bilder, ursprungligen skapat av Docker Inc (och sedan överfört för vidareutveckling till CNCF). Dess användning gör det möjligt att delegera roller och fördela ansvar för containrar, samt verifiera den kryptografiska integriteten hos bilder.
8. Grafaes – ett API för metadata som syftar till att hantera interna säkerhetspolicyer. Som exempel gör det det möjligt att förbättra säkerhetsskannerns funktionalitet för containrar. Shopify använder detta API för att hantera metadata för sina 500 000 bilder.
9. Sysdig Falco – ett verktyg för Kubernetes som övervakar systembeteende: aktivitet i containrar, på värdar, i nätverket. Möjliggör inställning av kontinuerliga kontroller i infrastrukturen, upptäckta anomalier och notifieringar om alla Linux-systemanrop.
10. Banyanops Collector — ett annat verktyg för statisk analys av Docker-kontaineravbilder. Gör det möjligt att "titta" in i avbildsfiler, samla nödvändig information, tillämpa önskade policyer osv.

Ytterligare en bra samling praktiska rekommendationer om hur man gör Docker säkrare kan hittas hos denna artikel företaget Aqua Security. Många av deras råd överlappar med de som redan nämnts ovan, men det finns också andra. Till exempel föreslår författarna att organisera övervakning av aktiviteten i containrarna och pekar på vad man ska vara uppmärksam på vid användning av Docker Swarm.

För de som vill dyka djupare in i detta ämne publicerades förra året boken "Docker Security: Quick Reference»", vars utdrag är fritt tillgängliga här.

Slutligen, för en praktisk bekantskap med vissa aspekter av Docker-säkerhet: Seccomp-profiler och användning av Linux-kärnans capabilities i containrar — kan man genomföra relevanta laboratorieövningar på resursen Play with Docker* — se avsnittet "Security".

* Om denna resurs skrev vi om hur de tillämpar teknologin för en ovanlig uppgift — att hitta fel i rubriker.) I slutändan lyckades vi automatisera upp till 90 % av flödet beroende på tjänsten. för två år sedan, och i november 2018 hände det något mycket intressant (ur säkerhetssynpunkt) med den. Kort sagt lyckades experter från CyberArk Software Ltd. hacka den: uppnå möjligheten att köra kommandon utanför containrar, dvs. på värdsystemet. En utmärkt illustration av säkerhetsproblemet i Docker, eller hur? Läs om alla detaljer i den händelsen här.

P.S. från översättaren

Läs även i vår blogg:

• «Vulnerable Docker VM — en utmaning kring Docker och pentesting»;
• «I 19% av de mest populära Docker-avbildningarna finns det inget lösenord för root»;
• «33+ verktyg för Kubernetes-säkerhet»;
• «Docker och Kubernetes i säkerhetskrävande miljöer»;
• «9 bästa praxis för att säkerställa säkerheten i Kubernetes»;
• «OPA och SPIFFE — två nya projekt i CNCF för säkerheten av molnapplikationer».

Källa: habr.com