Comptes, identifiants et permissions

Comptes, identifiants et autorisations déterminent l’identité d’une requête, l’expiration de l’accès et les opérations permises.

Modèle d’identité

Un compte peut avoir plusieurs identifiants. Tous les identifiants valides partagent ses permissions. En émettre un autre ne remplace pas les précédents ; modifier les permissions ne prolonge pas leur expiration. Le compte et ses autorisations restent après l’expiration d’un jeton.

Le ServiceAccount réside dans l’espace de noms du compte, par défaut kticket-users. L’espace de noms cible limite la portée et peut être différent. Utilisez un espace de noms de comptes dédié. Un ServiceAccount existant de même nom est réutilisé et géré par kticket ; il devient donc révocable.

Par exemple, alice dans kticket-users s’authentifie en tant que system:serviceaccount:kticket-users:alice. Un alias local dans le kubeconfig ne change pas cette identité.

Modifications des permissions

• L’émission ajoute les autorisations sélectionnées aux permissions existantes. --access none n’ajoute rien et ne supprime pas les accès existants.
• Un RoleBinding limite les permissions à son espace de noms cible ; un ClusterRoleBinding accorde un accès global. kticket utilise les rôles existants sans créer de règles de rôle personnalisées.
• L’édition des accès ajoute, remplace ou retire des autorisations gérées. Une configuration YAML décrit leur ensemble complet souhaité.
• Les permissions RBAC Kubernetes sont additives. Les liaisons externes et attributions de groupe peuvent encore fournir un accès ; kticket les affiche en lecture seule.

La liste n’est pas un inventaire complet des permissions effectives. Pour une opération précise, utilisez la vérification du TUI ou kticket access check. Voir les exemples dans Référence CLI.

Un remplacement peut interrompre brièvement l’accès. En cas d’échec partiel, les opérations terminées ne sont pas annulées. Rechargez le compte et vérifiez un nouveau plan avant application ; voir dépannage.

kticket n’expire pas automatiquement les autorisations, n’attribue pas de permissions distinctes aux jetons d’un même compte et ne révoque pas un jeton isolément. Utilisez des comptes séparés pour des permissions ou révocations indépendantes.

Durée de vie du jeton

La durée demandée est par défaut 24h, au minimum 10m. Le serveur API peut ajuster la durée réelle. Utilisez l’expiration indiquée dans le résultat d’émission.

Les destinataires peuvent charger le kubeconfig avec kubectl sans installer kticket. Le fichier contient un jeton Bearer : protégez-le comme un identifiant et partagez-le via un canal fiable.

Révocation

kticket revoke et la révocation du TUI suppriment le ServiceAccount et ses liaisons gérées. Tous les identifiants du compte sont affectés. Kubernetes rejette les jetons lors de leur prochaine validation. Recréer un compte de même nom ne réactive pas les anciens jetons.

La révocation ne termine pas les connexions établies et ne supprime ni espaces de noms, ni rôles partagés, ni liaisons externes, ni kubeconfigs locaux.

Si le compte est supprimé mais le nettoyage des liaisons échoue, inspectez et retirez les liaisons restantes avec des identifiants administrateur avant de recréer le compte. Cela évite d’hériter de permissions résiduelles.

Enregistrements des identifiants

Exécutez kticket list --credentials, ou appuyez sur v dans la liste des comptes ou l’éditeur d’accès du TUI, pour consulter les ID, dates d’émission et d’expiration, et ID d’audit disponibles.

L’historique ne couvre que les identifiants enregistrés. Son absence ne prouve pas l’absence de jetons valides. « Non expiré » décrit l’horodatage, sans garantir l’authentification ou l’autorisation. Supprimer un enregistrement ne révoque pas son jeton.

Si le cluster enregistre les événements d’audit Kubernetes pertinents, les ID d’audit relient émission et requêtes ultérieures. La corrélation dépend des informations fournies par le cluster. Les ID locaux ne permettent pas de corrélation native ; les copies d’un même kubeconfig sont indiscernables.

Permissions administrateur

Les permissions nécessaires dépendent de l’opération :

Les restrictions de liaison RBAC Kubernetes s’appliquent toujours. Les simulations côté serveur exigent aussi des droits d’écriture. Un rôle administrateur restreint doit couvrir les opérations et portées de ressources du parcours. Activer une licence n’accorde pas de droits administrateur Kubernetes.