Konten, Zugangsdaten und Berechtigungen

Konten, Zugangsdaten und Berechtigungen bestimmen die Identität einer Anfrage, den Zugriffsablauf und die erlaubten Vorgänge.

Identitätsmodell

Ein Konto kann mehrere Zugangsdaten besitzen. Alle gültigen Zugangsdaten teilen seine Berechtigungen. Neue Ausstellungen ersetzen frühere nicht; Berechtigungsänderungen verlängern keinen Ablauf. Konto und Berechtigungen bleiben nach Token-Ablauf bestehen.

Der Konto-Namespace enthält den ServiceAccount und ist standardmäßig kticket-users. Der Ziel-Namespace begrenzt den Berechtigungsumfang und kann abweichen. Einen dedizierten Konto-Namespace verwenden. Ein vorhandener gleichnamiger ServiceAccount wird wiederverwendet und von kticket verwaltet, sodass er durch Kontowiderruf gelöscht werden kann.

Zum Beispiel authentifiziert sich alice in kticket-users als system:serviceaccount:kticket-users:alice. Ein lokaler Benutzeralias in der kubeconfig ändert diese Identität nicht.

Berechtigungsänderungen

• Die Ausstellung ergänzt bestehende Berechtigungen um die ausgewählten Zuweisungen. --access none fügt keine hinzu und entfernt keinen bestehenden Zugriff.
• Ein RoleBinding begrenzt Berechtigungen auf seinen Ziel-Namespace; ein ClusterRoleBinding gewährt clusterweiten Zugriff. kticket nutzt vorhandene Rollen und erstellt keine eigenen Rollenregeln.
• Die Zugriffsbearbeitung ergänzt, ersetzt oder entfernt verwaltete Berechtigungen. Eine YAML-Konfiguration beschreibt den vollständigen gewünschten Satz.
• Kubernetes-RBAC-Berechtigungen wirken additiv. Externe Bindungen und Gruppenzuweisungen können weiterhin Zugriff gewähren; kticket zeigt sie schreibgeschützt an.

Die Liste erfasst nicht alle wirksamen Berechtigungen. Bestimmte Vorgänge mit der TUI-Prüfung oder kticket access check prüfen. Beispiele unter CLI-Referenz.

Das Ersetzen kann den Zugriff kurz unterbrechen. Bei Teilfehlern werden abgeschlossene Vorgänge nicht zurückgerollt. Konto neu laden und neuen Plan vor Anwendung prüfen; siehe Fehlerbehebung.

kticket lässt Berechtigungen nicht automatisch ablaufen, vergibt keine getrennten Rechte für Tokens desselben Kontos und widerruft keinen einzelnen Token unabhängig. Für unabhängige Berechtigungen oder Widerrufe getrennte Konten verwenden.

Token-Gültigkeitsdauer

Die angeforderte Dauer beträgt standardmäßig 24h, mindestens 10m. Der API-Server kann sie anpassen. Maßgeblich ist der im Ausstellungsergebnis angezeigte Ablauf.

Empfänger können die kubeconfig direkt mit kubectl nutzen, ohne kticket zu installieren. Die Datei enthält einen Bearer-Token: als Zugangsdaten schützen und über einen vertrauenswürdigen Kanal teilen.

Widerruf

kticket revoke und die TUI-Widerrufsaktion löschen ServiceAccount und verwaltete Bindungen. Dies betrifft alle Zugangsdaten des Kontos. Kubernetes lehnt die Tokens bei erneuter Prüfung ab. Ein neues gleichnamiges Konto macht alte Tokens nicht wieder gültig.

Widerruf beendet keine bestehenden Verbindungen und entfernt keine Namespaces, gemeinsamen Rollen, externen Bindungen oder lokalen kubeconfigs.

Wenn das Konto gelöscht wurde, die Bindungsbereinigung aber fehlschlug, verbleibende Bindungen mit Administratorzugangsdaten prüfen und entfernen, bevor das Konto neu erstellt wird. So erbt das neue Konto keine Restberechtigungen.

Zugangsdaten-Einträge

kticket list --credentials ausführen oder v in TUI-Kontoliste bzw. Zugriffseditor drücken, um Zugangsdaten-IDs, Ausstellungs- und Ablaufzeiten sowie verfügbare Audit-IDs zu sehen.

Der Verlauf umfasst nur erfasste Zugangsdaten. Fehlende Einträge beweisen nicht, dass keine gültigen Tokens existieren. „Nicht abgelaufen“ beschreibt den Zeitstempel, garantiert aber keine erfolgreiche Authentifizierung oder Autorisierung. Löschen eines Eintrags widerruft seinen Token nicht.

Zeichnet der Cluster relevante Kubernetes-Audit-Ereignisse auf, können Audit-IDs Ausstellung und spätere Anfragen verbinden. Das hängt von den bereitgestellten Audit-Daten ab. Lokale IDs ermöglichen keine native Audit-Korrelation; Kopien derselben kubeconfig sind nicht unterscheidbar.

Administratorberechtigungen

Benötigte Berechtigungen hängen vom Vorgang ab:

Kubernetes-RBAC-Bindungsbeschränkungen gelten weiterhin. Auch serverseitige Probeläufe benötigen Schreibrechte. Eingeschränkte Administratorrollen müssen die verwendeten Vorgänge und Ressourcenbereiche abdecken. Lizenzaktivierung gewährt keine Kubernetes-Administratorrechte.