De IT-wereld verandert snel encontainers en Kubernetes (K8s) worden steeds populairder. In slechts zeven jaar tijd zijn we van virtuele machines overgestapt op containers en vervolgens op een platform voor containerorkestratie (de eerste Docker-versie werd in 2013 gelanceerd). Sommige start-ups zijn nog aan het leren hoe ze deze nieuwe resources kunnen gebruiken en gevestigde bedrijven onderzoeken hoe ze hun bestaande systemen kunnen migreren naar efficiëntere infrastructuren.

De snelle overstap naar containers en Kubernetes geeft al aan hoe baanbrekend deze technologieën zijn. Ze hebben echter ook voor nieuwe beveiligingsproblemen gezorgd. Door hun grote populariteit en het feit dat veel organisaties nog niet over goede beveiligingsmaatregelen beschikken, zijn containers en Kubernetes een perfect doelwit geworden voor aanvallers.

Een K8s-cluster is een set computers die wordt beheerd door een hoofdknooppunt (en de replica’s hiervan). Zo’n cluster kan duizenden computers en services omvatten en daardoor een belangrijke attack vector worden. Daarom zijn strenge beveiligingspraktijken cruciaal.

Uw cluster beveiligen

Een Kubernetes-cluster bestaat uit veel bewegende onderdelen die allemaal goed beveiligd moeten worden. Het cluster kan uiteraard niet met één proces beveiligd worden. Om de veiligheid van het hele cluster te waarborgen, moeten verschillende best practices worden toegepast en hiervoor is een bekwaam beveiligingsteam nodig.

Hieronder bespreken we een aantal verschillende attack vectors voor Kubernetes en best practices om uw K8s-cluster veilig te houden.

Hou Kubernetes en de knooppunten up-to-date

K8s is een opensourcesysteem dat voortdurend wordt bijgewerkt. De GitHub-opslagplaats is een van de meest actieve opslagplaatsen van het platform. Er worden voortdurend nieuwe functies, verfijningen en beveiligingsupdates aan toegevoegd.

Elke vier maanden komt er een nieuwe, belangrijke Kubernetes-versie uit. Elke nieuwe versie biedt functies voor verbetering van de service, maar hierdoor kunnen er ook nieuwe beveiligingsproblemen of bugs worden geïntroduceerd. Dat is natuurlijk iets waar alle software mee te maken heeft, zeker als die vaak wordt bijgewerkt.

Maar ook in oudere versies komen zwakke plekken voor. Daarom is het essentieel om te begrijpen hoe het Kubernetes-team beveiligingsupdates in oudere versies aanpakt. In tegenstelling tot Linuxdistributies of andere platforms heeft Kubernetes geen LTS-versie. In plaats daarvan worden bij beveiligingsproblemen backports gebruikt naar de drie meest recente grote versies die zijn uitgebracht.

Daarom is het belangrijk om uw cluster in een van die drie meest recente grote versies te houden, alle beveiligingspatches bij te houden en minimaal elke twaalf maanden updates naar de meest recente grote versie te plannen.

Naast de hoofdcomponenten verwerkt Kubernetes ook knooppunten die verantwoordelijk zijn voor de workload die aan het cluster is toegewezen. Deze knooppunten kunnen fysieke of virtuele computers zijn waarop een besturingssysteem draait. Elk knooppunt is een potentiële attack vector die moet worden geüpdatet om beveiligingsproblemen aan te pakken. De knooppunten moeten zo schoon mogelijk zijn om de aanvalsmogelijkheden te verkleinen.

Beperkt de gebruikerstoegang

Toegangsbeheer op basis van rollen (Role-Based Access Control, RBAC) is een van de beste manieren om te beheren welke gebruikers op welke manier toegang hebben tot het cluster. De machtigingen van elke gebruiker kunnen met gedetailleerde rechten worden ingesteld. De regels zijn altijd additief, dus elke machtiging moet expliciet worden ingesteld. Met RBAC is het mogelijk om de toegangsrechten (weergeven, lezen of schrijven) te beperken voor elk Kubernetes-object, van pods (de kleinste rekeneenheid van K8s) tot naamruimten.

RBAC kan met OpenID Connect-tokens ook aan een andere directoryservice worden gekoppeld. Op die manier kan het beheer van gebruikers en groepen centraal worden gedefinieerd, zodat het breder kan worden toegepast binnen de organisatie.

