Anleitung zur Terminaloberfläche

Terminaloberfläche mit kticket starten oder Administrator-kubeconfig auswählen:

kticket --kubeconfig /path/to/admin.config

Mindestens 50 Spalten und 18 Zeilen verwenden. Breite Terminals zeigen Schritte, Formular und Vorschau nebeneinander; kleinere ein einzelnes Panel. Das Design folgt dem hellen oder dunklen Terminalhintergrund.

Sprache und Navigation

kticket --lang en
kticket --lang zh-CN
kticket --lang zh-TW
kticket --lang ja
kticket --lang fr
kticket --lang de
KTICKET_LANG=zh-CN kticket

Sprachauswahl in der Reihenfolge --lang, KTICKET_LANG, LC_ALL, LC_MESSAGES, dann LANG. Übliche Gebietsschemata wie zh_CN.UTF-8 werden erkannt. Nicht unterstützte Systemsprachen ergeben Englisch; ungültige explizite Sprache oder KTICKET_LANG-Werte führen zum Fehler.

Ohne Spracheinstellung wird bei aktuellem Host-Offset UTC+8 vereinfachtes Chinesisch gewählt, sonst Englisch. Mit --lang oder KTICKET_LANG explizit festlegen.

Auf jeder Seite wechselt F2 zwischen Englisch, vereinfachtem und traditionellem Chinesisch, Japanisch, Französisch und Deutsch. Eingabe, Cursor, Entwürfe und laufende Vorgänge bleiben erhalten. Gilt nur für die Sitzung. CLI-Flags, Hilfe und Ausgabe bleiben englisch; Namen, Pfade, API-Vorgänge und ursprüngliche Fehler bleiben unverändert.

Auf der Startseite mit Pfeilen oder 1, 2, 3 wählen. Seitenspezifische Aktionen stehen in der Fußzeile.

Selektoren laden Vorschläge beim Fokussieren. Eingabe filtert und markiert genaue Treffer. Pfeile wählen und füllen aus; ohne Treffer wählt Abwärts den ersten, Aufwärts den letzten Eintrag. Tab ergänzt, Enter bestätigt. Bei Vorschlagsfehlern bleibt manuelle Eingabe möglich, erforderliche Objekte müssen aber validiert werden.

Die Kopfzeile zeigt Cluster, lokalen Benutzeralias der Administrator-kubeconfig und Authentifizierungsarten. Der Alias stammt aus der Konfiguration und ist keine verifizierte Kubernetes-Identität.

Zugangsdaten ausstellen

Die Ausstellung hat sechs Phasen. Die obere Navigation zeigt die aktive Phase; Überschriften wie 2.1 bezeichnen ein Feld darin.

1. Umgebung. Kontext und ServiceAccount-Namespace wählen, standardmäßig kticket-users.
2. Konten. Namen eingeben oder mit Kommas, Leerzeichen oder Zeilenumbrüchen einfügen. Bereinigte Liste und zu erstellende bzw. wiederverwendete Konten prüfen.
3. Berechtigungen konfigurieren. Berechtigungen für alle Konten hinzufügen. Die Liste ist anfangs leer. Enter öffnet dann eine Bestätigung; erneut Enter fährt ohne Ergänzungen fort, Esc schließt. Mit Ergänzungen genügt einmal Enter.
4. Zugangsdaten konfigurieren. Dauer, API-Endpunkt, TLS-Prüfung und vorhandenes Ausgabeverzeichnis setzen. Dauer standardmäßig 24h, mindestens 10m, in ganzen Sekunden. Standardverzeichnis ist das Home-Verzeichnis des Benutzers als absoluter Pfad. Explizite Eingabe hat Vorrang.
5. Ausstellung bestätigen. Neue Berechtigungen, verbleibenden Zugriff, Verbindung und jeden <accountName>.<clusterName>.kubeconfig-Dateinamen prüfen. Enter startet, Esc bearbeitet weiter.
6. Ausführungsergebnis. Ergebnisse je Konto und Vorgänge mit Prüfbedarf ansehen.

Konten auswählen

alice, bob und carol sind ausgewählt. alice existiert bereits; bob und die carol wird erstellt. dave existiert, ist aber nicht ausgewählt. Das Häkchen zeigt die Stapelzugehörigkeit unabhängig von Eingabe oder hervorgehobenem Vorschlag.

Der Selektor enthält gewählte Namen und vorhandene verwaltete Konten. Auswahl füllt die Eingabe; Enter ergänzt den Stapel ohne Duplikate.

In der Kontoliste ergänzt a Namen, d entfernt sie nur aus dem Stapel. Der ServiceAccount bleibt. ↑/↓ zeigt direkte und Gruppenzuweisungen.

Bei gemeinsamen Berechtigungen ergänzt a, bearbeitet e eine Ergänzung und verwirft d sie. Alle erhalten dieselben Ergänzungen, behalten aber eigene Rechte; der endgültige Zugriff kann abweichen. Beispiel: alice, bob, carol mit ClusterRole/edit in app-dev und app-test sowie ClusterRole/view in app-prod.

