Concepts d'identité

Utilisateurs, groupes, rôles, privilèges et autorisations sur les objets, et comment Kyvernon décide ce qu'un utilisateur peut faire.

Kyvernon décide chaque requête à un seul endroit, qu'elle arrive par la console, la CLI, l'API native, l'API gRPC ou les points d'accès vSphere. La décision utilise l'utilisateur, les groupes de l'utilisateur, l'objet concerné par la requête et les rôles accordés sur cet objet ou au-dessus. Les administrateurs gèrent ces éléments dans la console sous Administration, dans la zone qu'ouvre le menu utilisateur.

Utilisateurs

Un utilisateur est un compte local ou un compte fédéré. Un compte local a un mot de passe que Kyvernon conserve sous forme de hachage Argon2id ; l'écran Utilisateurs (Utilisateurs) les crée et les gère. Un compte fédéré est créé à la première connexion par un fournisseur d'identité et n'a pas de mot de passe dans Kyvernon. Son nom d'utilisateur est le nom d'utilisateur préféré du fournisseur, en minuscules, et la colonne Source affiche Local ou Authentification unique.

Trois types de compte ont une fonction particulière :

Le premier administrateur, créé au premier démarrage du contrôleur. Il doit changer son mot de passe à la première connexion.
Le compte de secours (break-glass), nommé breakglass par défaut, à utiliser quand le fournisseur d'identité est indisponible. Il porte le badge Accès d’urgence, ses sessions durent une heure au plus, et son mot de passe doit être changé après chaque utilisation.
Les comptes de service, marqués avec Compte de service. Ils servent à l'automatisation et se connectent avec des jetons d'API, pas dans la console.

Un utilisateur peut être désactivé, ce qui met fin à ses sessions, et un utilisateur est verrouillé après des connexions échouées répétées. Le verrou prend fin de lui-même, ou un administrateur le lève.

Groupes

Un groupe est un ensemble nommé d'utilisateurs et d'autres groupes. Un utilisateur local est ajouté aux groupes sur l'écran Groupes (Groupes), et un utilisateur fédéré reçoit les groupes du claim des groupes du fournisseur d'identité à chaque connexion. Une autorisation peut désigner un groupe au lieu d'un utilisateur, de sorte qu'un rôle suit l'appartenance. Les groupes locaux, avec leur imbrication, et les politiques de mots de passe et de verrouillage sont conservés dans le store répliqué, si bien que chaque contrôleur les partage. Au premier démarrage de cette version, un contrôleur déplace le fichier de groupes d'une version antérieure dans le store et renomme le fichier en <nom>.migrated. Il écrit aussi une seule fois dans le store les fichiers de politique d'une version antérieure.

Rôles et privilèges

Un privilège est une opération autorisée, comme VirtualMachine.Interact.PowerOn ou Network.Config. Un rôle est un ensemble nommé de privilèges. Kyvernon compte neuf rôles intégrés que vous ne pouvez ni modifier ni supprimer, et vous pouvez créer les vôtres sur l'écran Rôles (Rôles). Les rôles intégrés sont Administrator, Read-only, No access, Virtual machine power user, Virtual machine user, Backup operator, Tenant administrator, Tenant user et Tenant service principal. Les pages Rôles intégrés et Privilèges listent le contenu de chacun.

Autorisations sur les objets

Une autorisation relie un principal (un utilisateur ou un groupe), un rôle et un objet de l'inventaire. Elle peut se propager aux enfants de l'objet. L'écran Autorisations (Autorisations) et l'onglet Autorisations de chaque objet les affichent et les modifient.

Pour décider si un utilisateur détient un privilège sur un objet, Kyvernon remonte de l'objet jusqu'à la racine :

Une autorisation qui ne se propage pas ne compte que sur l'objet lui-même.
Sur l'objet le plus proche qui a une autorisation pour l'utilisateur, cette autorisation décide. Une autorisation pour l'utilisateur lui-même l'emporte sur les autorisations de ses groupes. Plusieurs autorisations de groupe sur le même objet se combinent.
Rien au-dessus de cet objet n'est consulté. Une autorisation avec le rôle No access sur un enfant bloque donc un rôle accordé plus haut.
Le privilège est accordé lorsqu'un des rôles effectifs le contient.

Les utilisateurs d'un locataire sont confinés davantage : leurs privilèges ne s'appliquent que dans les dossiers et les groupes de ressources de leur locataire. Un rôle contenant un privilège de pare-feu réservé au fournisseur ne peut pas être accordé dans un locataire.

Sessions, jetons et journal d'audit

Une session commence à la connexion et prend fin par la déconnexion, par un délai d'inactivité, par sa durée de vie absolue ou quand un administrateur y met fin sur l'écran Sessions (Sessions). Un jeton d'API (Jetons d’API) est un identifiant de longue durée pour l'automatisation qui ne peut pas répondre à un code de vérification. Chaque modification des utilisateurs, des rôles, des autorisations, des jetons et des sessions est écrite dans le journal d'audit (Journal d’audit), avec les connexions échouées et refusées.