De toegangsrechten zijn niet beperkt tot Kubernetes. Gebruikers hebben soms toegang nodig tot een clusterknooppunt, bijvoorbeeld om problemen te identificeren. In dat soort gevallen is het beter om tijdelijke gebruikers aan te maken om de problemen op te lossen en die gebruikers vervolgens weer te verwijderen.

Best practices voor containers

Docker is de containertechnologie die het meest wordt gebruikt. Deze bestaat uit lagen, waarbij de binnenste laag de meest primitieve structuur is en de buitenste laag de meest specifieke. Alle Docker-images beginnen met een vorm van distributie- of taalondersteuning. Met elke nieuwe laag wordt de vorige functionaliteit uitgebreid of aangepast en dat gaat zo door tot aan de allerlaatste laag. De container moet dan alles hebben wat nodig is om de applicatie te draaien.

Deze lagen, die ook wel images worden genoemd, kunnen openbaar beschikbaar worden gesteld in Docker Hub of privé in een ander image registry. Een image kan op twee manieren worden uitgedrukt: als een naam plus een label (bijvoorbeeld node:latest) of met de onveranderlijke SHA-identificatie (bijvoorbeeld sha256: d64072a554283e64e1bfeb1bb457b7b293b6cd5bb61504afaa3bdd5da2a7bc4b voor dezelfde image op het moment van schrijven).

De image die aan het label is gekoppeld, kan op elk gewenst moment worden gewijzigd door de eigenaar van de opslagplaats. De tag latest verwijst dus naar de nieuwste versie die beschikbaar is. Dat betekent ook dat de binnenste laag plotseling en onaangekondigd kan veranderen wanneer er een nieuwe image wordt gebouwd of een image met een tag wordt uitgevoerd.

Deze strategie brengt dus enkele problemen met zich mee: (1) Je verliest de controle over wat er in je Kubernetes-instantie wordt uitgevoerd, omdat een hogere laag kan worden bijgewerkt en een conflict kan toevoegen of (2) de image kan met opzet worden aangepast om een inbreuk op de beveiliging te introduceren.

Dat eerste probleem is te voorkomen door in plaats van de tag latest een meer versiespecifieke tag te gebruiken (zoals node:14.5.0). Het tweede probleem kan worden vermeden door voor officiële images te kiezen, de image naar de privéopslagplaats te klonen of de SHA-waarde te gebruiken.

Daarnaast is het mogelijk om een detectietool voor kwetsbaarheden te gebruiken om de gebruikte images voortdurend te scannen. Deze tool kansamen met pijplijnen voor continue integratie worden uitgevoerd en kan de imageopslagplaats monitoren om problemen te identificeren die eerder niet zijn opgemerkt.

Het is belangrijk om er bij het bouwen van een nieuwe image rekening mee te houden dat elke image maar één service mag bevatten. De hele image moet zo worden gebouwd dat deze alleen de afhankelijkheden heeft die voor die applicatie nodig zijn en verder helemaal niets. De aanvalsmogelijkheden worden op die manier beperkt tot alleen de componenten die essentieel zijn voor de service. Met slechts één applicatie per image is het ook gemakkelijker om updates naar een nieuwe versie uit te voeren en resources toe te wijzen in de orchestrator.

Netwerkbeveiliging

Hierboven ging over het beperken van de aanvalsmogelijkheden en hetzelfde geldt voor netwerken. Kubernetes beschikt binnen het cluster over virtuele netwerken die de toegang tussen pods kunnen beperken en externe toegang kunnen toestaan, zodat alleen toegang mogelijk is tot services die zijn toegestaan. Dit is een primitieve oplossing die goed werkt in kleine clusters.

Grotere clusters met meerdere services die door verschillende teams zijn ontwikkeld, zijn veel complexer en dan is beheer vanuit één centrale aanpak vaak niet mogelijk. In dergelijke gevallen zijn servicemeshes op dit moment de beste methode. De servicemesh maakt een netwerkencryptielaag die ervoor zorgt dat services veilig met elkaar kunnen communiceren. Deze werken meestal als een sidecar-agent die aan elke pod is gekoppeld en communicatie tussen services mogelijk maakt. Servicemeshes zijn niet alleen bedoeld voor de beveiliging. Ze maken bijvoorbeeld ook monitoring/tracing/logging en detectie van services mogelijk en voorkomen serviceonderbreking door een circuit breaking patroon toe te passen.

Stel resourcequota’s in

Applicaties worden voortdurend bijgewerkt. Voor de beveiliging van uw cluster is het dan ook niet voldoende om alleen de bovenstaande maatregelen te implementeren. Bovendien is er altijd nog het risico op een beveiligingslek.

