Beveilig je Kubernetes Cluster met RBAC

RBAC is in snel tempo best-practice aan het worden om je Kubernetes cluster te beveiligen. Met RBAC is het op een overzichtelijke manier mogelijk om toegangsbeheer tot op een geavanceerd niveau te regelen. Sinds Kubernetes 1.8 is het mogelijk om Role Based Access Control te gebruiken en veel aanbieders van Managed Kubernetes Clusters hebben RBAC standaard geactiveerd. Ook bij Cloudlets staat RBAC op op Kubernetes standaard geactiveerd. Om een goed begin te maken met Kubernetes is het daarom van belang dat je begrijpt hoe RBAC werkt, waarom het belangrijk is om RBAC te gebruiken en hoe je het in de praktijk inzet.

Cloudlets maakt Kubernetes toegankelijk voor een groter publiek. Dat doen wij door het opzetten van een cluster eenvoudiger te maken, door goede tools te bieden die je helpen met het beheren van Kubernetes en door goede ondersteuning te bieden. Wij zijn ons ervan bewust dat we in het toegankelijker maken van Kubernetes in geen geval moeten inleveren op veiligheid. Daarom willen we met dit artikel RBAC in begrijpelijke taal uitleggen.

Wat is RBAC voor Kubernetes?

Met Role Based Access Control, kortweg RBAC, kan je gebruikers en applicaties rechten geven om bepaalde handelingen in je cluster te verrichten. Voordat RBAC geintroduceerd werd, was het niet mogelijk om gebruikers of applicaties gelimiteerde toegang tot je cluster te geven. Volledige toegang of géén toegang waren de opties. Het is in veel gevallen wenselijk om met rollen te werken. Iedere gebruiker die een bepaalde rol toegekend heeft, kan de taken uitvoeren die bij die rol horen. Je kunt door middel van een rol toegang geven tot je gehele cluster of tot namespaces in je cluster. Daarnaast definieer je in een rol welke vorm van toegang je wilt geven: create, read, update, delete.

Het gebruik van RBAC wordt steeds meer de standaard. Niet alleen in Kubernetes, ook op allerlei andere gebieden wordt deze vorm van toegangsbeheer toegepast.

De basisconcepten van RBAC

Om met RBAC te werken is het belangrijk dat je onderstaande basisconcepten kent:

• Role en ClusterRole
  • Een rol is een set aan regels die de rechten in het Kubernetes cluster bepalen. Een rol kan betrekking hebben op het gehele cluster of op een namespace (een afgebakend deel van het cluster). Is er sprake van een rol waarmee rechten tot het hele cluster worden geregeld, dan is sprake van een ClusterRole.
• Rolebinding
  • Een rol kan toegekend worden aan gebruikers, applicaties of serviceaccounts. Dat doe je door een rolebinding toe te passen. De rolebinding kan toegang geven tot een namespace, maar ook tot je gehele cluster. Heeft je rolebinding betrekking op het gehele cluster, dan spreken we van ClusterRoleBindings. Rolebindings kunnen aangemaakt eenvoudig worden met kubectl. Zodra de bindings aangemaakt zijn, kan je ze toepassen op de resources in je cluster.
• Verbs
  • De acties die je door middel van RBAC kunt toestaan heten Verbs: create, delete, deletecollection, get, list, patch, update en watch.
• Resources
  • Een object binnen je cluster waarop een actie uitgevoerd kan worden. Een pod, deployment en namespace zijn voorbeelden van objecten waarop je, mits de juiste rol is toegekend, een actie kunt uitvoeren.

Standaard ClusterRoles

Als je niet eerder met RBAC gewerkt hebt, dan is het implementeren van de juiste rules al snel een complexe en tijdrovende bezigheid. Om toch relatief snel en eenvoudig aan de slag te gaan met de veiligheid van je cluster, komt Kubernetes met een ander standaard ClusterRoles. Het gaat om onderstaande rollen die allen toegang regelen tot je volledige cluster:

• admin
  • Met de rol admin kan je gebruikers en applicaties volledige toegang geven resources binnen een namespace. Gebruikers en applicaties die de rol admin hebben, kunnen alles lezen, aanpassen en verwijderen binnen de aangegeven namespace.
• cluster-admin
  • Vergelijkbaar met de rol admin, met als belangrijk verschil dat de cluster-admin op het hoogste niveau alle rechten heeft en dus niet vooraf gebonden hoeft de worden aan specifieke resources waarop acties uitgevoerd moeten worden. Met de rol cluster-admin heb je volledige toegang tot alle resources in het cluster.
• edit
  • De edit role geeft je rechten om een groot deel van de resources binnen een namespace te bekijken en wijzigen. Resources waaraan deze rol niet is gekoppeld, kan je niet wijzigen of verwijderen.
