Containers en Docker – Huh?

In deze post wil ik kort kijken naar het begrip “containerisatie” ofwel het werken met containers. Als we het hebben over containers ontkomen we ook niet aan de termen “Docker” en “Kubernetes”. In de basis zijn containers volledige runtime omgevingen voor een dedicated doel. Met andere woorden, een container bevat een applicatie incl. de benodigdheden om te kunnen draaien en deze is volledig onafhankelijk van onderliggend OS of gebruikte architectuur. Laten we eens even verder kijken naar deze steeds vaker toegepaste techniek.

Containers zijn ontstaan vanuit development behoefte en ik denk dat we allemaal de pijn herkennen van “dependencies”. “Deze software werkt niet op dit systeem wan hierop draait versie X van product Y”. Soms is zelfs het OS systeem zelf een blokkerende factor. Docker ontwikkelaar “Solomon Hykes” zei het heel mooi, “Problemen ontstaan als de ondersteunende softwareomgeving niet identiek is”. Een container bundelt de applicatie tezamen met alle dependencies, configuratiebestanden, binaries en libraries zodat de applicatie kan functioneren. Deze container kan vervolgens beschikbaar worden gesteld door een container systeem de zogenaamde “Container Runtime”. Deze container runtime draait op een host en containers zullen resources van deze host gebruiken. Dit lijkt op het principe van een virtuele machine maar een container is veel efficiënter dan een virtuele machine.

• Containers hebben een veel lichtere beheer last dan VM’s (het zijn immers geen OSen die gepatched en geüpdate moeten worden)
• Containers gaan veel beter om met resources (Geen OS systeem en virtuele hardware welke system resources van de host verbruikt)
• Container starten veel sneller op dan VM’s

In de praktijk zie je dat containers veel beter performen en dat je 2 tot 3 maal zoveel toepassingen kunt draaien op 1 server als je containers gebruikt i.p.v. VM’s.

En dan komen we meteen tot het grootste nadeel van containers en dat is de beveiliging. Virtual Machines draaien in een eigen geïsoleerde omgeving (OS) welke door de hypervisor laag beheerd en beveiligd wordt. Het virtuele OS voorziet de applicatie van de benodigde resources en komt nooit in aanraking met het host OS (zonder tussenkomst van de hypervisor). Een docker image heeft toegang tot 5 namespaces (kernel resource partities (processen)) van het hostOS, namelijk “Process, Network, Mount, Hostname en Shared Memory”. Maar belangrijke subsystemen (van Linux) zijn niet namespaced zoals:

• SELinux
• Cgroups
• file systems under /sys
• /proc/sys, /proc/sysrq-trigger, /proc/irq, /proc/bus
• /dev/mem
• /dev/sd* file system devices
• Kernel Modules

In theorie betekend dit dus dat wanneer een user binnen een container superuser rechten heeft, hij deze onderdelen van het host OS kan benaderen en aanvallen.

Uiteraard zijn containers wel te beveiligen maar hier moet veel moeite voor gedaan worden. De basisregels bij containerbeveiliging zijn:

• Gebruik netwerk segmentatie om containers op basis van hun vertrouwen, risico en blootstelling te separeren van elkaar
• Pas virusscanning en malicious bahaviour scanning toe op containers voor en tijdens ze opgestart zijn
• Beperk de toegangsrechten zo veel mogelijk
• Draai services al seen dedicated service user en niet als root/superuser gebruiker
• Behandel de root binnen een container alsof het de root van je host OS is
• Pas alle security settings aan zodat deze zo strak mogelijk ingesteld staan. Denk aan registry scanning, container privileges etc.
• Hou de host en de container altijd up-to-date
• Verzamel logging van je containers en analyseer deze
• Overweeg een third party dedicated container security appliance

Kortom… er zit niet heel veel verschil tussen het toepassen van security binnen een container of binnen een VM.

En dan kennen containers nog wat andere nadelen zoals wildgroei (het is zo makkelijk en snel dus uitrollen maar), of het draaien van meerdere toepassingen in een container (waardoor het nut van de container verdwijnt en je beter meteen een VM had kunnen gebruiken). Een ander probleem is transparantie. Bij een grote verscheidenheid van containers worden ook afhankelijkheden tussen verschillende containers gemaakt. Als deze afhankelijkheden niet heel goed inzichtelijk zijn dan zullen er zich zeker problemen voordoen. Stel er draaien 2 apps op 1 apache server (allen in een container) en de beheerder kent slechts 1 app en gaat Apache updaten naar een versie die niet compatible is met de andere app. Ga dan maar eens zoeken.

