nl

NL

Startpagina / Blog / Kubernetes blog serie: Security

Met behulp van diensten zoals Google Kubernetes Engine (GKE), kun je in slechts een paar klikken met Kubernetes aan de slag. Binnen enkele minuten kijk je naar de beroemde woorden - "Hallo wereld!" - in je favoriet browser. Waarschijnlijk heb je hier nog wel een aantal brandende vragen over. In deze blogserie zullen we er een aantal behandelen.

De focus van dit eerste artikel is Security. Begin je je Kubernetesreis met security in gedachten, dan zul je jezelf over een paar maanden bedanken. Security, (vanaf hier beveiliging) is achteraf namelijk niet zo eenvoudig te implementeren. We beginnen daarom met een eenvoudige vraag:

Is mijn cluster zo veilig mogelijk?

Het is belangrijk om te weten hoe je services zoals GKE kunt gebruiken om ervoor te zorgen dat je cluster veilig is en de beste beveiligingsmethoden volgt. Er zijn veel manieren waarop je kan profiteren van Kubernetes-clusters en implementaties die niet zijn opgezet met het oog op beveiliging.

Gelukkig maakt GCP deze beveiligingsmethoden eenvoudig te implementeren.

Privé knooppunt

De eenvoudigste manier om je cluster veilig te maken, is door externe (openbare) IP-adressen te verwijderen, waardoor ze alleen een intern (privé) IP-adres hebben en ze 'privé knooppunten'. Dit beschermt de knooppunten en, door associatie, je workload die erop worden uitgevoerd vanaf het openbare internet.

Met behulp van GKE kun je een beheerde NAT-service toevoegen zodat je knooppunten internettoegang hebben op een veel beter beheersbare en veiligere manier waarmee ze bijvoorbeeld externe afbeeldingen kunnen installeren.

Bovendien stelt GCP je Kubernetes-cluster ook in staat om nog steeds met andere services op GCP te communiceren zonder toegang tot het openbare internet. Met behulp van Private Google Access, staat GCP communicatie toe met de meeste API's van Google vanuit een privaat netwerk.

Gebruik van een niet-standaard serviceaccount

Wanneer je een cluster maakt met behulp van GKE, wordt een serviceaccount gebruikt, het "standaardberekeningsserviceaccount". Het wordt aanbevolen om door de gebruiker beheerde serviceaccounts te maken en standaardserviceaccounts niet te gebruiken, omdat:

  1. Het gedrag van de standaardserviceaccounts onvoorspelbaar is in termen van wanneer deze is gemaakt en hoe deze in je project worden weergegeven.
  2. Ze hebben meestal een zeer groot aantal machtigingen. Dit betekent dat ze binnen GCP veel kunnen doen, wat in strijd is met het principe van het minste voorrecht dat Google aanbeveelt.

Toegang tot de master beperken

Een privécluster heeft 2 master-eindpunten - privé en openbaar - die kunnen worden gebruikt om met de master te communiceren. Standaard gebruiken knooppunten in een cluster het privé-eindpunt voor alle communicatie en wordt het openbare eindpunt gebruikt voor externe verbindingen met de master-API (d.w.z. een ontwikkelaar die kubectl gebruikt).

Realistisch gezien, hoewel technisch haalbaar, kun je je openbare master-API niet volledig beperken, omdat je meer dan waarschijnlijk toegang tot de bronnen op het cluster nodig hebt vanaf een lokale machine voor foutopsporing of probleemoplossing. Als dit het geval is, moet je ernaar streven het eindpunt van de openbare master zoveel mogelijk te beperken.

Als je bijvoorbeeld alleen toegang hebt tot de bronnen vanaf een computer op kantoor, beperk je de toegang tot het IP-bereik van het kantoornetwerk. Als je vanuit huis werkt, overweeg dan een VPN of een statisch adres waartoe je je hoofdtoegang kunt beperken.

Afbeeldingen beveiligen

Beveiliging stopt niet bij het cluster! Nu we een veiliger cluster hebben, moeten we nadenken over onze implementaties.

Ga weg!

Overweeg tools die aanvallers kunnen gebruiken als ze toegang krijgen tot je container om schadelijke code te downloaden en uit te voeren - bijvoorbeeld 'curl' en 'wget'.

Als je toepassing zonder deze hulpmiddelen kan worden uitgevoerd, zet je ze in je Dockerfile of beter nog verwijder ze. Begin klein en voeg alleen hulpmiddelen toe die je nodig hebt.

Afbeeldingsbronnen

Denk na over waar je basisafbeelding vandaan komt. Zorg ervoor dat het afkomstig is van een gerenommeerde bron of dat je de code hebt gezien die deze afbeelding definieert om er zeker van te zijn dat het geen kwetsbaarheden bevat of dat je iets vreemds installeert.

Als dit allemaal goed is, denk dan aan de verdeling waarop de bronafbeelding is gebaseerd. Veel tutorials vertellen je bijvoorbeeld dat je een Alpine-afbeelding moet gebruiken. Deze distributie van Linux is ontworpen met het oog op beveiliging en is erg klein, met een snelheid van ongeveer 5 MB.

