CLI-Referenz

CLI-Befehle sind nicht interaktiv. Schreibbefehle werden sofort ausgeführt, sofern kein unterstütztes --dry-run-Flag gesetzt ist. Flags nach dem Unterbefehl angeben. Befehlsspezifische Optionen mit kticket <command> --help oder kticket access <command> --help anzeigen.

Lange Optionen verwenden zwei Bindestriche, etwa --username alice oder --username=alice. Hilfe und Beispiele verwenden dieses Format; bestehende lange Optionen mit einem Bindestrich bleiben aus Kompatibilitätsgründen gültig.

Die Optionen --kubeconfig und --lang können auch vor dem Unterbefehl stehen. Ein beim Unterbefehl angegebenes --kubeconfig überschreibt den Wert auf Stammebene. Der Wert von --lang gilt nur für die TUI und wird von CLI-Befehlen ignoriert.

Befehle

Befehl	Zweck
`kticket [flags]`	Terminaloberfläche öffnen
`kticket license`	Lizenzstatus und lokale Maschinen-ID anzeigen
`kticket issue`	Token für ein Konto ausstellen und kubeconfig schreiben
`kticket list`	Verwaltete Konten auflisten; optional mit Zugangsdaten-Einträgen
`kticket revoke`	Konto löschen und alle seine Zugangsdaten widerrufen
`kticket access list`	Bekannte verwaltete und externe RBAC-Zuweisungen auflisten
`kticket access grant`	Berechtigung hinzufügen
`kticket access replace`	Berechtigung ersetzen
`kticket access remove`	Berechtigung entfernen
`kticket access plan`	Änderungen aus einer YAML-Datei anzeigen
`kticket access apply`	YAML-Berechtigungskonfiguration anwenden
`kticket access check`	Berechtigung für einen bestimmten Vorgang prüfen

Die TUI unterstützt Stapelausstellung und Namespace-Mehrfachauswahl. CLI issue akzeptiert pro Aufruf ein Konto und eine Berechtigungsauswahl.

Lizenzbefehle

kticket license machine-id
kticket license install /path/to/kticket-license.ktlicense
kticket license status
kticket license inspect /path/to/kticket-license.ktlicense

Informationen zu Kauf, Installationspfaden, --force und KTICKET_LICENSE_FILE finden Sie unter Lizenzkauf und Aktivierung.

Cluster- und Kontoauswahl

CLI-Kontobefehle akzeptieren --kubeconfig und --context. Standard für kubeconfig ist zuerst KUBECONFIG, dann ~/.kube/config; verwendet wird der aktuelle Kontext dieser Konfiguration. Kontextnamen müssen bereits in der kubeconfig existieren.

--namespace wählt den Konto-Namespace, in dem der ServiceAccount liegt. Standard für issue, revoke und access ist kticket-users. Bei list bedeutet ein ausgelassener Namespace alle Namespaces.

Der Konto-Namespace ist unabhängig vom Ziel-Namespace, in dem Zugriff gewährt wird. Das Ziel mit --role-namespace bei issue bzw. --target-namespace bei access-Befehlen angeben.

Zugangsdaten ausstellen

Vorhandene ClusterRole edit in app-prod zuweisen:

kticket issue --username bob --duration 8h \
  --access namespace --role edit --role-namespace app-prod \
  --output ./bob.kubeconfig

Vorhandene Role im Namespace binden:

kticket issue --username carol --access role \
  --role support --role-namespace app-prod

Zugangsdaten ohne neue Berechtigungen ausstellen:

kticket issue --username alice --access none \
  --duration 1h --output ./alice-laptop.kubeconfig

--access none behält bestehende Berechtigungen bei. Erneute Ausstellung für ein bestehendes Konto erstellt einen weiteren Token für denselben ServiceAccount; frühere Tokens werden nicht ersetzt.

Für Empfänger mit einem anderen API-Endpunkt:

kticket issue --username eve --access namespace \
  --role view --role-namespace app-prod \
  --server https://api.example.com:6443

Konto-Namespace und ServiceAccount werden erstellt, falls sie fehlen. Rollen und Ziel-Namespaces müssen existieren. Einzige Ausnahme ist die Bindung einer bestehenden ClusterRole im bei dieser Ausstellung erstellten Konto-Namespace.

