Référence CLI

Les commandes CLI sont non interactives. Les commandes d’écriture s’exécutent immédiatement, sauf si l’option --dry-run est prise en charge et définie. Placez les options après la sous-commande. Utilisez kticket <command> --help ou kticket access <command> --help pour les options propres à chaque commande.

Les options longues utilisent deux tirets, comme --username alice ou --username=alice. L’aide et les exemples suivent ce format ; les options longues à un seul tiret restent acceptées pour compatibilité.

Les options --kubeconfig et --lang peuvent aussi précéder la commande. La valeur --kubeconfig propre à une commande remplace celle définie à la racine. La valeur --lang concerne uniquement le TUI et est ignorée par les commandes CLI.

Commandes

Le TUI permet l’émission par lot et la sélection de plusieurs espaces de noms. La commande CLI issue accepte un compte et une sélection d’autorisation par appel.

Commandes de licence

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

Consultez achat et activation de licence pour l’achat, les chemins d’installation, --force et KTICKET_LICENSE_FILE.

Choix du cluster et du compte

Les commandes de compte CLI acceptent --kubeconfig et --context. Le kubeconfig utilise par défaut KUBECONFIG, puis ~/.kube/config ; le contexte est celui actuellement sélectionné dans cette configuration. Les noms de contexte doivent déjà exister dans le kubeconfig.

--namespace sélectionne l’espace de noms du compte, où réside le ServiceAccount. Sa valeur par défaut est kticket-users pour les commandes issue, revoke et access. Pour list, omettre l’espace de noms signifie tous les espaces de noms.

L’espace de noms du compte est indépendant de l’espace de noms cible où l’accès est accordé. Utilisez --role-namespace avec issue et --target-namespace avec les commandes access pour la cible.

Émettre des identifiants

Accorder le ClusterRole existant edit dans app-prod :

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

Lier un Role existant dans un espace de noms :

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

Émettre un identifiant sans ajouter d’autorisations :

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

--access none conserve les permissions existantes. Réémettre pour un compte existant crée un autre jeton pour le même ServiceAccount, sans remplacer les jetons antérieurs.

Pour les destinataires utilisant un autre point d’accès API :

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

L’espace de noms du compte et le ServiceAccount sont créés s’ils manquent. Les rôles et espaces de noms cibles doivent exister. Seule exception : lier un ClusterRole existant dans l’espace de noms du compte créé lors de cette émission.

Options d’émission

Omettre les options d’accès accorde un accès global de type cluster-admin . Utilisez des options explicites pour une portée plus restreinte. issue n’a pas d’option --dry-run.

Kubeconfig généré

Le fichier contient le jeton Bearer, le point d’accès API et les données CA configurées, y compris celles lues depuis un fichier référencé par le kubeconfig administrateur. Sans CA configurée, le client utilise les racines de confiance du système. En mode non sécurisé, la sortie omet les données CA.

Le nom du cluster vient du contexte administrateur sélectionné. Le contexte généré est <account>@<cluster>, choisi comme current-context. Son espace de noms par défaut est celui du compte ; utilisez kubectl --namespace pour les charges ailleurs. --server change le point d’accès sans changer le nom du cluster. Sans nom disponible, kticket utilise cluster.

Le nom de fichier par défaut inclut le compte et le cluster, comme alice.production-eu.kubeconfig. L’option CLI --output choisit un fichier ; le TUI exige un dossier existant.

Chaque identifiant émis a un alias utilisateur kubeconfig distinct. Consultez les enregistrements des identifiants pour les dates d’émission et d’expiration.

Lister les comptes et identifiants

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

La liste des comptes inclut les liaisons de rôles gérées. --credentials ajoute les ID d’identifiants, horodatages et ID d’audit enregistrés. Ces enregistrements décrivent les identifiants émis et consignés par kticket, pas tous les jetons utilisables.

Révoquer un compte

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

La révocation supprime d’abord le ServiceAccount géré, puis ses liaisons gérées. Elle affecte tous les jetons de cet UID de compte, sans supprimer l’espace de noms ni les kubeconfigs locaux. Le nom d’utilisateur doit désigner un compte géré existant.

Consultez révocation et gestion des échecs avant de recréer un compte dont le nettoyage des liaisons a échoué.

Gérer les autorisations

Toutes les commandes access exigent --username et acceptent les options de sélection du cluster et du compte ci-dessus. L’option --expected-uid impose un UID de ServiceAccount précis, permettant aux scripts de rejeter un compte supprimé puis recréé.

Ajouter une autorisation à un compte existant, en prévisualisant d’abord :

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

Utilisez --role support pour un Role local. Choisissez exactement l’un de --cluster-role et --role. La portée par défaut est namespace ; une autorisation globale exige --scope cluster --cluster-role NAME sans espace de noms cible.

Lister les autorisations, puis en remplacer ou retirer une par son ID :

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 et remove prennent en charge --dry-run, qui calcule un plan sans écrire de ressources. Sinon, les modifications s’appliquent immédiatement. Retirer une autorisation conserve le compte et ses identifiants. Les attributions externes restent hors du contrôle de kticket.

Tous les rôles et espaces de noms cibles référencés doivent exister. Les commandes d’accès ne créent jamais d’espaces de noms. Plusieurs autorisations peuvent coexister dans un même espace de noms. Les changements s’appliquent à tous les identifiants valides du compte sans prolonger leur expiration.

Déclarer un ensemble d’autorisations

Créer alice-access.yaml :

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

Prévisualiser et appliquer :

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

Le fichier décrit l’ensemble complet souhaité des autorisations gérées par kticket du compte. Les autorisations gérées omises sont retirées ; les attributions externes restent. grants: [] retire toutes les autorisations gérées. Le champ grants doit être un tableau explicite ; null, doublons et champs inconnus sont refusés.

Utilisez roleKind: Role pour un Role local. Pour une autorisation globale, utilisez scope: cluster et roleKind: ClusterRole et omettez namespace.

apply calcule un nouveau plan à partir du fichier et de l’état actuel du cluster, sans exécuter un plan sauvegardé. Les remplacements retirent les anciennes liaisons avant d’en créer de nouvelles, ce qui peut interrompre brièvement l’accès. Voir modifications des permissions pour les échecs partiels.

Vérifier une opération

Vérifier si un compte peut lire les journaux de pods :

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

La vérification utilise SubjectAccessReview avec l’identité Kubernetes et les groupes du compte. La ressource nommée n’a pas besoin d’exister : c’est une requête d’autorisation, pas une demande de ressource. Résultats : ALLOWED, DENIED ou UNAVAILABLE ; la CLI termine en échec sauf si le résultat est ALLOWED.

La liste montre les attributions RBAC connues, pas toutes les permissions effectives. Une attribution externe peut encore autoriser une opération après le retrait d’une autorisation gérée.