Team & Rollen
Im Bereich Team des Dashboards lädst du Personen in dein Team ein und entscheidest, was jede von ihnen tun darf — sowohl im Dashboard als auch, bei gehosteten Clustern, innerhalb von Kubernetes selbst. Der Zugriff wird auf zwei Wegen gewährt, die sich kombinieren: eine Stufe, die jeder hat, plus optionale benutzerdefinierte Rollen.
Mitglieder einladen
Lade ein Mitglied per E-Mail ein. Es erhält eine Einladung und meldet sich mit kubehz an (E-Mail + Passwort mit Zwei-Faktor, GitHub oder deinem eigenen SSO — siehe Identität & Anmeldung). Das Hinzufügen oder Ändern eines Mitglieds ist eine sensible Aktion und fordert dich auf, mit einer frischen Zwei-Faktor-Anmeldung zu bestätigen.
Nur ein Team-Owner oder Admin kann Mitglieder und Rollen verwalten.
Die drei Zugriffsstufen
Jedes Mitglied hat genau eine Stufe. Auf einem gehosteten Cluster bildet die Stufe direkt auf den integrierten Kubernetes-Zugriff ab:
| Stufe | Im Cluster | Kubernetes-Rolle |
|---|---|---|
| Admin | Volle Kontrolle, einschließlich Secrets und RBAC. | cluster-admin |
| Editor | Die meisten Ressourcen lesen und schreiben; keine Rollen oder Cluster-Einstellungen. | edit |
| Viewer | Nur lesend, ohne Secrets. | view |
Die Stufe ist die Grundlage. Für die meisten Teams sind die drei Stufen alles, was du brauchst.
Benutzerdefinierte Rollen
Wenn eine Stufe zu weit gefasst ist, definiere eine benutzerdefinierte Rolle: enger gefasster, sicherer Zugriff, den du in einer Berechtigungsmatrix zusammenstellst — Zeilen sind Kubernetes-Ressourcen (Pods, Logs, Deployments, deine CRDs, …), Spalten sind Aktionen (get, list, watch, create, update, delete, …); hake genau das an, was die Rolle darf. Eine benutzerdefinierte Rolle wird zusätzlich zur Stufe eines Mitglieds gewährt — sie fügt immer nur Zugriff hinzu, reduziert ihn nie.
Vorlagen. Du musst nicht mit einem leeren Raster beginnen. Der Editor bringt geprüfte Ausgangspunkte mit — Log Viewer, Debugger, Deployment Manager und Cluster Observer —, die die Matrix vorbefüllen; passe die Haken an und speichere. Gespeichert wird immer die Matrix selbst — was du siehst, ist genau das, was der Cluster durchsetzt.
Deine eigenen Ressourcen. Die Matrix listet die Standard-Kubernetes- Ressourcen plus alles, was deine gehosteten Cluster tatsächlich bereitstellen — einschließlich CRDs — mit einem Badge, welche Cluster die jeweilige Ressource kennen. Cluster dürfen sich unterscheiden: Eine Regel, die eine Ressource benennt, die ein Cluster nicht hat, ist völlig in Ordnung und bleibt dort einfach wirkungslos, bis die CRD auftaucht.
Sensible Aktionen (Secrets lesen, exec in Pods, Impersonation, RBAC-Eskalation) werden im Editor markiert, damit eine zu weit gefasste Rolle vor dem Speichern sichtbar ist.
Geltungsbereich. Eine Rolle gilt standardmäßig für den gesamten Cluster, oder du kannst sie auf benannte Namespaces beschränken (gib zum Beispiel einem Auftragnehmer Debugger nur in staging).
Zuweisen. Erstelle Rollen im Bereich Rollen des Team-Bereichs und hake sie dann bei einem Mitglied an (oder im Einladungsformular). Das Definieren einer Rolle gewährt für sich genommen nichts; das Zuweisen schon.
Cluster pro Mitglied wählen
Sowohl die Stufe als auch jede Rollenzuweisung lässt sich auf ausgewählte gehostete Cluster beschränken. Standardmäßig gilt der Zugriff eines Mitglieds für alle gehosteten Cluster deines Teams; wähle bestimmte Cluster, wenn jemand nur einen Teil davon anfassen soll — zum Beispiel ein externer Entwickler, der nur auf dem Staging-Cluster Editor ist, plus Log Viewer auf Produktion.
Die Cluster-Beschränkung gilt für gehostete Cluster (dort verwaltet kubehz den Zugriff). Selbst gehostete Cluster behalten den Zugriff, den du selbst konfigurierst.
Bring dein eigenes SSO mit
Du kannst deinen eigenen externen OIDC-Identitätsanbieter föderieren (Okta, Entra, Google Workspace oder einen beliebigen OIDC-Anbieter), sodass sich dein Team mit deiner bestehenden Unternehmensidentität anmeldet. kubehz vermittelt die Anmeldung und gewährt denselben Zugriff — deine Stufe und deine Rollen entscheiden weiterhin, was jede Person tun darf. Siehe Identität & Anmeldung.
Wie es den Cluster erreicht
Deine Stufe und deine benutzerdefinierten Rollen werden zu Gruppen-Claims in dem Token, das kubehz bei deiner Anmeldung ausstellt. Der API-Server eines gehosteten Clusters vertraut kubehz als seinem Identitätsanbieter und bildet diese Gruppen auf Kubernetes-RBAC ab — beschränkt auf dein Team, sodass der Zugriff eines Teams niemals auf den Cluster eines anderen angewendet werden kann. Du verbindest dich mit der OIDC-kubeconfig; der Cluster setzt genau deine Rolle durch.
Nächste Schritte
- Verbinden mit kubectl — die OIDC-kubeconfig herunterladen und verwenden.
- Identität & Anmeldung — Anmeldeoptionen und Team-Isolation.
- Dashboard — der Rest dessen, was dir das Dashboard bietet.
Doku-Status
| Aspekt | Detail |
|---|---|
| Zustand | aktiv |
| Zuletzt geprüft | 2026-07-16 |