Suche
  • Robin Nepomuk Mai

Kubeconfig auf Namespace begrenzen

Für die logische Unterteilung eines Clusters bietet Kubernetes das Konzept der Namespaces. Ein Namespace für einen neuen Kunden ist schnell angelegt, aber wie verhindere ich, dass Ressourcen in anderen Namespaces ungewollt bearbeitet oder schlimmstenfalls gelöscht werden können?


Service Accounts sind die Antwort

Einen neuen Service Account anzulegen ist genauso trivial wie das erstellen eines neuen Namespaces. Anzugeben sind der Name und der Namespace des Service Accounts. In dem Beispiel wird der ServiceAccount im Default Namespace angelegt, da das Binding an den Namespace des Kunden gleich im RoleBinding passiert.

--- 
apiVersion: v1 
kind: ServiceAccount 
metadata:   
  name: new-customer   
  namespace: default

Welche Rechte soll der neue Account besitzen?

Die Berechtigungen werden in einer ClusterRole gesetzt. Hier kann man sehr feingranular bestimmen auf welche Ressourcen welche Aktionen ausgeführt werden können. In diesem Beispiel möchten wir dem Kunden Vollzugriff auf seinen Namespace geben, daher bekommt er Vollzugriff auf die API Gruppen und Ressourcen

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: new-customer
rules:
  - apiGroups: ['*']
    resources: ['*']
    verbs:
      - create
      - delete
      - deletecollection
      - get
      - list
      - patch
      - update
      - watch

Nun geht es ans Eingemachte: der ServiceAccount wird bis auf weiteres mit seiner ClusterRole verheiratet. Dadurch erbt er die Berechtigungen der Rolle in dem Namespace der in seinen Metadaten angegeben ist.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: new-customer
  namespace: new-customer-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: new-customer
subjects:
  - kind: ServiceAccount
    name: new-customer
    namespace: default

Wie erfolgt der Zugriff?

Für den angelegten ServiceAccount wurde ein Token erstellt, welches in einem Secret im Default Namespace gespeichert wurde. Dieses kann zur Authentifizierung gegenüber der Kubernetes API benutzt werden.


Jetzt muss das Secret nur noch ausgewählt...

kubectl get secrets

und das Token extrahieren werden.

kubectl get secrets new-customer-token-vk822 --template={{.data.token}} | base64 --decode

Jetzt noch schnell das Token in die Kubeconfig einfügen und den Namespace auf den des Kunden setzen(dann spart er sich das manuelle angeben seines Namespaces mit -n).

apiVersion: v1
kind: Config
preferences: {}

clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubernetes.nepomuk.software
  name: production-kubernetes
contexts:
- context:
    cluster: production-kubernetes
    namespace: new-customer-namespace
    user: new-customer
  name: production-kubernetes-context
current-context: production-kubernetes-context

users:
- name: new-customer
  user:
    token: superscrettoken

Wenn die Kubeconfig jetzt im richtigen Verzeichnis liegt(~/.kube/config), sollte der folgende Befehl "No resources found." zurück geben. Er kann auf den Namespace zugreifen, allerdings sind noch keine Deployments angelegt.

 kubectl get pods

Der selbe Befehl in einem anderen Namespace

kubectl get pods -n kube-system

wird eine Fehlermeldung zurückgeben, dass dieser ServiceAccount nicht berechtigt ist Post in diesem Namespace aufzulisten.

Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:new-customer" cannot list resource "pods" in API group "" in the namespace "kube-system"

18 Ansichten

©2020 by Nepomuk Software UG & Co. KG 

Made with ☕️ in Büdingen

Impressum Datenschutzerklärung

Alle Preise für Geschäftskunden zzgl. 19 % MWST.