• view
  • Met de view-role geef je read-only toegang, waardoor je het grootste deel van de resources binnen een namespace zien.

Bovenstaande is een beknopte weergave van de rechten per standaard rol. Wil je alle details weten? Vraag ze dan op via kubectl met het commando kubectl describe clusterrole rolnaam.

RBAC toepassen met Kubectl & .yml files

Wil je rechten toekennen, dan doe je dat niet direct aan een gebruiker of aan een useraccount. Je maakt een rol aan die je vervolgens koppelt aan een gebruiker of een serviceaccount. Die rol bepaalt vervolgens wat je wel of niet mag doen in het cluster of binnen een namespace.

Bestaande clusterrole toekennen

Kubernetes komt standaard met een aantal voorgedefinieerde rollen, zoals in het hoofdstuk hierboven aangegeven. Wil je een bestaande rol toekennen aan een gebruiker om daarmee leestoegang te geven tot je cluster, dan kan dat met onderstaande commando:

$ kubectl create rolebinding rolnaam-view --clusterrole view --user gebruikersnaam --namespace je-namespace

In bovenstaande commando maken we een rolebinding aan met de naam rolnaam-view. Die rolebinding geeft  de rol view aan gebruikersnaam. In plaats van view kan je een een andere (cluster)role kiezen. Het is raadzaam om de rolebinding een herkenbare naam te geven, zodat je de rol op een later tijdstip kunt aanpassen of terugtrekken.

Nieuwe rol aanmaken

Wil je een rol aanmaken waarmee je toegang kunt geven binnen een namespace? Dat kan door in een .yml-bestand te specificeren welke kenmerken die rol moet hebben. Vervolgens kan je rol aanmaken door dat commando met kubectl uit te voeren. Onderstaand een voorbeeld van een .yml-bestand waarmee de rol pod-reader aangemaakt wordt. De rol pod-reader geeft toegang tot de namespace default. Met de rol krijg je de rechten get, watch en list.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Heb je bovenstaande code in een bestand, bijvoorbeeld pod-reader.yml opgeslagen? Dan maak je de rol vervolgens aan door dat bestand met kubectl in te lezen en uit te voeren:

kubectl create -f pod-reader.yml

Met bovenstaande commando maak je een rol. Voordat je iets met de rol kunt, moet deze rol aan een gebruiker of serviceaccount toegekend worden.

Rol toekennen aan een gebruiker of serviceaccount

# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

Bovenstaande code, overgenomen van Kubernetes.io, bind de rol pod-reader aan de gebruiker jane. De rolebinding heeft als name read-pods en heeft betrekking op de namespace default. Om de rolebinding aan te maken, zet je bovenstaande code in een .yml-bestand dat je bijvoorbeeld de naam read-pods.yml geeft. Vervolgens voer je dat configuratiebestand uit met kubectl:

kubectl create -f read-pods.yml

Rollen controleren

Heb je rollen en rolebindings aangemaakt? Dan is het belangrijk dat je controleert of ze naar behoren werken voordat je ze in productie brengt. Als de rollen en bindings niet juist zijn aangemaakt, hebben gebruikers of applicaties wellicht alsnog volledige toegang tot je cluster of hebben ze helemaal geen toegang. Kubernetes komt het met commando auth can-i commando om te checken of een gebruiker iets wel of niet mag. Wil je controleren of gebruiker bijvoorbeeld deployments mag aanmaken in een bepaalde namespace, dan kan dat met onderstaande commando:

kubectl auth can-i create deployments –namespace je-namespace –as gebruiker

De term deployments kan je in bovenstaande voorbeeld veranderen door iedere willekeurige resource die je binnen je cluster hebt. In plaats van create kan je natuurlijk iedere CRUD-actie (create, read, update, delete, etc.) invoeren.

Roles en Bindings eenvoudig aanmaken met audit2rbac

Om roles en bindings goed aan te maken, is het niet alleen van belang dat je goede kennis hebt van Kubernetes en RBAC, maar ook dat je oog voor detail hebt. Als je ergens een klein detail mist, kan het zijn dat je rol niet goed werkt of juist teveel rechten geeft op het cluster. Om dit proces te vereenvoudigen kan je gebruik maken van Audit2rbac. Audit2rbac houdt in de audit logs van Kubernetes bij welke requests door users gedaan worden en stelt op basis daarvan rollen en bindings samen, die je vervolgens alleen nog maar hoeft goed te keuren.

Hulp met RBAC of een security audit nodig?

Hulp nodig bij het opstellen van je RBAC-policy of wil je graag een security audit? Dat verzorgen wij graag voor je. Neem contact met ons op voor de mogelijkheden!