Wat is Container Security? Alles wat je moet weten

Container-gebaseerde systemen voegen nieuwe lagen toe aan software delivery pipelines. Het is belangrijk om het host OS, de container runtime en de containers zelf te beveiligen, omdat ze allemaal op dezelfde hosting stack draaien. Dit brengt nieuwe overwegingen met zich mee. We moeten goed nadenken over hoe we gecontaineriseerde apps bouwen en draaien.

Hoe Container Security Verschilt van Traditionele Security

Vroeger draaide cloud security vooral om het beschermen van een enkel verdedigingspunt: de perimeter. Maar met de opkomst van containerisatie is deze aanpak achterhaald. Organisaties moeten hun security strategie heroverwegen. De containeromgeving brengt nieuwe tools en uitdagingen met zich mee die sterk afwijken van traditionele beveiligingsmethoden.

De containeromgeving is complexer en dynamischer. Met containertechnologieën moeten wijzigingen upstream worden doorgevoerd, in tegenstelling tot traditionele methoden waarbij software direct op de host wordt bijgewerkt.

Bovendien heeft cloud native computing de manier veranderd waarop we applicaties ontwikkelen, deployen en beveiligen. Dit vraagt om een nieuwe aanpak, waarbij traditionele methodes steeds minder relevant worden.

En terwijl containertechnologieën steeds populairder worden, verschuiven verantwoordelijkheden naar de shift-left aanpak. Dat betekent dat containers al vanaf de vroegste fases van de CI/CD pipeline tot en met deployment en productie beveiligd moeten worden. Developers krijgen hierdoor meer verantwoordelijkheid voor security dan voorheen, bijvoorbeeld door het toepassen van infrastructure as code.

Wat maakt containers anders?

Naast het feit dat containers verschillen van virtual machines (VMs) en andere deployment methodes, verandert containerisatie de gehele applicatie lifecycle.

• Containers hebben minder afhankelijkheden van de onderliggende infrastructuur.
• Ze worden gebouwd met machine-leesbare images, waardoor verschillende besturingssystemen en applicaties op dezelfde machine kunnen draaien. Dit zorgt voor isolatie tussen applicaties en een efficiënter gebruik van resources.
• Containers zijn declaratief en voeren alleen uit wat in de code is gedefinieerd. Hierdoor gedragen ze zich voorspelbaar, en elke afwijking kan worden opgespoord als een potentiële bedreiging.
• Containers zijn vluchtig en kunnen binnen enkele seconden op- en afgeschaald worden.
• Containers zijn portabel, wat het eenvoudiger maakt om ze te deployen in multi-cloud omgevingen.

Eén probleem kan zich door alle lagen verspreiden

Wat container security bijzonder maakt, is de impact van een enkele kwetsbaarheid. Als één container image een zwakke plek bevat, zijn alle instances van die container kwetsbaar, waardoor het attack surface toeneemt. Dit probleem wordt groter naarmate er meer containers vanuit dezelfde image draaien. En met publieke image repositories kan een gecompromitteerde image zich wereldwijd verspreiden naar miljoenen machines. Bovendien wordt visibiliteit lastiger naarmate containers verspreid worden over verschillende omgevingen.

Langdurige containers: Een nieuw paradigma

Oorspronkelijk waren containers bedoeld voor kortstondige workloads die snel opstarten, een taak uitvoeren en weer afsluiten. Tegenwoordig worden containers steeds vaker gebruikt voor langdurige processen en traditionele applicaties die vroeger op een VM draaiden. Deze verandering brengt nieuwe security uitdagingen met zich mee die we niet kunnen negeren.

Container Security Risks

We kunnen de risico's van containerized applicaties opsplitsen in twee fases: voor productie (tijdens het bouwen en ontwikkelen van de app) en na deployment (wanneer de app draait en beheerd wordt).

Container Image Risico's

