De top 10 Kubernetes bevindingen van ons pentesting team

Onze top 10 Kubernetes-bevindingen (en hoe ze op te lossen)

Kubernetes: elke IT-held houdt van dit platform! Dat is niet zo gek, want Kubernetes biedt enorme flexibiliteit en schaalbaarheid aan moderne applicaties. Kubernetes is bewust open ontworpen, waardoor gebruikers veel controle hebben.

Maar: deze openheid betekent ook dat gebruikers een grote verantwoordelijkheid hebben bij het effectief beheren en configureren van Kubernetes. Zoals een beroemdheid ooit zei: 'Met grote macht komt grote verantwoordelijkheid.'

Eerlijk is eerlijk, Kubernetes heeft veel voordelen, maar kan ook complex zijn. Het bevat veel componenten en functionaliteiten, dus het is geen wonder dat er kwetsbaarheden in de beveiliging kunnen ontstaan als het systeem niet goed wordt beheerd. Bijvoorbeeld: blootgestelde API's, onhandige toegangsrechten en andere ongewenste beveiligingsproblemen.

Bij Secura doen we veel Crystal Box Kubernetes security assessments. We delen onze inzichten graag. Daarom hebben we een 'Top 10' samengesteld van de meest voorkomende bevindingen die we tegenkomen tijdens onze Kubernetes security assessments. En natuurlijk laten we het niet daarbij: we delen ook hoe deze problemen op te lossen zijn...

1. Standaard onbeperkte netwerktoegang

Deze bevinding wijst erop dat bronnen zoals pods en diensten binnen een namespace standaard met elkaar kunnen communiceren zonder dat er extra netwerkregels of -beperkingen gelden.

Stel je het volgende scenario voor: Stel je het volgende scenario voor: Je hebt een Kubernetes-cluster geconfigureerd voor het deployen van je applicaties. Wanneer in de default status een nieuwe pod wordt ingezet binnen een namespace in het cluster, kan deze niet alleen verbinding maken met alle andere pods binnen dezelfde namespace maar ook met externe services, zoals een database gehost door een cloud provider, zonder enige initiële beperkingen.

Aanvallers kunnen misbruik maken van deze onbeperkte verbindingsmogelijkheden. Als ze toegang krijgen tot één pod, kunnen ze onbeperkte toegang krijgen tot alle andere pods in dezelfde namespace, wat gevoelige informatie bloot kan leggen. Als gevolg hiervan kunnen aanvallers allerlei schadelijke activiteiten uitvoeren, zoals het stelen van gevoelige gegevens, het manipuleren van de applicatie door de code of het gedrag te wijzigen, het injecteren van schadelijke code of zelfs het verstoren van services.

Om dit risico te beperken, is het belangrijk om regels in te stellen voor ingress en egress voor alle pods binnen een namespace, zodat alleen specifieke pods met elkaar kunnen communiceren.

2. Containerbestandssystemen niet onveranderlijk

Dit betekent dat containers schrijftoegang hebben tot het bestandssysteem. Hierdoor kan een aanvaller essentiële configuratiebestanden wijzigen of kwaadaardige software installeren.

Stel je voor dat je applicatie wordt uitgevoerd op een Kubernetes-cluster en zeer gevoelige klantgegevens verwerkt. In dit scenario ontdekt een aanvaller een kwetsbaarheid in de applicatie waardoor de aanvaller ongeautoriseerde toegang tot de container krijgt en naar het bestandssysteem kan schrijven. Met deze toegang kan de aanvaller kwaadaardige scripts uitvoeren om persoonlijke gegevens te stelen of zelfs applicatieconfiguraties wijzigen om gevoelige informatie vrij te geven.

Om dit risico te verkleinen, kun je container bestandssystemen onveranderbaar maken. Als een container echt schrijftoegang tot het bestandssysteem nodig heeft, kun je mounts gebruiken om specifieke delen schrijfrechten te geven terwijl het grootste deel van het bestandssysteem alleen-lezen blijft.

3. Lege Namespaces

Deze bevinding geeft aan dat er namespaces in het cluster zijn die geen bronnen bevatten.

