Undersøgelse af den (manglende) sikkerhed for typiske Docker- og Kubernetes-installationer

Undersøgelse af den (manglende) sikkerhed for typiske Docker- og Kubernetes-installationer
Jeg har arbejdet med IT i mere end 20 år, men på en eller anden måde kom jeg aldrig til containere. I teorien forstod jeg, hvordan de var opbygget, og hvordan de fungerede. Men da jeg aldrig havde stødt på dem i praksis, var jeg ikke sikker på, hvordan gearene under deres motorhjelm præcist drejede og drejede.

Desuden anede jeg ikke, hvordan deres sikkerhed var. Men igen, teorien lyder fint, og den gamle sang "i takt med at sikkerheden stiger, falder brugervenligheden" fast i mit hoved. Så jeg tænkte, at da alt er så nemt at gøre med containere, så er sikkerheden der under pari. Som det viser sig, havde jeg ret.

For at komme hurtigt i gang har jeg tilmeldt mig kurser Sort hat 2020 med titlen "Fra klude til rigdom: penetration og beskyttelse af Docker Swarm og Kubernetes miljøer'.

Kurset, som blev undervist af Sheila A. Berta og Sol Ozzan, begyndte straks med en beskrivelse af, hvordan Docker-containere fungerer, og den rejse, de tager, når de udsættes til Kubernetes. Dette var en helt praktisk klasse - eleverne skulle installere Docker og microk8s på deres maskiner før klassen - en fantastisk måde at se, hvordan værktøjerne interagerer med hinanden, finde svage punkter og, vigtigst af alt, prøve at blokere dem.

Selvom kurserne lovede at blive en "prins" efter to dage, følte jeg desværre, at alt lige var begyndt, og jeg havde stadig meget at lære.

Undersøgelse af den (manglende) sikkerhed for typiske Docker- og Kubernetes-installationer

Før du dykker ned i mine høje observationer, er det vigtigt at forklare, hvad en container er. I udviklingsverdenen anses det for at være normalt, at den kode, der er skrevet på din personlige maskine, fungerer perfekt, men når du forsøger at køre den på en server et eller andet sted, virker det simpelthen ikke. Containere forsøger at overvinde dette problem ved at levere selvstændige maskiner, som du nemt kan flytte fra en server til en anden, vel vidende at de altid vil fungere. Som navnet antyder, indeholder de koden, bibliotekerne og anden software, der er nødvendig for at få arbejdet gjort. Det er Kubernetes derimod orkestreringsplatform til containere. I princippet kan den bruges til problemfrit at håndtere hundreder eller tusindvis af forskellige containere.

Nedenfor er nogle af mine resultater fra det røde og blå holds perspektiv.

Rødt hold

Det meste containerindhold kører som root: Det betyder, at hvis containeren er kompromitteret, vil du have fuld adgang til containeren. Dette gør de næste trin meget nemmere.

Det er farligt at montere docker.sock inde i en container: Hvis du har root inde i en container og også installeret Docker inde i en container, der har en Docker-socket (/var/run/docker.sock), har du potentialet til at udforske hele klyngen, inklusive adgang til enhver anden container. Sådan adgang kan ikke forhindres ved netværksisolering eller på anden måde.

Miljøvariabler indeholder ofte hemmelige data: I de fleste tilfælde sender folk adgangskoder til containeren ved hjælp af normale miljøvariabler. Så hvis du har adgang til kontoen, kan du spionere på disse miljøvariabler for senere at udvide dine beføjelser.

Docker API kan give en masse information: Docker API, når det er konfigureret som standard, kører uden autorisation og kan producere et væld af information. Ved at bruge Shodan kan du nemt finde en liste over åbne porte, derefter få detaljerede oplysninger om klyngen - og fortsætte til dens fulde indfangning. TrendMicro skrev om dette mest interessante artikel.

Blå hold

Kør ikke containerindhold som root: Selvom det er nemmere at køre som root, bør du ikke gøre det. Kør i stedet applikationer med nulstillingstilladelser ved at vise uid, enten ved at bruge --user-indstillingen, når du kører fra CLI, eller ved at angive USER i Dockerfilen.

Tillad ikke, at software installeres i containere: Næsten hvert angreb starter med at plante noget. Fra nmap til ifconfig til selve Docker (inde i en container) har det været almindeligt at installere alt i en container. Af samme grund bør du altid blokere alle ubrugte porte. Dette hjælper også med at forhindre kontrolkommandoer i at blive transmitteret, når din maskine er inficeret. Ud over at forhindre installation af programmer er det værd at sørge for, at det mindste antal applikationer, der kræves for at fuldføre opgaven, er installeret i selve containeren.

Beskyt docker.sock: Den skal beskyttes, fordi kommunikationen mellem beholderen og klyngen behandles gennem denne socket. Da jeg ikke ønsker at gå i detaljer i denne artikel, så læs notat fra Docker, hvad der kan ske, og også hvordan man blokerer det hele.

Brug Docker-hemmeligheder i stedet for miljøvariabler: Der er hemmeligheder siden omkring 2017. Selvom dette ikke er sikkert, er det stadig bedre end miljøvariabler til at sende hemmelige data til containeren.

Hvis artiklen har vakt din interesse for containere, kan du nemt installere Docker eller microk8s (en lille version af Kubernetes). Her der er instruktioner til installation af Docker til Linux og MacOS, og her — instruktioner til installation af microk8s til Windows, Linux og MacOS.

Efter installationen kan du gå dette er en hurtig startguide fra Docker, lignende mulighed tilbydes og til microk8s.

Hvis du ønsker eller har brug for at tage et omfattende kursus om Docker, hvor praktiske foredragsholdere undersøger alle dets værktøjer: fra grundlæggende abstraktioner til netværksparametre, nuancer af at arbejde med forskellige operativsystemer og programmeringssprog, så prøv "Docker video kursus" Du vil blive fortrolig med teknologien og forstå, hvor og hvordan du bedst bruger Docker. Og få samtidig best practice-cases - det er bedre at lære i sikkerhed og med støtte fra praktikere fra historier om river end personligt fra selve riverne med piggede håndtag.

Kilde: www.habr.com

Tilføj en kommentar