Een andere belangrijke stap is het gebruik van resourcequota’s, waarmee Kubernetes de dekking van uitval limiteert tot de ingestelde beperkingen. Als die beperkingen goed zijn ontworpen, voorkomen ze dat alle clusterservices niet meer beschikbaar zijn door onvoldoende resources. Ze kunnen ook voorkomen dat u aan het einde van de maand met een torenhoge cloudrekening komt te zitten.

Monitoring en logboekregistratie

Monitoring van het cluster, van cluster tot pods, is essentieel om storingen op te sporen en de oorzaak hiervan vast te stellen. Het draait allemaal om het detecteren van abnormaal gedrag. Als het netwerkverkeer is toegenomen of de CPU van de knooppunten zich anders gedraagt dan normaal, moet dat verder onderzocht worden om problemen uit te sluiten. Bij monitoring gaat het vooral om meetgegevens, zoals CPU, geheugen en netwerken. Logboekregistratie kan aanvullende (historische) informatie bieden die kan helpen ongebruikelijke patronen te detecteren of de bron van het probleem te identificeren.

Prometheus en Graphana vormen samen twee effectieve tools voor Kubernetes-monitoring. Prometheus is een zeer krachtige time-series database en Graphana is een grafisch dashboard dat Prometheus-data kan lezen en gebruiksvriendelijke dashboards kan weergeven.

Een andere nuttige tool is ElasticSearch. Dit is een van de populairste tools voor centrale logboekregistratie van de applicatie, knooppunten en Kubernetes zelf, vrijwel in real time.

Cloud versus on-premises: vanuit beveiligingsoogpunt

Een Kubernetes-installatie kan zich on-premises bevinden of een cloudbeheerservice gebruiken. In de on-premises situatie moet elke configuratie − zoals het opstarten van nieuwe computers, het instellen van netwerken en het beveiligen van de applicatie −handmatig gebeuren. Voor services die vanuit de cloud worden beheerd, zoals Google GKE, AWS EKS of Azure AKS, kan K8s met minimale configuratie worden geïnstalleerd. Bovendien zijn deze compatibel met andere services van de cloudprovider.

Vanuit beveiligingsoogpunt gezien hebben on-premises oplossingen veel meer aandacht nodig. Zoals gezegd moet elke nieuwe update door het systeem worden gedownload en geconfigureerd. Ook de knooppunten moeten worden bijgewerkt. Daarom is het raadzaam een on-premises Kubernetes-systeem alleen door een ervaren team te laten implementeren.

Bij cloudbeheerservices is het proces veel eenvoudiger. Kubernetes is dan al geïnstalleerd en de cloudleverancier zorgt ervoor dat alle knooppunten zijn bijgewerkt met de meest recente beveiligingsfuncties. Wat de clusters betreft: bij de meeste cloudproviders kan de gebruiker de K8s-versie kiezen en ze bieden ook manieren om naar een nieuwe versie te updaten. Het is dus eenvoudiger, maar er is ook minder flexibiliteit.

Ten slotte

Met voortdurende updates en de constante stroom van nieuwe tools die op de markt komen is het niet eenvoudig om up-to-date te blijven en alle kwetsbaarheden op tijd aan te pakken. Inbreuk is niet te voorkomen. Met Kubernetes is de uitdaging nog groter, omdat het meer is dan een tool. Kubernetes is eigenlijk een set tools die andere tools, computers en netwerken beheert. De beveiliging ervan is dan ook essentieel.

Met zoveel bewegende onderdelen is het veilig houden van uw Kubernetes echter geen gemakkelijke taak, dus houd u aan deze richtlijnen:

• Scan applicaties die op K8s draaien op beveiligingsproblemen.
• Beperk en beheer de toegang.
• Zorg dat alles met de meest recente beveiligingsupdates is gepatcht en blijf het cluster voortdurend monitoren om storingen meteen aan te pakken en de schade te beperken.

Bij on-premises implementaties is de uitdaging nog groter, omdat er hardware moet worden beheerd, automatiseringen moeten worden gemaakt en meer software moet worden bijgewerkt. Als u echter de best practices opvolgt die hier zijn beschreven, krijgt u een grote voorsprong wat de beveiliging betreft en kunt u uw Kubernetes-omgeving veilig en actief houden.

Het SentinelOne-platform ondersteunt fysieke en virtuele computers, Docker, zelf beheerde Kubernetes en door cloudserviceproviders beheerde Kubernetes zoals AWS EKS. Vraag vandaag nog een gratis demo aan om meer te ontdekken.