• Image vulnerabilities: Een container met kwetsbaarheden deployen door gebruik van een verouderde image met ingebouwde zwakke plekken.
• Image configuratieproblemen: Niet alleen softwarefouten, maar ook configuratiefouten kunnen risico’s opleveren.
• Embedded malware: Kwaadaardige bestanden van onbetrouwbare derde partijen kunnen in een image zitten en andere containers in de omgeving aanvallen.
• Embedded clear text secrets: Geheimen in het image-bestandssysteem opslaan is riskant. Iedereen met toegang tot de image kan ze eenvoudig extraheren.
• Gebruik van onbetrouwbare images: Het gemak van containerportabiliteit kan leiden tot het draaien van images uit onbetrouwbare bronnen.

Container Registry Risico's

Container registries zijn vaak vertrouwd, maar als ze worden gecompromitteerd, kan dit gevolgen hebben voor alle afgeleide containers en hosts.

• Gevoelige data blootstelling: Registries bevatten je applicatiecode, binaries en libraries. Onbeveiligde registries kunnen leiden tot ongeautoriseerde toegang of manipulatie.
• Zwakke authenticatie en autorisatie: Onvoldoende toegangscontrole kan aanvallers blootstellen aan de intellectuele eigendom van de applicatie.
• Onveilige verbindingen: Verbinden met registries via onbeveiligde kanalen verhoogt het risico op onderschepte gegevens en man-in-the-middle aanvallen.
• Verouderde images in registries: Oude images met kwetsbaarheden blijven vaak opgeslagen, wat het risico op een onbedoelde deployment vergroot.

Container Runtime Risico's

Runtime security richt zich op het identificeren van kwetsbaarheden in draaiende containers en het beschermen van applicaties tegen deze bedreigingen.

• Kwetsbaarheden in runtime apps: Sommige malware richt zich op resources van andere containers of het host OS.
• Uitgaande netwerktoegang: Een gecompromitteerde container kan netwerken scannen en andere resources blootstellen.
• Onveilige runtime instellingen: Onnodige rechten kunnen containers en het host OS kwetsbaar maken. Privileged mode maakt dit erger.
• Applicatie kwetsbaarheden: De app in de container kan zelf kwetsbaar zijn, zoals bij SQL-injectie of cross-site scripting.
• Rogue containers: Testcontainers zonder controle op kwetsbaarheden kunnen een doelwit voor aanvallers zijn.

Container Orchestration Risico's

• Kwetsbaarheden in de orchestrator stack: Orchestrators hebben vaak volledige admin-toegang, wat een risico vormt als er geen strikte toegangscontrole is.
• Onbeperkte admin toegang: Orchestrators hebben vaak een eigen directoryservice, wat kan leiden tot zwakke accountbeheer praktijken.
• Slechte inter-container netwerken: Verkeer tussen applicaties op hetzelfde virtuele netwerk kan beveiligingslekken veroorzaken.
• Verschillende gevoeligheidsniveaus mixen: Het draaien van verschillende workloads op dezelfde host kan risico’s opleveren, bijvoorbeeld wanneer een kwetsbare webserver samen met gevoelige financiële data draait.

Host OS Risico's

• Aanvalsoppervlak optimalisatie: Container-specifieke Operating Systems hebben een kleiner aanvalsoppervlak dan algemene, maar delen nog steeds een kernel.
• Kritieke systeemcomponenten: Kwetsbaarheden in cryptografie libraries of kernelprimitives kunnen alle containers op het host OS in gevaar brengen.
• Directe toegang tot de host: Het direct beheren van containers op de host, zonder orchestrator, vergroot de kans op misconfiguratie en veiligheidsrisico’s.
• Onveilige containerconfiguraties: Containers die gevoelige host directories mounten, kunnen kritieke bestanden wijzigen en de hele omgeving compromitteren.

Container Security Best Practices

Het is belangrijk om verschillende security maatregelen door de hele lifecycle van containers te implementeren, van ontwikkeling tot deployment en runtime.

Gecontaineriseerde applicaties vereisen een multi-layer defence aanpak. Laten we de beste praktijken voor container security doornemen:

Conclusie

Een magische oplossing voor container security bestaat niet. In plaats daarvan is een multi-layered defence, oftewel defence in depth, de beste aanpak.

Geen enkel systeem is perfect beveiligd, dus het gaat erom risico's te beperken op een passend niveau voor elke applicatie.