Hiérarchie testée

1. Clients
2. Clusters
3. Nœuds
4. VM / CT
5. Modèles
6. Stockage
7. Réseaux

Les permissions se propagent le long de cet arbre. Chaque niveau est vérifié : ce que chaque compte peut voir et ce qu’il peut modifier.

Quatre dimensions

• GUI

  Interface réelle

  La suite actionne les vraies commandes — menus, onglets, boutons et menus contextuels — exactement comme chaque utilisateur, et enregistre ce qui est affiché, masqué ou désactivé.

• API

  Appels directs

  Les mêmes opérations sont envoyées directement à l’API. Utilisé lorsque le produit n’offre pas de commande dans l’interface ou que les permissions du compte la masquent — toujours signalé dans le rapport.

• Isolation

  Contrôles de fuite

  Chaque lecture — listes, tableaux de bord, recherches, cartes et topologie — doit renvoyer uniquement les ressources du compte. Tout client, cluster, nœud, VM ou CT étranger compte comme une fuite.

• Sécurité

  Sondes d’isolation en écriture

  Des actions de gestion — créer, modifier, supprimer, démarrer/arrêter, migrer, cloner — sont tentées hors des droits du compte et doivent être refusées. La limitation de débit de l’API et le blocage de compte sont aussi testés.

Comptes testés

15 comptes couvrent tous les niveaux de permission : global (super-admin, admin et lecture seule), client, cluster, nœud et VM/CT individuelle, chacun avec un rôle Admin, Opérateur ou Lecteur — plus un compte sans aucune permission, qui ne doit rien voir ni rien faire.

Comment lire les résultats

• PASSLe compte s’est comporté exactement comme prévu : autorisé là où il en a le droit, bloqué ailleurs.
• FAILLe résultat diffère de ce qu’exige le modèle de permissions.
• SKIPLe contrôle ne s’applique pas à ce compte ou à cet environnement ; il ne compte ni comme réussite ni comme échec.
• FUITESLe compte a accédé à des données hors de son périmètre. L’objectif est toujours zéro.
• BLOCAGES CORRECTSActions interdites refusées exactement comme il se doit.