Dus wil je meerdere toepassingen bundelen en uitvoeren, gebruik een virtuele machine. Wil je 1 toepassing uitvoeren in een onafhankelijk omgeving of als je meerdere exemplaren van dezelfde applicatie wilt uitvoeren (databases) gebruik dan een container. Containers zijn erg praktisch en niet meer weg te denken maar worden vaak foutief ingezet en geconfigureerd.

Tot zover het beveiligingsaspect van containers. Er zijn namelijk meerdere soorten containers. Iedereen associeert de term “Docker” met containerisatie omdat Docker momenteel het meest succesvol is in het propageren van containers. Containers zijn echter niet nieuw. Container technologie zit al meer dan 10 jaar in Linux in de vorm van LXC. Er zijn vele vergelijkbare technologieën zoals OpenVZ, BSD Jails en Solaris Zones.

In 2015 is de OCI (Open Container Initiative) opgericht met als doel om een industriële container specificatie te ontwikkelen welke zou bestaan uit een container runtime specificatie en een container format specificatie. Het startpunt van dit initiatief was echter Docker technologie. OCI is momenteel een belangrijke standaard als het gaat over de manier waaraan containers moeten voldoen.

Voor het gros van de container technologieën kunnen we stellen dat Linux nog steeds dominant is. Microsoft kent nu de “Windows Server Containers” welke feitelijk gebaseerd is op Docker.

Een container die aangemaakt is binnen een specifieke runtime is meestal niet uitwisselbaar met een andere runtime.

Mocht je enthousiast zijn om containers te gaan gebruiken dan kun je in principe elke Linux distributie gebruiken. Om echter niets meer dan alleen containers te hosten dan kun je beter kiezen voor een dedicated Linux OS zoals Container Linux, Photon OS of simpelweg de Ubuntu Core.

Om toch voor voldoende overzicht te zorgen zijn er bepaalde container management tools. Management tools zorgen ervoor dat containers gemakkelijk gemaakt en beheerd kunnen worden. Ze zorgen er tevens voor dat specifieke taken gescheduled kunnen worden en dat er gecentraliseerde logging plaatsvind. Een ander belangrijk voordeel is dat container manager dynamisch resources kunnen toekennen aan de containers en het plaatsen van containers in bepaalde clusters voor b.v. failover management.

De bekendste is misschien we de open-source oplossing van Google genaamd “Kubernetes”. Kubernetes bestaat sinds 2014 en is (in verhouding met de andere) een van de oudste producten. Een andere bekendere (zonder afdoende resource management) is Docker Swarm (uiteraard alleen voor Docker). Daarnaast hebben we nog Mesos van Apache (voor Docker en AppC), Tectonic, Open Shift Container en vele andere.

Conclusie

Omdat we in de toekomst wat meer met containers gaan doen leek het me interessant om deze algemene post te maken. Containers zijn een oplossing voor diverse problemen en maken het makkelijker om diverse applicaties naast elkaar te draaien in hun eigen runtime omgeving zonder afhankelijkheid van andere applicatie en dependencies die elkaar in de weg kunnen zitten. Version management is essentieel maar heel goed te managen voor containers. Containers kennen echter ook diverse nadelen die virtuele machines niet hebben en dus is het zaak om per opdracht te kijken naar de juiste invulling. Soms zal dit een container zijn maar vaak ook gewoon een virtuele machine. Momenteel zijn de Docker containers de way-to-go welke weer prima te beheren zijn met Kubernetes. Ga zelf eens experimenteren! Dit is waarom ICT zo leuk blijft. Nieuwe technieken blijven het landschap hervormen… en de meningen verder verdelen 😉

Vond je deze post interessant en heb je er iets van opgestoken dan zou ik het super fijn vinden als jij deze post waardeert door hem te delen op je sociale kanalen of op je website. Of like hem even? Deze acties geven we weer nieuwe arbeidsvitaminen om aan de volgende post te beginnen! Yeah!