Ausstellungsoptionen

Flag	Standard	Bedeutung
`--username`	Erforderlich	ServiceAccount-Name: DNS-1123-Label, höchstens 63 Zeichen; Kleinbuchstaben, Ziffern und Bindestriche, beginnend und endend mit Buchstabe oder Ziffer
`--namespace`	`kticket-users`	Konto-Namespace
`--duration`	`24h`	Angeforderte Token-Gültigkeitsdauer; Go-Dauer in ganzen Sekunden, mindestens `10m`
`--access`	`cluster`	`cluster`, `namespace`, `role` oder `none`
`--role`	`cluster-admin`	Zu bindende vorhandene Rolle
`--role-namespace`	Leer	Für Zugriffsmodi `namespace` und `role` erforderlich
`--server`	URL des ausgewählten Clusters	In die Ausgabe eingebetteter API-Endpunkt
`--insecure-skip-tls-verify`	`false`	API-Server-Zertifikatsprüfung für den Empfänger deaktivieren
`--output`	`~/<accountName>.<clusterName>.kubeconfig`	Neue Ausgabedatei; vorhandene Dateien und symbolische Links werden abgelehnt

Ohne Zugriffsflags wird clusterweiter Zugriff gewährt: cluster-admin . Für einen engeren Umfang explizite Flags verwenden. issue hat keine --dry-run-Option.

Zugriffsmodus	Erstellte Bindung	Umfang
`cluster`	ClusterRoleBinding an eine ClusterRole	Clusterweit
`namespace`	RoleBinding an eine ClusterRole	Nur `--role-namespace`
`role`	RoleBinding an eine Role	Nur `--role-namespace`
`none`	Keine neue Bindung	Bestehende Zugriffsrechte bleiben

Erzeugte kubeconfig

Die Datei enthält Bearer-Token, API-Endpunkt und konfigurierte CA-Daten, auch aus einer vom Administrator-kubeconfig referenzierten Datei. Ohne konfigurierte CA nutzt der Client die Systemvertrauensanker. Im unsicheren Modus werden CA-Daten weggelassen.

Der Clustername stammt aus dem ausgewählten Administratorkontext. Der erzeugte Kontext heißt <account>@<cluster> und wird als current-context ausgewählt. Sein Standard-Namespace ist der Konto-Namespace; für andere Workloads kubectl --namespace verwenden. --server ändert den Endpunkt, nicht den Clusternamen. Ist kein Clustername verfügbar, verwendet kticket cluster.

Der Standarddateiname enthält Konto- und Clusternamen, etwa alice.production-eu.kubeconfig. CLI --output wählt eine Datei; die TUI verlangt ein vorhandenes Verzeichnis.

Jede ausgestellte Zugangsdaten-Datei hat einen eigenen kubeconfig-Benutzeralias. Ausstellungs- und Ablaufzeiten stehen unter Zugangsdaten-Einträge.

Konten und Zugangsdaten auflisten

kticket list
kticket list --context my-cluster --namespace kticket-users
kticket list --credentials

Die Kontoliste enthält verwaltete Rollenbindungen. --credentials ergänzt erfasste Zugangsdaten-IDs, Zeitstempel und Audit-IDs. Die Einträge beschreiben von kticket ausgestellte und erfasste Zugangsdaten, nicht sämtliche nutzbaren Tokens.

Konto widerrufen

kticket revoke --context my-cluster --namespace kticket-users --username alice

Der Widerruf löscht zuerst den verwalteten ServiceAccount und bereinigt dann seine verwalteten Bindungen. Er betrifft alle Tokens dieser Konto-UID, löscht aber weder Namespace noch lokale kubeconfigs. Der Benutzername muss ein vorhandenes verwaltetes Konto bezeichnen.

Vor dem Neuerstellen eines Kontos nach fehlgeschlagener Bindungsbereinigung siehe Widerruf und Fehlerbehandlung.

Berechtigungen verwalten

Alle access-Befehle benötigen --username und akzeptieren die obigen Flags zur Cluster- und Kontoauswahl. Optional verlangt --expected-uid eine bestimmte ServiceAccount-UID, sodass Skripte gelöschte und neu erstellte Konten ablehnen können.

