
Jeg har arbejdet i IT i mere end 20 år, men jeg har aldrig fået arbejdet med containere. Teoretisk forstod jeg, hvordan de fungerer, og hvordan de arbejder. Men da jeg aldrig har mødt dem i praksis, var jeg ikke sikker på, hvordan tandhjulene svinger under motorhjelmen.
Derudover havde jeg ingen anelse om, hvordan det står til med sikkerheden. Men igen, teoria lyder smukt, og det gamle ordsprog "da sikkerheden vokser, falder brugervenligheden" sad fast i mit hoved. Så jeg tænkte, at når det er så let at arbejde med containere, så må sikkerheden være under minimum. Som det viste sig, havde jeg ret.
For en hurtig start tilmeldte jeg mig et kursus i 2020 med titlen "».
Kurset, der blev undervist af Sheila A. Berta og Sol Ozzan, startede straks med at beskrive, hvordan Docker-containere fungerer, samt hvilken vej de tager ved implementering i Kubernetes. Det var en helt praktisk session - deltagerne skulle have installeret Docker og microk8s på deres maskiner inden kurset - en fremragende måde at se, hvordan værktøjerne interagerer, finde svagheder og, vigtigst af alt, prøve at blokere dem.
Desværre, selvom kurserne lovede at gøre mig til "kongen" efter to dage, følte jeg, at det hele kun lige var begyndt, og jeg stadig havde meget at lære.

Før jeg dykker ned i mine høje observationer, er det vigtigt at forklare, hvad en container er. I udviklingsverdenen anses det som normalt, at koden, der er skrevet på din egen maskine, fungerer perfekt, men når man prøver at køre den et eller andet sted på en server, så virker den bare ikke. Containere forsøger at overvinde dette problem ved at tilbyde autonome maskiner, som du nemt kan flytte fra server til server og vide, at de altid vil fungere. Som navnet antyder indeholder de koden, bibliotekerne og andet software, der er nødvendigt for at arbejde. Kubernetes, på den anden side, er . I princippet kan man bruge det til ubesværet at styre hundreder eller tusinder af forskellige containere.
Her er nogle af mine konklusioner set fra et rødt og blåt teams perspektiv.
Rødt team
De fleste indhold i containerne kører under root: det betyder, at hvis du kompromitterer containeren, får du fuld adgang til containeren. Det gør de efterfølgende skridt betydeligt lettere.
Montering af docker.sock indeni containeren er farligt: hvis du har fået rootadgang i containeren, og også har installeret Docker inden i en container med Docker-socketen (/var/run/docker.sock), har du en potentiel mulighed for at udforske hele klyngen, inklusive adgang til enhver anden container. Denne adgang kan ikke forhindres hverken ved netværksisolering eller på andre måder.
Miljøvariabler indeholder ofte hemmelige data: i de fleste tilfælde sender folk adgangskoder ind i containeren ved hjælp af almindelige miljøvariabler. Så hvis du har adgang til kontoen, kan du søge disse miljøvariabler for at udvide dine rettigheder senere.
Docker API kan udlevere en masse information: Docker API, når det er konfigureret som standard, fungerer uden godkendelse og kan udlevere en masse information. Ved at bruge Shodan kan du nemt finde en liste over åbne porte, dernæst få detaljeret information om klyngen — og gå videre til dens fulde overtagelse. TrendMicro har skrevet en .
Den blå team
Kør ikke containerindhold som root: på trods af at det er lettere at køre som root, skal du ikke gøre det. I stedet skal du køre applikationer med nedsatte rettigheder ved at angive uid, enten ved hjælp af parameteren —user, når du arbejder med CLI, eller ved at angive USER i Dockerfile.
Tillad ikke installation af programmer i containerne: næsten hver angreb starter med installation af noget. Fra nmap til ifconfig og selve Docker (inden i containeren) har installation af noget i containeren været en almindelig praksis. Af samme grund skal alle ubrugte porte altid blokeres. Dette hjælper også med at forhindre overførsel af kontrolkommandoer, hvis din maskine bliver inficeret. Udover at forhindre installation af programmer, er det vigtigt at sikre, at der i selve containeren kun er installeret det minimale antal applikationer, der er nødvendige for at udføre opgaven.
Beskyt docker.sock: det skal beskyttes, da kommunikationen mellem containeren og klyngen behandles gennem denne socket. Da jeg ikke ønsker at gå ind i detaljerne i denne artikel, læs venligst , hvad der kan ske, samt hvordan man kan blokere alt dette.
Brug Docker-hemmeligheder i stedet for miljøvariabler: Der er hemmeligheder . Selvom det ikke er sikkert, er det stadig bedre end miljøvariabler til at overføre hemmelige data til containeren.
Hvis artiklen har vakt din interesse for containere — kan du forholdsvis nemt installere Docker eller microk8s (en lille version af Kubernetes). Der findes installationsvejledninger til Docker for Linux og MacOS, og — installationsvejledninger til microk8s for Windows, Linux og MacOS.
Efter installationen kan du følge fra Docker, en lignende version findes også for microk8s.
Hvis du har lyst eller behov for at gennemføre et omfattende kursus i Docker, hvor praktiserende talere gennemgår alle dets værktøjer: fra grundlæggende abstraktioner til netværksindstillinger, detaljerne i arbejdet med forskellige operativsystemer og programmeringssprog, så prøv "". Du vil lære teknologien at kende og forstå, hvor og hvordan Docker bedst kan bruges. Og samtidig få best practice cases — det er bedre at lære i sikkerhed og med praktisk støtte på historier om at snuble over det, end selv at snuble over de samme problemer med spidse håndtag.
Kilde: habr.com