Bei Ausstellung können nur Konto-Namespace und ServiceAccount erstellt werden. Rollen und Ziel-Namespaces müssen existieren; ausgenommen ist eine vorhandene ClusterRole im neu erstellten Konto-Namespace. Eine Role braucht immer einen vorhandenen Namespace. Konto-Namespace-Wechsel löscht die Zielauswahl zur erneuten Prüfung.

Vorab wird der gesamte Stapel auf Namen, fehlende Ziele, vorhandene Dateien/Links und doppelte Ausgabepfade geprüft. Entwurf und Prüfung schreiben keine Berechtigungen oder Tokens. Bei Ausstellung wird erneut geprüft. Die Übersicht hebt clusterweiten cluster-admin-Zugriff und deaktiviertes TLS hervor.

Mehrere Ziel-Namespaces auswählen

app-dev und die app-test sind markiert. Nach Bestätigung Rollentyp und -name wählen; die Rolle gilt für jedes Ziel.

Mit ↑/↓ navigieren und Space oder Tab auswählen. Kommagetrennte Namen oder mehrzeilige Listen sind möglich. Enter prüft, Ctrl+U löscht die Auswahl.

Eine Rolle für alle Ziele wählen. Je Namespace entsteht eine eigene Berechtigung ohne Duplikate, später einzeln bearbeitbar. Für andere Rollen eine weitere Auswahl hinzufügen.

Eine Role muss in allen ausgewählten Namespaces gleichnamig existieren; nur gemeinsame Namen werden vorgeschlagen. Namespace-begrenzte ClusterRole-Auswahl erstellt RoleBindings in den Zielen, keinen clusterweiten Zugriff.

Stapel prüfen

Die Übersicht zeigt drei Konten, acht Stunden Dauer, gemeinsame Berechtigungen und je eine Ausgabedatei. alice behält die bestehende Berechtigung app-prod ; erneute Auswahl erzeugt keine doppelte Bindung.

Ergebnisse und Wiederholung

Konten laufen nacheinander; Ergebnisse aktualisieren sich und stoppen beim ersten Fehler. ↑/↓ zeigt Vorgänge, tatsächlichen Ablauf und Widerrufsbefehl. Dateipfade sind hervorgehoben. Auf lokalem Desktop öffnet o die gewählte erfolgreiche Datei im Dateimanager; bei Fehlerzeilen die erste erfolgreiche. Über SSH und ohne Desktop ist dies ausgeblendet. Tokenwerte werden nie angezeigt.

Fertige Zugangsdaten und Berechtigungen bleiben. In derselben Sitzung prüft r fehlgeschlagene oder ausstehende Konten; erfolgreiche werden ausgeschlossen. Nach Token-Ausstellung mit Folgefehler erhält das Konto Prüfung nötig und wird nicht automatisch wiederholt. Vor Neuausstellung Bericht prüfen.

Wiederholungszustand gilt nur für diese Sitzung; nach Beenden keine Fortsetzung. Zu möglichen Restressourcen siehe Fehlerbehandlung.

Konten und Zugangsdaten prüfen

Konten und Berechtigungen wählen. Die Tabelle zeigt Konten und Bindungen. Auf breiten Terminals folgt der nächste Ablauf auf die Erstellungszeit. Die UID steht in den Zeilendetails.

Im Verlauf wählt ↑/↓, PgUp/PgDn scrollt und Esc kehrt zurück. Berechtigungsentwürfe bleiben erhalten. Angezeigt werden Alias, Ausstellung, Ablauf, vollständige ID und verfügbare Audit-ID. Kontoerstellung und Ausstellung sind unterschiedliche Zeiten.

Kontoberechtigungen bearbeiten

alice behält ClusterRole/view in app-prod, mit ClusterRole/edit vorgemerkt für app-staging. Zeilendetails zeigen die vollständige Bindungsreferenz. Enter prüft den Entwurf vor der Anwendung.

Konto wählen und mit Enter den Zugriffseditor öffnen.

Änderungen bleiben bis zur Bestätigung lokale Entwürfe. Esc führt zurück zur Bearbeitung. Vor Kontoliste, Aktualisierung oder Widerruf anwenden oder verwerfen. Externe Zuweisungen sind grau und schreibgeschützt; Auswahl zeigt Subjekte und Bindungen. Verwaltete Berechtigung oder Ergänzung zur Entwurfsprüfung wählen.

Auch hier ist Namespace-Mehrfachauswahl möglich. Eine Zeile zu ersetzen entfernt die ursprüngliche Berechtigung und ergänzt die Rolle in jedem gewählten Namespace.

Entfernen mit d erhält Konto und Zugangsdaten. Widerruf mit r löscht den ServiceAccount und macht alle Tokens seiner UID ungültig. Die TUI zeigt immer eine Bestätigungsseite.

Die Prüfung akzeptiert Namespace, API-Gruppe, Ressource/Unterressource, Verb und optionalen Namen. Ergebnisse beschreiben den gewählten Vorgang, nicht alle wirksamen Kontorechte. Für Skripte siehe CLI-Referenz.