Ik werk al meer dan twintig jaar in de IT, maar op de een of andere manier ben ik nooit aan containers toegekomen. In theorie begreep ik hoe ze waren gestructureerd en hoe ze werkten. Maar aangezien ik ze in de praktijk nog nooit was tegengekomen, wist ik niet zeker hoe de tandwielen onder hun motorkap precies draaiden en draaiden.
Bovendien had ik geen idee hoe hun veiligheid was. Maar nogmaals, de theorie klinkt leuk, en het oude liedje ‘naarmate de beveiliging toeneemt, neemt de bruikbaarheid af’ bleef in mijn hoofd hangen. Dus ik dacht dat omdat alles zo gemakkelijk te doen is met containers, de veiligheid daar onder de maat is. Het bleek dat ik gelijk had.
Om snel van start te gaan, heb ik mij aangemeld voor cursussen 2020 getiteld ".
De cursus, gegeven door Sheila A. Berta en Sol Ozzan, begon onmiddellijk met een beschrijving van hoe Docker-containers werken en de reis die ze afleggen wanneer ze worden ingezet in Kubernetes. Dit was een volledig praktijkgerichte les - studenten moesten Docker en microk8s vóór de les op hun machines installeren - een geweldige manier om te zien hoe de tools met elkaar omgaan, zwakke punten te vinden en, belangrijker nog, te proberen ze te blokkeren.
Hoewel de cursussen beloofden na twee dagen een 'prins' te worden, had ik helaas het gevoel dat alles nog maar net was begonnen en dat ik nog veel te leren had.
Voordat ik inga op mijn verheven observaties, is het belangrijk om uit te leggen wat een container is. In de ontwikkelingswereld wordt het als normaal beschouwd dat de code die op uw persoonlijke computer is geschreven perfect werkt, maar als u deze ergens op een server probeert uit te voeren, werkt dit eenvoudigweg niet. Containers proberen dit probleem te ondervangen door op zichzelf staande machines aan te bieden die u gemakkelijk van de ene server naar de andere kunt verplaatsen, in de wetenschap dat ze altijd zullen werken. Zoals de naam al doet vermoeden, bevatten ze de code, bibliotheken en andere software die nodig is om de klus te klaren. Kubernetes daarentegen wel . In principe kan het worden gebruikt om honderden of duizenden verschillende containers naadloos te beheren.
Hieronder staan enkele van mijn bevindingen vanuit het perspectief van het rode en blauwe team.
rode team
De meeste containerinhoud wordt als root uitgevoerd: Dit betekent dat als de container wordt gecompromitteerd, u volledige toegang tot de container heeft. Dit maakt de volgende stappen een stuk eenvoudiger.
Het monteren van docker.sock in een container is gevaarlijk: Als je root in een container hebt en Docker ook hebt geïnstalleerd in een container met een Docker-socket (/var/run/docker.sock), heb je de mogelijkheid om het hele cluster te verkennen, inclusief toegang tot elke andere container. Dergelijke toegang kan niet worden voorkomen door netwerkisolatie of andere middelen.
Omgevingsvariabelen bevatten vaak geheime gegevens: In de meeste gevallen sturen mensen wachtwoorden naar de container met behulp van normale omgevingsvariabelen. Dus als u toegang heeft tot het account, kunt u deze omgevingsvariabelen bespioneren om later uw bevoegdheden uit te breiden.
Docker API kan veel informatie vrijgeven: De Docker API werkt, indien standaard geconfigureerd, zonder autorisatie en kan een hoop informatie produceren. Met Shodan kunt u eenvoudig een lijst met open poorten vinden, gedetailleerde informatie over het cluster verkrijgen en doorgaan met de volledige vastlegging ervan. TrendMicro schreef hierover .
Blauwe team
Voer de containerinhoud niet uit als root: Ook al is het gemakkelijker om als root te draaien, je zou het niet moeten doen. Voer in plaats daarvan applicaties uit met reset-machtigingen door de uid weer te geven, met behulp van de optie --user wanneer deze wordt uitgevoerd vanuit de CLI, of door USER op te geven in het Docker-bestand.
Sta niet toe dat software in containers wordt geïnstalleerd: Bijna elke aanval begint met het planten van iets. Van nmap tot ifconfig tot Docker zelf (in een container), het installeren van alles in een container is gebruikelijk. Om dezelfde reden moet u altijd alle ongebruikte poorten blokkeren. Dit helpt ook voorkomen dat besturingsopdrachten worden verzonden wanneer uw machine is geïnfecteerd. Naast het voorkomen van de installatie van programma's, is het de moeite waard ervoor te zorgen dat het minimale aantal applicaties dat nodig is om de taak te voltooien, in de container zelf is geïnstalleerd.
Bescherm docker.sok: Het moet worden beveiligd omdat de communicatie tussen de container en het cluster via deze socket wordt verwerkt. Omdat ik in dit artikel niet in detail wil treden, lees het , wat er kan gebeuren, en ook hoe je dit allemaal kunt blokkeren.
Gebruik Docker-geheimen in plaats van omgevingsvariabelen: Er zijn geheimen . Hoewel dit niet veilig is, is het nog steeds beter dan omgevingsvariabelen voor het doorgeven van geheime gegevens aan de container.
Als het artikel uw interesse in containers heeft gewekt, kunt u eenvoudig Docker of microk8s (een kleine versie van Kubernetes) installeren. er zijn instructies voor het installeren van Docker voor Linux en MacOS, en — instructies voor het installeren van microk8s voor Windows, Linux en MacOS.
Na de installatie kunt u aan de slag van Docker, soortgelijke optie en voor microk8's.
Als je een uitgebreide cursus over Docker wilt of moet volgen, waarin praktische sprekers alle tools ervan onderzoeken: van basisabstracties tot netwerkparameters, nuances van het werken met verschillende besturingssystemen en programmeertalen, probeer dan “" Je raakt vertrouwd met de technologie en begrijpt waar en hoe je Docker het beste kunt gebruiken. En krijg tegelijkertijd praktijkvoorbeelden: het is beter om veilig en met de steun van praktijkmensen te leren van verhalen over harken dan persoonlijk van de harken zelf met puntige handvatten.
Bron: www.habr.com