In een lege namespace zonder actieve pods of services die verkeer genereren, kan eventueel gegenereerd verkeer, bijvoorbeeld van schadelijke activiteiten, onopgemerkt blijven door beheerders, waardoor het een uitdaging wordt om verdachte acties te signaleren. Dit geeft aanvallers meer mogelijkheden om kwaadaardige acties te verbergen en om effectieve aanvallen uit te voeren. Daarnaast resulteert het in onnodige vervuiling en draagt het bij aan de administratieve last om het cluster te onderhouden.

Om de veiligheid en beheersbaarheid van het cluster te verbeteren, is het een goede gewoonte om ongebruikte namespaces te identificeren en te verwijderen.

4. Kubernetes resources zonder CPU- en geheugenbeperkingen

In dit geval hebben sommige pods en containers geen limiet voor CPU- en geheugengebruik.

Zonder het instellen van CPU- en geheugenlimieten kan een aanvaller servers mogelijk overbelasten door grote datavolumes te verwerken en te verzenden. Dit kan leiden tot netwerkcongestie, waardoor de bandbreedte van het cluster verbruikt wordt en de nodes die de pods van de aanvaller hosten overbelast raken. Zulke aanvallen kunnen leiden tot denial-of-service, waardoor het bedrijf inkomsten misloopt. Daarnaast, als diensten zijn geconfigureerd om automatisch te schalen onder belasting, kan dit leiden tot onverwachte hoge kosten.

Om de stabiliteit van het cluster te behouden, is het belangrijk om pod resource limieten in te stellen om deze aanvallen te voorkomen en een efficiënte toewijzing van resources te garanderen.

5. Pod Security Policy beperkt implementaties niet

In het cluster zijn er geen beperkingen ten aanzien van securitymaatregelen voor het inzetten van pods.

In het scenario waarin het Pod Security Policy (PSP) onjuist is geconfigureerd in een cluster, worden kwetsbaarheden blootgelegd in de containers van de applicatie. Door dit gebrek aan beperkingen kunnen containers in bevoorrechte modus werken met extra capabilities zoals NET_ADMIN en host mounts.

In feite geeft dit iedereen die het cluster beheert de autoriteit om deze capabilities toe te wijzen zonder een fundamentele beveiligingslaag, wat mogelijk leidt tot willekeurige toewijzing van capabilities om implementaties functioneel te maken, zonder de gevolgen voor de beveiliging in overweging te nemen.

Bovendien kunnen deze ongecontroleerde capabilities resulteren in een container escape, waardoor een aanvaller ongeautoriseerde toegang kan krijgen tot clusterbronnen en schadelijke acties kan uitvoeren. Bij afwezigheid van een PSP om hun acties te beperken, hebben aanvallers onbeperkte vrijheid om hun schadelijke plannen uit te voeren.

Om dit beveiligingsrisico te beperken, is het belangrijk om het juiste Pod Security Policies op te stellen en af te dwingen. Deze proactieve maatregel helpt bij het beveiligen van je Kubernetes-cluster en voorkomt potentiële aanvallen door containeracties en -capabilities te beperken.

6. Onbeperkte egress van Kubernetes-clusters

Uitgaand verkeer van pods in het cluster is niet beperkt.

In een cluster met onbeperkte egress kunnen pods vrij communiceren met externe resources en zelfs andere pods, waardoor het risico bestaat op misconfiguraties: services die geen internettoegang zouden mogen hebben zijn verbonden met de externe wereld.

Dit beveiligingsrisico kan beperkt worden door beperkingen op te leggen aan externe resources waar pods toegang toe hebben. Dit kan worden bereikt door egress configuraties en netwerkbeleidsregels te implementeren, waardoor pod communicatie met externe resources effectief wordt gecontroleerd en beperkt.

7. Clusterbeheerdergebruikers zonder PIM

Deze bevinding is specifiek voor Microsoft Azure, waar sommige gebruikers onbeperkte en permanente toegang hebben tot de rol van clusterbeheerder in het Kubernetes-cluster, zonder dat er controlemechanismen zoals Privileged Identity Management (PIM) aanwezig zijn.