Als je een stap verder wilt gaan en geen shell-toegang tot de actieve containers nodig hebt, overweeg dan om een ​​"distroless" basisafbeelding te gebruiken (zoals degene die Google biedt). "Distroless" betekent dat het runtime-afhankelijkheden en je toepassing herbergt zonder veel onnodige bestanden, services en tools.

Nog beter, als je applicatie bijvoorbeeld een Go binary is, bouw je je afbeelding "VANAF nul" dat zo klein als mogelijk is. Docker beschrijft deze afbeelding als "een expliciet lege afbeelding".

Scan je kwetsbaarheid

Bovenop bovenstaande maatregelen is het scannen van afbeeldingen op kwetsbaarheden de moeite waard. Voor de functie 'Vulnerability scanning' van Google Container Registry is alleen een API vereist voor je project en wordt elke afbeelding die naar GCR wordt gepusht automatisch gescand op kwetsbaarheden. Het voegt "opmerkingen" toe aan de afbeelding die de kwetsbaarheid, de ernst ervan en hoe dit te verhelpen beschrijft (als er een oplossing beschikbaar is).

Je kunt dit zelfs in je pijplijn integreren om ervoor te zorgen dat afbeeldingen de "OK" krijgen voordat ze worden geïmplementeerd in je cluster op GKE.

Veilig implementeren

Nu hebben we een veilige cluster en zijn al onze afbeeldingen geschreven met veiligheid in gedachten! Vervolgens moeten we ze implementeren met behoud van onze focus op beveiliging.

RBAC

Role-Based Access Control is de methode waarmee toegang tot Kubernetes-bronnen wordt verleend aan gebruikers en serviceaccounts binnen Kubernetes.

Om dit effectief te kunnen gebruiken, moeten serviceaccounts per applicatie worden gebruikt wanneer toegang tot andere bronnen vereist is. Het serviceaccount mag alleen toegang hebben tot de benodigde resources met het minimaal vereiste toegangsniveau. Deze vorm van toegang wordt het principe van het minste privilege genoemd.

Network Policies

Een netwerkbeleid is een manier om de communicatie van pods naar andere pods en eindpunten te definiëren. Labels worden gebruikt om pods te selecteren en regels worden gedefinieerd voor welk verkeer van en naar de geselecteerde bronnen is toegestaan. Met behulp van dit beleid kun je ervoor zorgen dat pods alleen kunnen communiceren met andere pods en services wanneer deze verbindingen vereist zijn. Deze moeten worden gebruikt om de straal van een aanval te minimaliseren.

Beveiligingscontext

Een beveiligingscontext kan worden gedefinieerd voor pods en / of containers en wordt gebruikt om het bevoegdheidsniveau en de beveiligingstoegang van de container(s) in te stellen. Hier volgen enkele van de belangrijke instellingen die je kunt definiëren in een pod-beveiligingscontext (deze waarden zijn van toepassing op alle containers in de pod) samen met de beveiligingscontext op containerniveau:

  • runAsGroup - De GID om het entrypoint van het containerproces uit te voeren. Kan ook worden ingesteld in de context van de containerbeveiliging.
  • runAsNonRoot - Dwingt af dat de container moet worden uitgevoerd als een niet-rootgebruiker. Deze instelling zorgt ervoor dat de container niet start als het Kubelet van mening is dat het als root draait. Kan ook worden ingesteld in de context van de containerbeveiliging.
  • runAsUser - De UID om het entrypoint van het containerproces uit te voeren.

Bovendien kan het volgende worden ingesteld in de beveiligingscontext van een specifieke container:

  • privileged - Als deze boolean is ingesteld op true, wordt de container in de bevoorrechte modus uitgevoerd. Processen in bevoorrechte containers zijn in wezen gelijk aan root op de host.
  • readOnlyRootFilesystem - of zijn container alleen-lezen toegang heeft tot het rootbestandssysteem.

Mogelijkheden

Mogelijkheden kun je definiëren in een beveiligingscontext van een container. Hiermee kun je functies toevoegen aan of verwijderen uit actieve containers. Een mogelijkheid definieert een reeks superuserprivileges als een eenheid en kan worden in- en uitgeschakeld. Hiermee kun je containers uitvoeren als niet-rootgebruikers, terwijl ze alleen de mogelijkheden krijgen die ze nodig hebben om te worden uitgevoerd.

Een eenvoudig voorbeeld: als een webserver is geschreven om te binden aan een poort in het bereik van 1-1023, kan deze worden uitgevoerd als niet-root en nog steeds binden aan deze poorten met behulp van de mogelijkheid "net_bind_service".

En nu?

Samenvattend: ik sprak over het beveiligen van je Kubernetes-implementatie van start tot finish. Daarin beschreef ik de best practices voor het beveiligen van je cluster met Google Kubernetes Engine op GCP.

Vervolgens behandelde ik hoe Docker-afbeeldingen moeten worden geschreven en in Kubernetes kunnen worden geïmplementeerd met beveiliging voorop. Het gebruik van eenvoudige toevoegingen zoals RBAC, netwerkbeleid en beveiligingscontexten naast je implementatie kan je architectuur aanzienlijk beveiligen.

Beginnen met beveiliging is belangrijk. In deel 2 van deze serie zal ik bespreken hoe je GCP optimaal kunt benutten om een CICD-platform te bieden voor je Kubernetes-architectuur.

Vergelijkbare verhalen