Guide de l’interface terminal

Lancez le TUI avec kticket, ou choisissez un kubeconfig administrateur :

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

Utilisez au moins 50 colonnes et 18 lignes. Les terminaux larges affichent étapes, formulaire et aperçu côte à côte ; les petits utilisent un panneau. Le thème suit le fond clair ou sombre du terminal.

Langue et 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

L’ordre de sélection est --lang, KTICKET_LANG, LC_ALL, LC_MESSAGES, puis LANG. Les locales courantes comme zh_CN.UTF-8 sont reconnues. Une locale système non prise en charge donne l’anglais ; une langue explicite ou valeur KTICKET_LANG invalide provoque une erreur.

Sans réglage, le décalage UTC actuel de l’hôte choisit le chinois simplifié pour UTC+8, l’anglais sinon. Utilisez --lang ou KTICKET_LANG pour choisir explicitement.

Sur toute page, F2 parcourt anglais, chinois simplifié, chinois traditionnel, japonais, français et allemand sans perdre saisie, curseur, brouillons ni opération en cours. Ce choix vaut pour la session. Options, aide et sortie CLI restent en anglais ; noms, chemins, opérations API et erreurs sous-jacentes sont conservés.

À l’accueil, choisissez avec les flèches ou 1, 2, 3. Les actions propres à la page figurent en bas.

Les sélecteurs chargent des suggestions au focus. La saisie filtre et surligne la correspondance exacte. Les flèches sélectionnent et remplissent ; sans correspondance, Bas choisit la première, Haut la dernière. Tab complète sans avancer ; Entrée confirme. Une erreur de suggestions permet la saisie manuelle, mais les objets requis doivent être validés.

L’en-tête affiche cluster, alias local du kubeconfig administrateur et méthodes d’authentification. L’alias vient de la configuration, pas d’une identité Kubernetes vérifiée.

Émettre des identifiants

L’émission comporte six étapes. La navigation indique l’étape active ; les titres comme 2.1 désignent un champ de cette étape.

1. Environnement. Choisissez contexte et espace de noms du ServiceAccount, par défaut kticket-users.
2. Comptes. Saisissez un nom ou collez des noms séparés par virgules, espaces ou lignes. Vérifiez la liste dédoublonnée et les comptes créés ou réutilisés.
3. Configurer les autorisations. Ajoutez des autorisations communes. La liste commence vide. Entrée sur une liste vide ouvre une confirmation ; une seconde Entrée continue sans ajout, Échap ferme. Avec des ajouts, une seule Entrée suffit.
4. Paramètres des identifiants. Définissez durée, point d’accès API, TLS et dossier existant. Durée par défaut 24h, minimum 10m, en secondes entières. Le dossier par défaut est le dossier personnel de l’utilisateur, affiché en chemin absolu. Une saisie explicite prévaut.
5. Confirmer l’émission. Vérifiez ajouts, accès conservés, connexion et chaque nom <accountName>.<clusterName>.kubeconfig. Entrée émet ; Échap revient à l’édition.
6. Résultat de l’exécution. Inspectez chaque résultat et les opérations à vérifier.

Choisir les comptes

alice, bob, et carol sont sélectionnés. alice existe déjà ; bob et carol sera créé. dave existe mais n’est pas sélectionné. La coche indique l’appartenance au lot, indépendamment de la saisie ou du candidat surligné.

Le sélecteur contient noms choisis et comptes gérés existants. Choisir remplit la saisie ; Entrée ajoute au lot sans doublon.

Dans la liste, a ajoute et d retire du lot sans supprimer le ServiceAccount. ↑/↓ inspecte les attributions directes et de groupe.

Dans les autorisations communes, a ajoute, e modifie un ajout, d l’annule. Tous reçoivent les mêmes ajouts mais gardent leurs droits propres ; l’accès final peut différer. Exemple : alice, bob, carol avec ClusterRole/edit dans app-dev et app-test, plus ClusterRole/view dans app-prod.