Zonder PIM kunnen gebruikers permanente toegang krijgen tot de rol van clusterbeheerder, terwijl PIM slechts tijdelijke toegang zou verlenen. Als een aanvaller toegang krijgt tot de inloggegevens van de beheerder, bijvoorbeeld via een phishing-aanval, kan hij deze toegang misbruiken om volledige administratieve controle te krijgen over het Kubernetes-cluster. Dit houdt toegang tot het management dashboard in en de mogelijkheid om alle pods, services en configuraties te controleren.

In cloudomgevingen is het raadzaam om PIM te gebruiken om bevoorrechte toegang te beheren en te monitoren en zo beveiligingsrisico's te beperken door just-in-time rechten af te dwingen.

8. Verouderde containers

Dit is een beveiligingsbevinding in Kubernetes waarbij een container in het cluster niet de laatste versie van een image gebruikt.

Deze situatie kan leiden tot een kwetsbaarheid omdat bepaalde containers verouderde software kunnen draaien of essentiële beveiligingspatches missen. Aanvallers kunnen mogelijk misbruik maken van bekende kwetsbaarheden en zwakke plekken in de beveiliging van deze verouderde containers om de beveiliging van de container te omzeilen en toegang te krijgen tot het cluster.

Om dit risico te verkleinen, is het essentieel om containers regelmatig bij te werken naar de nieuwste versies en ervoor te zorgen dat ze de meest recente beveiligingsfixes en -verbeteringen hebben.

9. Kubernetes API toegankelijk vanaf het internet

De Kubernetes API-server is toegankelijk vanaf het internet zonder de juiste beveiligingsmaatregelen.

Een aanvaller kan actief zoeken naar openbare IP-adressen met open poorten voor de Kubernetes API. Als zo'n kwetsbare API zonder enige beperking wordt gevonden, kan de aanvaller er toegang toe krijgen zonder dat daarvoor referenties of verificatie nodig zijn.

Met ongeautoriseerde toegang tot de Kubernetes API kan de aanvaller proberen een schadelijke pod te deployen binnen het cluster, waardoor hij mogelijk toegang krijgt tot andere pods, zoals een database met klantgegevens. Dit kan leiden tot diefstal van gegevens, compromittering van financiële informatie of zelfs volledige controle over het cluster, wat kan leiden tot inkomstenverlies.

Zelfs als er beperkingen worden opgelegd, blijft er een risico omdat aanvallers nog steeds op zoek kunnen gaan naar kwetsbaarheden om toegang te krijgen tot het cluster.

Om dit beveiligingsprobleem aan te pakken, is het cruciaal om de toegang tot de API-server te beperken.

10. Register is toegankelijk vanaf alle netwerken

Het containerregister in het Kubernetes-cluster is toegankelijk vanaf alle netwerken zonder beperkingen.

In dit scenario vertrouwt het Kubernetes-cluster op containers uit een extern containerregister dat zonder beperkingen toegankelijk is voor alle netwerken. Dit vormt een beveiligingsrisico omdat aanvallers kwaadaardige code in een image kunnen injecteren, een aangepaste image met deze code kunnen maken en deze naar het register kunnen uploaden.

Zodra het schadelijke image in het register staat, kunnen aanvallers het gebruiken om een schadelijke pod in het cluster te deployen, met als doel gevoelige gegevens te stelen of andere schadelijke acties uit te voeren.

Beperk de toegang tot het containerregister om dit te voorkomen. Implementeer toegangscontrolelijsten (ACL's) en dwing authenticatie- en autorisatiemechanismen af, beperk de toegang tot geautoriseerde gebruikers en verminder het risico op ongeautoriseerde code-injectie.

Wij kunnen helpen

Dat waren de 10 bevindingen die wij vaak tegenkomen in ons werk. Natuurlijk hebben we nog veel meer potentiële bevindingen in onze verzameling, die we controleren tijdens onze security assessments. ]

Zo kunnen we samen werken aan de beveiliging van jullie applicaties en systemen, en jullie IT-heldenstatus verder versterken!