Choisir la source d’identité en créant un utilisateur : présent sur le serveur ou seulement dans le panneau

Le suffixe à la fin d’un nom d’utilisateur n’est pas un ornement. Il dit où vit le compte, et ce choix ne se déplace pas ensuite.

Deux types d’utilisateurs

Le premier type existe vraiment sur le serveur. Ce sont les utilisateurs propres à la machine, et leur mot de passe est celui de la machine. Le compte root avec lequel vous vous connectez d’abord est de ce type.

Le second type n’existe qu’à l’intérieur de Proxmox. Il n’a pas d’équivalent sur la machine : pas de shell, pas de connexion à distance, aucune place dans le système. Cela paraît incomplet, mais c’est justement ce que l’on veut. Laisser quelqu’un utiliser le panneau ne demande pas de lui ouvrir le serveur.

La première erreur classique

Un utilisateur est créé sur le serveur, puis le panneau refuse de le laisser entrer. Créer un compte système n’accorde à lui seul rien dans le panneau, car identité et droits sont deux travaux distincts. Le compte est reconnu, mais ce qu’il peut voir n’a jamais été dit. C’est le jumeau du problème où le droit est donné et où rien n’apparaît quand même.

La deuxième erreur classique

Un utilisateur est créé dans le panneau, puis quelqu’un essaie de se connecter au serveur avec. Cela ne marchera pas, et il est bon que cela ne marche pas. Un compte qui n’existe que dans le panneau existe précisément pour cela : sa portée s’arrête à l’écran.

Lequel choisir

Si la personne n’a pas besoin de toucher au serveur lui-même, choisissez le type qui n’existe que dans le panneau. Moins de portes s’ouvrent, et le jour où il faut fermer, cela se ferme à un seul endroit. Si quelqu’un doit réellement travailler sur le serveur, il lui faut de toute façon un compte système, mais ne prenez pas cette décision à cause d’un besoin lié au panneau.

Désactiver plutôt que supprimer

Un compte peut être désactivé sans être supprimé, et un compte peut recevoir une date de fin. Supprimer emporte l’historique avec l’entrée : la question de savoir qui avait reçu quoi reste sans réponse. Pour quelqu’un qui est parti, désactiver est le plus souvent la réponse plus juste que supprimer.

Donner à un groupe, pas à une personne

Donner directement à une personne est rapide le premier jour, recommence tout à la deuxième, et à la troisième on ne sait plus qui a quoi ni pourquoi. Donner à un groupe et y placer la personne laisse quelques secondes de travail pour chaque personne suivante et n’accumule aucune entrée éparse derrière vous.

Deuxième facteur

Un mot de passe seul est une porte. Si le panneau est joignable depuis l’extérieur, ou si le compte porte de l’autorité, activez le deuxième facteur. Pour l’automatisation, produire une clé distincte vaut mieux que partager un mot de passe, et c’est un sujet à part.

Ce que fait Atlas

Atlas montre l’accès comme une chaîne plutôt que comme une liste : le serveur, la portée, la source d’identité, l’utilisateur, le groupe, le rôle et le chemin tiennent reliés sur une même carte. Ainsi la question « par quelle porte cette personne entre-t-elle et jusqu’où va-t-elle » se répond en regardant, pas en assemblant des entrées dans sa tête. Mot de passe, deuxième facteur et clés d’automatisation se gèrent par compte, et comme Atlas ne construit pas son propre système de rôles, l’autorité vue à l’écran est la même que celle du serveur.