Seuls l’espace de noms du compte et le ServiceAccount sont créables à l’émission. Rôles et cibles doivent exister, sauf liaison d’un ClusterRole existant dans le nouvel espace du compte. Un Role exige toujours un espace existant. Changer l’espace du compte efface la sélection cible pour révision.

Le lot entier est vérifié : noms, cibles, fichiers/liens existants, chemins dupliqués. Brouillons et vérifications n’écrivent ni autorisations ni jetons. Une vérification finale détecte les changements intervenus. La revue signale l’accès global cluster-admin et la désactivation TLS.

Sélectionner plusieurs espaces de noms cibles

app-dev et app-test sont cochés. Après confirmation, choisissez type et nom du rôle ; il s’applique à chaque cible.

Utilisez ↑/↓ et Space ou Tab pour sélectionner. Vous pouvez saisir des noms séparés par virgules ou coller plusieurs lignes. Enter valide, Ctrl+U efface.

Choisissez un rôle commun. Une autorisation distincte est créée par espace de noms, sans doublon, puis modifiable séparément. Pour un autre rôle, ajoutez une sélection.

Un Role doit exister sous le même nom dans chaque cible ; seules les correspondances communes sont proposées. Un ClusterRole limité à des espaces de noms crée des RoleBindings locaux, sans accès global.

Vérifier le lot

La revue affiche trois comptes, huit heures demandées, les autorisations communes et un fichier par compte. alice conserve son autorisation app-prod ; la sélectionner à nouveau ne crée pas de liaison dupliquée.

Résultats et reprise

Les comptes sont traités dans l’ordre ; les résultats s’actualisent et s’arrêtent au premier échec. ↑/↓ affiche opérations, expiration réelle et commande de révocation. Les chemins sont surlignés. Sur un bureau local, o révèle le fichier réussi sélectionné, ou le premier réussi si la ligne a échoué. Action masquée via SSH ou sans bureau. Aucun jeton n’est affiché.

Les identifiants et autorisations terminés restent. Dans la session, r vérifie et révise échecs ou attentes ; les réussis sont exclus. Un jeton émis suivi d’un échec marque le compte À vérifier, exclu des reprises automatiques. Inspectez son rapport avant réémission.

La reprise ne persiste que dans la session ; impossible après fermeture. Voir gestion des échecs pour les ressources pouvant rester.

Inspecter comptes et identifiants

Choisissez Comptes et autorisations. Le tableau montre comptes et liaisons. Sur un terminal large, la prochaine expiration suit la date de création. L’UID reste dans les détails de la ligne sélectionnée.

Dans l’historique, ↑/↓ sélectionne, PgUp/PgDn défile, Échap revient. Les modifications préparées sont conservées. Les enregistrements montrent alias, émission, expiration, ID complet et ID d’audit disponible. Création du compte et émission sont distinctes.

Modifier les permissions du compte

alice conserve ClusterRole/view dans app-prod, avec ClusterRole/edit préparé pour app-staging. Les détails montrent la référence complète de liaison. Entrée révise le brouillon avant application.

Sélectionnez un compte et appuyez sur Entrée pour ouvrir son éditeur.

Les éditions restent en brouillon local jusqu’à confirmation. Échap revient à l’édition. Appliquez ou abandonnez avant retour à la liste, actualisation ou révocation. Les attributions externes, grises et en lecture seule, permettent d’inspecter sujets et liaisons. Sélectionnez une autorisation gérée ou un ajout pour réviser le brouillon.

La sélection multiple est aussi disponible ici. Remplacer une ligne retire l’autorisation d’origine et ajoute le rôle dans chaque espace choisi.

Retirer avec d conserve compte et identifiants. Révoquer avec r supprime le ServiceAccount et invalide tous les jetons de son UID. Le TUI affiche toujours une confirmation.

La vérification accepte espace de noms, groupe API, ressource ou sous-ressource, verbe et nom facultatif. Le résultat décrit l’opération choisie, pas toutes les permissions effectives. Voir Référence CLI pour les scripts.