Aller au contenu

Utilisateurs & permissions (RBAC)

/admin/rbac/ — modèle RBAC dynamique.

Un catalogue de permissions (module, action) existe par défaut, par exemple :

  • servers.read_global ;
  • patching.manage ;
  • plugins.manage ;
  • system.admin.

Un rôle est un ensemble nommé de permissions cochées dans ce catalogue. Un utilisateur a un rôle global et, le cas échéant, des rôles supplémentaires au niveau module. Aucune hiérarchie implicite entre rôles — uniquement l'union des permissions accordées.

L'interface permet de créer ou modifier un rôle personnalisé en cochant des permissions, et de gérer les comptes utilisateurs (/users/) et leur rôle. Chaque action sensible est journalisée (/audit/).

Périmètre « mes serveurs »

Les rôles à périmètre restreint ont servers.read_assigned sans servers.read_global : opérateur, administrateur d'équipe, administrateur d'application. Ils ne voient que leurs serveurs, partout dans le portail et pas seulement sur la liste des serveurs. Un rôle avec servers.read_global voit tout.

Un serveur est visible pour un rôle restreint si :

  • il est public ;
  • ou vous en êtes propriétaire ;
  • ou vous êtes membre d'une de ses équipes ;
  • ou vous êtes membre d'une de ses applications.

Ce que le périmètre filtre

Le périmètre s'applique aux listes, fiches, exports, compteurs et graphiques de tout le portail :

  • vulnérabilités : la liste ne garde que les CVE qui touchent vos serveurs, avec des comptes calculés sur votre périmètre ;
  • logiciels ;
  • certificats : un certificat sans serveur n'est visible que si son empreinte est déployée sur l'un de vos serveurs ;
  • patching ;
  • tableau de bord ;
  • Risk Intel ;
  • PathFinder ;
  • posture Linux ;
  • applications ;
  • comptes ;
  • analyses (CrossRiver, SUSE Manager, Entra, signaux de détection) ;
  • pages des connecteurs, y compris les angles morts d'ELK : un rôle restreint ne voit que ses serveurs, jamais les hôtes absents de l'inventaire ;
  • réponses de l'assistant.

Pour le connecteur AWS : une instance EC2 est visible avec son serveur et un service managé avec son namespace (voir Amazon Web Services).

Ce qui reste masqué

  • Une fiche hors de votre périmètre répond « introuvable » : le portail ne révèle pas l'existence d'un serveur que vous ne pouvez pas voir.
  • Les lignes d'un connecteur qui ne sont rattachées à aucun serveur (machine virtuelle ou hôte non réconcilié) sont masquées pour un rôle restreint.
  • Analyse IA de Risk Intel : calculée sur tout le parc, elle n'est pas affichée à un rôle restreint et son lancement lui est refusé.
  • Fiches de contexte de l'IA : réservées aux rôles qui voient tout le parc.

Règles de délégation

  • Un rôle personnalisé ne peut contenir que des permissions que vous possédez vous-même ; en modification, vous ne pouvez qu'en ajouter que vous possédez (en retirer reste libre).
  • Hors super_admin, vous ne pouvez pas modifier votre propre rôle ni le rôle personnalisé que vous détenez.
  • Un rôle personnalisé ne peut être attribué à un compte que si vous en possédez toutes les permissions ; les rôles fournis (opérateur, auditeur, viewer…) restent attribuables.
  • Seul un super_admin peut activer, désactiver, modifier ou supprimer un compte super_admin.

Permissions d'action coûteuse ou destructive

Permission Effet Rôles qui l'ont par défaut
cves.snapshot Prendre un snapshot de persistance post-patching (page Vulnérabilités) super_admin, admin, operator
graph.run_analysis Lancer l'analyse IA de Risk Intel (modèle local) super_admin, admin, operator

| applications.delete | Supprimer une application (depuis sa page de modification) | super_admin, admin | | teams.delete | Supprimer une équipe (depuis sa page de modification) | super_admin, admin |

La suppression d'une application ou d'une équipe retire l'objet et ses associations (membres, groupes LDAP, serveurs rattachés) ; les serveurs et les comptes utilisateurs ne sont jamais supprimés. Elle est journalisée avec le nombre d'associations retirées.

Sans ces permissions, les boutons correspondants ne sont pas affichés et les requêtes sont refusées (403). À cocher sur un rôle personnalisé pour les donner à un autre profil ; sur une installation existante, les deux permissions sont ajoutées automatiquement aux rôles ci-dessus au démarrage.

Validation des formulaires

Utilisateurs, applications et équipes sont validés côté serveur : e-mail de la forme nom@domaine.tld, identifiant sans espace (lettres, chiffres, . _ - @), et longueurs maximales alignées sur la base (identifiant 64, e-mail 128, nom complet 128 ; nom d'application ou d'équipe 64, nom affiché d'équipe 128). Une valeur refusée affiche un message dans le formulaire.