Google Cloud-engineer om Kubernetes: Du bør absolut definere netværkspolitikker

Illustration: Privatfoto
Der indgår mange forskellige elementer i en Kubernetes-løsning, hvilket betyder, at sikkerheden skal sikres i flere lag. Google-ekspert fortæller hvordan.

Abdelfettah Sghiouar er en venlig, hurtigttalende, teknisk indsigtsfuld Cloud Engineer fra Google, som bruger meget af sin tid på at hjælpe kunder med cloud computing. Han er født i Marokko, men har arbejdet i Belgien og nu i Sverige, hvor Abdelfettah rådgiver kunder om, hvordan de bedst kan anvende cloud.

Han beskæftiger sig indgående med Kubernetes-løsninger, og på Version 2's store sikkerhedskonference Infosecurity Denmark 2019 vil han fortælle om sikkerhed i forbindelse med Kubernetes.

Sikkerhed i mange lag

Kubernetes har på relativ kort tid gået sin sejrsgang som måden at håndtere og koordinere blandt andet de populære Docker-containere i distribuerede cloud-løsninger på. Det kan du læse mere om her.

Kubernetes kan have en eller flere Docker-containere i en pod, som kører på en node, som indgår i en Kubernetes-klynge. Der er således flere abstraktionslag i en Kubernetes-løsning, og følgelig er der også sikkerhedsproblematikker i flere lag.

Derfor har Abdelfettah valgt at kalde sin præsentation for 'Kubernetes Securities – a multi layer approach'.

»Ideen med præsentationen er at se på sikkerheden i relation til de enkelte lag som indgår i en Kubernetes-opsætning,« siger Abdelfettah.

Container-sikkerhed

Et par dage inden Version2's samtale med Abdelfettah om hans arbejde med sikkerhed i Kubernetes, offentliggør open source-sikkerhedsfirmaet Snyk en rapport, hvor det blandt andet nævnes, at de 10 mest populære Docker-images har en række sårbarheder.

Abdelfettah nævner da også, at det er vigtigt at sikre containerlaget. Abdelfettah foretrækker selv at anvende Containerd i stedet for Docker.

»Containerd har ikke så mange features, men heller ikke så mange sikkerhedsproblematikker som Docker, da Containerd ikke er så kompleks som Docker. Docker har eksempelvis sin egen netværksstak, mens Containerd anvender netværksstakken på noden,« siger Abdelfettah.

Sikring af noder

Det er selvfølgelig også vigtigt at sikre selve noderne i en Kubernetes-opsætning. Det kan være en fysisk maskine eller en VM, og her skal den grundlæggende sikkerhed være på plads.

»Det er ting som firewalls samt sørge for at grundlæggende patchning og opgradering er på plads,« anbefaler Abdelfettah og bevæger sig derefter opad i Kubernetes-stakken i sin sikkerhedsmæssige gennemgang.

Separering af workloads

»Hvordan sikrer du, at de forskellige workloads, der kører på noderne er separeret fra hinanden?« spørger Abdelfettah retorisk.

For Abdelfettah er svaret på det spørgsmål at anvende gVisor fra Google, som foretager en effektiv sandboxing af containere.

Det samme kan opnås, hvis man tildeler en VM til hver enkelt container, men da gVisor er mere letvægt med hensyn til ressourcer, er det en bedre løsning, mener Abdelfettah.

Netværkssikkerhed og RBAC

Vi bevæger os yderligere op ad Kubernetes-stakken og kommer til clusteret eller klyngen.

»En standardinstallation af en Kubernetes-klynge vil betyde, at alle pods kan tale med hinanden. Alle services kan kalde alle services. Der er ingen netværkspolitikker som standard,« siger Abdelfettah, der kraftigt anbefaler at definere netværkspolitikker.

Kubernetes anvender Role-based Access Control (RBAC) til at kontrollere adgangen til processer og ressourcer for både systemer og mennesker. Her anbefaler Abdelfettah at liste alle brugere og services som anvender/indgår i et Kubernetes-cluster og definere en matrix.

»Opstil en matrix med mennesker/systemer på x-aksen, og hvilke adgangsrettigheder der har brug for på y-aksen,« anbefaler Abdelfettah.

Håndtering af mange clustre

Når man får flere Kubernetes-clustre at holde styr på, kan man få hjælp til at sikre konsistens i sikkerhedspolitikkerne på tværs af clustrene ved at anvende det nyligt frigivne CSP Config Management.

CSP Config Management er integreret med Git-versionskontrolsystemet, så man kan have et centralt Git-repository med RBAC, ressourcekvoter og andre sikkerhedspolitikker.

Huskes det i virkeligheden?

Selvom der altså er forskellige hjælpeværktøjer til at sikre en konsistent sikkerhedspolitik for en virksomheds Kubernetes-anvendelse, bliver Version2 lidt urolig over de mange lag, som IT-folk skal huske at sikre.

Er det noget som er godt indarbejdet i virksomhedernes processer, og bliver det gjort?

»Det er noget, som folk bør gøre. Der er traditionelt tre aktører: Udviklere; operatører, der tager sig af klyngen, og så driftsfolk, der tager sig af den underliggende infrastruktur, selvom operatører og infrastrukturfolk nogle gange overlapper hinanden,« svarer Abdelfettah.

Men hvordan med devops, hvordan ser det ud i de tilfælde?

»Devops er et andet paradigme. Hvis du implementerer devops best practices, så bliver sikkerhed alles ansvar. Det er ikke op til team A, team B eller team C at tage sig af sikkerheden; det er alles ansvar. De skal blive enige om, hvordan man bedst implementerer gode sikkerhedspolitikker, og så gøre det,« svarer Abdelfettah.

Sker det så i virkeligheden?

»Det afhænger af organisationen, de enkelte teams, hvor agile folk er og så videre. Det er min opgave at gøre folk opmærksomme på de her ting,« svarer Abdelfettah.

Bliv inspireret

Abdelfettah har omkring 45 minutter til sin gennemgang af sikkerhed i Kubernetes-løsninger, så han kan ikke love at komme til bunds i alle de forskellige sikkerhedsaspekter.

»Der er masser af ting at tale om. Min præsentation kan ses som en TL;DR om Kubernetes sikkerhed. Det er ikke en fuldstændig løsning, mere end checkliste,« siger Abdelfettah, der lover at have masser af links til yderligere information og ressourcer.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Martin Rasmussen

Som udgangspunkt ingen, udover de folk/organisationer som benytter disse. Her adskiller det sig eks. ikke fra github, hvor der, ifølge mange malware/virus undersøgelser, ligger en del skadelig kode.

Som udgangspunkt er dem der hoster disse sider, dog mere end behjælpelige til at få fjernet sådanne indhold hvis du/man laver indsigelser imod indhold.

Så; husk at afsætte nogle ressourcer til at gøre denne del, og lad være med at antage at 'det har de andre nok gjort'..

Log ind eller Opret konto for at kommentere