Berechtigung zu vorhandenem Konto hinzufügen, zunächst mit Vorschau:

kticket access grant --username alice \
  --target-namespace app-staging --cluster-role edit --dry-run
kticket access grant --username alice \
  --target-namespace app-staging --cluster-role edit

Für eine Role im Namespace --role support verwenden. Genau eines von --cluster-role und --role wählen. Standardumfang ist namespace; clusterweite Berechtigungen benötigen --scope cluster --cluster-role NAME ohne Ziel-Namespace.

Berechtigungen auflisten, dann über die Berechtigungs-ID ersetzen oder entfernen:

kticket access list --username alice

# Replace GRANT_ID with an ID from the list.
kticket access replace --username alice --grant-id GRANT_ID \
  --target-namespace app-staging --cluster-role view

# List again, then use the current grant ID for removal.
kticket access list --username alice
kticket access remove --username alice --grant-id CURRENT_GRANT_ID

grant, replace und remove unterstützen --dry-run, das einen Plan ohne Ressourcenschreibzugriffe berechnet. Ohne diese Option werden Änderungen sofort angewendet. Das Entfernen einer Berechtigung erhält Konto und Zugangsdaten. Externe Zuweisungen bleiben außerhalb der Kontrolle von kticket.

Alle referenzierten Rollen und Ziel-Namespaces müssen existieren. Zugriffsbefehle erstellen keine Namespaces. Mehrere Berechtigungen können in einem Namespace koexistieren. Änderungen gelten für alle gültigen Zugangsdaten des Kontos, ohne deren Ablauf zu verlängern.

Berechtigungssatz deklarieren

alice-access.yaml erstellen:

grants:
  - scope: namespace
    namespace: app-prod
    roleKind: ClusterRole
    roleName: view
  - scope: namespace
    namespace: app-staging
    roleKind: ClusterRole
    roleName: edit

Vorschau anzeigen und anwenden:

kticket access plan --username alice --file alice-access.yaml
kticket access apply --username alice --file alice-access.yaml

Die Datei beschreibt den vollständigen gewünschten Satz von kticket verwaltete Berechtigungen für das Konto. Ausgelassene verwaltete Berechtigungen werden entfernt; externe Zuweisungen bleiben. grants: [] entfernt alle verwalteten Berechtigungen. Das Feld grants muss ein explizites Array sein; null, Duplikate und unbekannte Felder werden abgelehnt.

Für eine Role im Namespace roleKind: Role verwenden. Für clusterweite Berechtigungen scope: cluster und roleKind: ClusterRole verwenden und namespace weglassen.

apply berechnet einen neuen Plan aus Datei und aktuellem Clusterzustand; ein gespeicherter Plan wird nicht ausgeführt. Beim Ersetzen werden alte Bindungen vor dem Anlegen neuer entfernt, was den Zugriff kurz unterbrechen kann. Zu Teilfehlern siehe Berechtigungsänderungen.

Vorgang prüfen

Prüfen, ob ein Konto Pod-Protokolle lesen darf:

kticket access check --username alice \
  --target-namespace app-staging --resource pods/log --verb get

Flag	Bedeutung
`--target-namespace`	Vorhandener Ziel-Namespace; bei clusterweiten Ressourcen weglassen
`--api-group`	API-Gruppe, etwa `apps`; für Core-Ressourcen weglassen
`--resource`	Erforderliche Ressource oder Unterressource, etwa `pods` oder `pods/log`
`--verb`	Erforderlicher API-Vorgang, etwa `get`, `list` oder `create`
`--resource-name`	Optionaler Name für die Berechtigungsabfrage

Die Prüfung nutzt SubjectAccessReview mit Kubernetes-Identität und Gruppen des Kontos. Eine benannte Ressource muss nicht existieren: Es ist eine Berechtigungsabfrage, keine Ressourcenanforderung. Ergebnisse sind ALLOWED, DENIED oder UNAVAILABLE; nur bei ALLOWED beendet sich die CLI erfolgreich.

Die Liste zeigt bekannte RBAC-Zuweisungen, nicht alle wirksamen Berechtigungen. Eine externe Zuweisung kann nach dem Entfernen einer verwalteten Berechtigung weiterhin einen Vorgang erlauben.