Cloud-computing draait om de samenwerking van allerlei losse componenten. Kubernetes is hier een essentieel onderdeel om applicaties in containers te draaien en hardware-resources te verdelen. Ze zijn daarom ruim configureerbaar, of ook wel “composable”, zodat het toepasbaar is voor talloze IT-infrastructuren. OWASP (Open Worldwide Application Security Project) ziet echter dat dit een aantal gevaren met zich meebrengt. Het licht er 10 uit.
OWASP bestaat al sinds 2001 en produceert ook lijstjes rondom bijvoorbeeld API-security en cryptografische fouten. De toenemende populariteit van cloud-computing zal het belang van de Kubernetes top 10 alleen maar duidelijker hebben gemaakt. Daarbij komt ook nog dat de lijst van best practices omtrent Kubernetes lang niet altijd worden nageleefd. Erg handig om dus even de vinger op de zere plek te leggen. Wat kan er allemaal misgaan en hoe los je het op?
Tip: Best practices Kubernetes worden vaak niet nageleefd
K01: onveilige workload-configuraties
OWASP citeert onderzoek van Red Hat dat zag dat bijna 53 procent van de ondervraagden wel eens een Kubernetes-misconfiguratie-incident had meegemaakt in de laatste twaalf maanden. Zo kan men een proces binnen een container draaien als de root-user, waardoor een aanvaller root-privileges kan verkrijgen. Ook moeten gebruikers kiezen voor read-only filesystems zodat kwaadwillenden niet buiten een container acties kunnen ondernemen. Daarnaast is het niet aan te raden om een privileged container te draaien: daarmee kan een threat actor extra resources aanspreken en een host op kernel-niveau overnemen. Daarmee omzeilt diegene veel ingebouwde preventiemiddelen tegen het uitbreken van containers.
K02: supply chain-kwetsbaarheden
OWASP geeft aan dat een enkele container met honderden third-party componenten en dependencies kan omgaan, waardoor het erg lastig wordt om elke oorsprong te vertrouwen. De nonprofit haalt aan dat het moeilijk is om de integriteit van een image te garanderen omdat er geen of te weinig data wordt gelogd. Daarom is het belangrijk om in elke fase de integriteit van de software te verifiëren met in-toto attestations.
Daarnaast bestaat een container image uit lagen, waarbij externe software ervoor kan zorgen dat het aanvalsoppervlak vergroot wordt. Hackers kunnen bekende kwetsbaarheden exploiteren om zich zo binnen een Kubernetes-omgeving te wurmen.
Door een grote afhankelijkheid van third-party software kunnen er kwetsbaarheden onbekend zijn in die applicaties, waardoor een gehele cluster in gevaar kan komen. Daarom moet elke organisatie er een Software Bill of Materials (SBOM) op nahouden, waarvanuit security-checks dienen plaats te vinden om te controleren op kwetsbaarheden of ongepatchte applicaties.
K03: te losse RBAC-configuraties
RBAC (Role-based access control) zorgt ervoor dat een netwerk of gebruiker slechts het toegangsniveau heeft dat strict noodzakelijk is. Een fout in het configureren ervan kan betekenen dat een gecompromitteerde gebruiker tot veel meer toegang kan leiden voor een kwaadwillende dan gedacht. Een voorbeeld van OWASP is het onnodig inzetten van cluster-admin voor een gebruiker. Gecentraliseerde policies om riskante RBAC-permissies te detecteren en te blokkeren kunnen daarin enorm helpen. Directe toegang tot clusters moet ook zoveel mogelijk worden voorkomen.
K04: geen gecentraliseerde policy enforcement
Veel organisaties werken tegenwoordig met meerdere clouddiensten tegelijk of hebben meerdere Kubernetes die bijvoorbeeld per regio of per bedrijfsdivisie verdeeld zijn. Hierbij is het voor de hand liggend om niet alle policies centraal te laten functioneren, maar dat is erg belangrijk. Wie dat niet doet, kan namelijk mogelijk images vanuit niet vertrouwde registries toelaten. In combinatie met andere veel gemaakte fouten kan dit leiden tot het escaleren van privileges, met alle gevolgen van dien.
Gelukkig hebben Kubernetes een ingebouwde Admission Controller in de API zitten om dit te verzorgen.
K05: inadequaat gebruik van logging en monitoring
Bij Kubernetes is het belangrijk om data te loggen, zeker omdat containers veelal kort in leven zijn waardoor het bewijs van een cyberaanval snel vervaagt. Het is met name belangrijk om een gecentraliseerde locatie voor logs te hebben, waardoor je visibility houdt in mogelijke cyberaanvallen. Zaken als gefaalde authenticatiepogingen of het handmatig verwijderen van Kubernetes-resources moeten zichtbaar zijn. Kubernetes kent zelf een Audit logging-functionaliteit die acties ondernomen door de API bewaart voor latere analyse. Het is eveneens belangrijk om de logging-infrastructuur goed te beschermen, want anders kan een uitgekiende aanvaller zijn sporen uitwissen.
K06: kwetsbare authenticatie-mechanismen
Authenticatie is op veel manieren te configureren binnen Kubernetes, maar daardoor ook op veel manieren te verknallen. Zo moeten gebruikers voorkomen dat ze certificaten gebruiken om via de Kubernetes-API toegang te verlenen. Deze kunnen namelijk niet herroepen worden, waardoor een gecompromitteerde cluster vlug een re-key nodig heeft. OWASP noemt certificaten een “Break Glass”-mechanisme als je echt geen andere manier hebt om authenticatie te verzorgen.
Zoals bekend is MFA (Multi-Factor Authentication) inmiddels overal, maar ook hier is het een nuttige wijze van beveiliging.
K07: ontbrekende tools voor network segmentation
Het belang van network traffic bij Kubernetes is al gauw duidelijk: de infrastructuur kan in de weer zijn met allerlei microservices en tenants. Networking is daarom standaard “flat”, waardoor elke workload standaard met elke andere workload kan communiceren. Wie daar niet van afwijkt, kan aanvallers de kans geven om zich door het netwerk te navigeren.
OWASP raadt meerdere Kubernetes-clusters aan wanneer dat gepast is. Daardoor ontstaat er een afscheiding tussen workloads zodat aanvallers minder ver kunnen komen. Toch kan dit voor extra complexiteit zorgen in je IT-infrastructuur. Network policies kunnen de communicatiestromen tussen Kubernetes-pods inperken. Ook een service mesh zoals Istio, Linkerd en HashiCorp Consul wordt door OWASP aangeraden om network traffic te segmenteren.
K08: fouten in secrets management
Een Kubernetes-Secret is een object dat gevoelige data bewaart, zoals een wachtwoord of een token. OWASP raadt aan om deze met “extreme voorzichtigheid” te gebruiken. Wie deze oproept via de API, krijgt een onversleutelde gebruikersnaam en wachtwoord te zien. Het is daarom cruciaal om secrets-at-rest van encryptie te voorzien. Daarnaast dienen gebruikers RBAC-configuraties goed af te sluiten, aangezien een kwaadwillende met toegang hiertoe kan bepalen welke privileges men wil. Hierbij keren logging en auditing terug, omdat daarmee ingezien kan worden of iemand toegang verkreeg tot een Kubernetes-secret.
K09: verkeerd geconfigureerde cluster-componenten
Een Kubernetes-cluster kan op allerlei manieren geconfigureerd worden, iets dat fouten in de hand werkt. Denk aan kubelets, die ervoor zorgt dat containers naar behoren werken. Echter is het mogelijk om geen authenticatie aan te hebben staan op verzoeken naar deze kubelet. Ook moet de key-value store etcd goed bewaard worden, omdat deze config-data huisvest en Kubernetes-secrets.
Het is eveneens van belang om de Kubernetes API-server niet op een publiek netwerk te draaien. OWASP haalt BleepingComputer aan dat in 2022 berichtte over 900.000 Kubernetes-instances die online beschikbaar waren.
Reguliere CIS Benchmark-scans en audits moeten component-misconfiguraties kunnen ontdekken. Een sterke Infrastructure-as-Code cultuur zou ervoor moeten zorgen dat security-teams visibility houden in hoe clusters worden gecreëerd en bijgehouden.
K10: gedateerde en kwetsbare componenten
Het traditionele patchen en controleren van kwetsbaarheden kan tenslotte ook voor problemen zorgen. Het bijhouden van Kubernetes-gerelateerde CVE’s moet vanzelfsprekend zijn, net als het continu scannen voor kwetsbare componenten met bijvoorbeeld OPA Gatekeeper. Het minimaliseren van third-party dependencies kan een Kubernetes-cluster veilig houden.
Kortom: bewaar het overzicht
IT-teams zullen overwegend al veel dreigingen in kaart hebben gebracht en de nodige stappen hebben genomen. Toch begint het bijhouden van Kubernetes-securit bij het bewaren van het overzicht. Zo spreekt OWASP over de Software Bill of Materials, dat als voorbeeld kan gelden voor de aanpak van de eigen IT-infrastructuur. Is er bekend wat er in elke cluster plaatsvindt, wie toegang heeft en of alle data inzichtelijk is? Dat is eigenlijk altijd makkelijker gezegd dan gedaan.
Voor een overzicht van Kubernetes anno 2023 publiceerden we eerder dit jaar een uitgebreid artikel.
Lees het hier: De staat van Kubernetes in 2023