Zum Hauptinhalt springen

Absicherung von Tenant-Namespaces mit der restrict-Autorisierungsfunktion in Chaos Mesh

· 3 Minuten Lesezeit
Anurag Paliwal
Anurag Paliwal
Contributor of Chaos Mesh
Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Chaos-Engineering-Tools
Chaos-Engineering-Tools

Ein Multi-Tenant-Cluster wird von mehreren Nutzern und/oder Workloads gemeinsam genutzt, die als "Tenants" bezeichnet werden. Betreiber solcher Cluster müssen Tenants voneinander isolieren, um Schäden durch kompromittierte oder böswillige Tenants für den Cluster und andere Nutzer zu minimieren.

Cluster-Multitenancy​

Bei der Planung einer Multi-Tenant-Architektur solltest du die Ebenen der Ressourcenisolierung in Kubernetes berücksichtigen: Cluster, Namespace, Node, Pod und Container.

Obwohl Kubernetes keine perfekte Isolation zwischen Tenants garantieren kann, bietet es Funktionen für spezifische Anwendungsfälle. Du kannst jeden Tenant mit seinen Kubernetes-Ressourcen in eigenen Namespaces organisieren. Kubernetes unterstützt mehrere virtuelle Cluster auf derselben physischen Infrastruktur. Diese virtuellen Cluster heißen Namespaces. Namespaces sind ideal für Umgebungen mit vielen Nutzern verteilt über Teams oder Projekte.

Cluster mit Chaos Mesh​

Stell dir vor, du hast einen Kubernetes-Cluster mit mehreren Tenant-Services entworfen. Dabei wurden Best Practices für Kubernetes-Sicherheit befolgt: Jeder Tenant-Service läuft in eigenen Namespaces, Nutzer haben passende Zugriffsrechte ausschließlich für ihre Namespaces, etc.

Chaos Mesh (Chaos Mesh ist eine cloud-native Chaos-Engineering-Plattform für Kubernetes) wurde im Cluster aktiviert, damit Tenant-Services Resilienztests durchführen können. Über RBAC wurden spezifische Chaos Mesh-Rechte an Tenant-Nutzer vergeben.

Angenommen, ein Tenant-Nutzer möchte Pod-Kill-Operationen in seinem Namespace (z.B. chaos-mesh) durchführen. Dazu erstellt er folgende Chaos Mesh-YAML-Datei:

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill
  namespace: chaos-mesh
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - tidb-cluster-demo
    labelSelectors:
      'app.kubernetes.io/component': 'tikv'
  scheduler:
    cron: '@every 1m'

Der Nutzer hat Rechte für den chaos-mesh-Namespace, aber keine für tidb-cluster-demo. Bei der Anwendung dieser YAML-Datei via kubectl wird die Pod-Kill-Ressource im chaos-mesh-Namespace erstellt. Wie im Selector-Abschnitt zu sehen, hat der Nutzer jedoch einen anderen Namespace (tidb-cluster-demo) angegeben. Somit werden Pods aus tidb-cluster-demo für das Chaos-Experiment ausgewählt – nicht aus seinem berechtigten Namespace. Dadurch kann dieser Nutzer einen Namespace beeinflussen, für den er keine Rechte besitzt. Problem!

Seit Chaos Mesh 1.1.3 wurde diese Sicherheitslücke mit der restrict-Autorisierungsfunktion geschlossen. Bei Anwendung der YAML-Datei erscheint nun eine Fehlermeldung wie:

Error when creating "pod/pod-kill.yaml": admission webhook "vauth.kb.io" denied the request: ... is forbidden on namespace
tidb-cluster-demo

Problem gelöst!

Hinweis: Falls der Nutzer auch für tidb-cluster-demo berechtigt ist, tritt dieser Fehler nicht auf.

Weitere Anleitungen​

Falls du erzwingen möchtest, dass kein Nutzer Chaos-Experimente über Namespaces hinweg erstellen darf, empfehle ich meinen vorherigen Blogbeitrag: Absicherung von Tenant-Services bei der Verwendung von Chaos Mesh mit OPA.

Abschließend​

Falls Sie an Chaos Mesh interessiert sind und mehr erfahren möchten, laden wir Sie herzlich ein, unserem Slack-Kanal beizutreten oder Pull Requests sowie Issues im GitHub-Repository einzureichen.