psouquet
commented
5 years ago Après quelques reflections, créer un workspace et visualiser un workspace ne relèvent pas vraiment de permissions. A moins de changer profondément le fonctionnement actuel de cockpit (ce qui est, bien sûr, envisageable).
- Actuellement: Il faut ajouter un utilisateur à aux membres d'un workspace pour qu'il puisse le visualiser, rendant la permission associée redondante (ou antinomique si on la retire).
- Actuellement: tout le monde à le droit de créer un workspace, les bus étant protégés par le mot de passe du conteneur et la passphrase de la topologie. Protéger la création de workspace revient à créer un rôle uniquement pour cela. Ce qui peut faire sens, mais alourdit probablement le quotidien d'administrateurs cockpits. Quelqu'un qui possède le mot de passe d'un conteneur pourra s'y connecter avec ou sans cockpit...
En prenant cela en considération. Voici un premier jet d'attribution de permissions :
| perm/role | admin cpt | admin wksp | dev | archi | deploy | hosting | admin métier |
|---|---|---|---|---|---|---|---|
| admin globale | ✔ | ||||||
| admin wksp | ✔ | ✔ | |||||
| att/det bus | ✔ | ✔ | |||||
| att/det cont | ✔ | ✔ | |||||
| lifecycle art | ✔ | ✔ | ✔ | ✔ | |||
| deploy/param art | ✔ | ✔ | ✔ | ||||
| niveau logs | ✔ | ✔ | ✔ | ✔ | |||
| edit modèle | ✔ | ✔ | |||||
| deploy modèle | ✔ | ✔ | |||||
| admin flux | ✔ | ✔ | ✔ | ||||
| traces monit | ✔ | ✔ | ✔ | ✔ |
Remarques:
- admin cpt est le seul rôle global il est attribué à un utilisateur, tous les autres rôles sont attribués à un utlisateur sur un workspace uniquement
- la permission d'administrer un wokspace est accordée aux administrateurs cockpit pour TOUS les workspaces existants, mais au administrateurs workspace uniquement sur le workspace sur lequel ils sont admin.
- on considére que l'admin workspace dispose, de base, de toutes les permissions (afin de ne pas avoir à s'attribuer les permissions sytématiquement lors de POCs ou tests).
- Edit pour refléter les changements apportés à lifecycle artifact jbi, et opérateur production
L'accès aux ressources et actions doivent être restreintes dans Cockpit. Notamment pour limiter les diverses administrations (techniques et métier) aux personnes responsables, d'autre part pour protéger les données sensibles (production par exemple). Pour ce faire (et afin de décider quelle implémentation est la plus pertinente) nous allons commencer par lister les différentes permissions à accorder ainsi que les roles qui grouperont ces permissions. Par la suite, les permissions et rôles pourront être associés puis affinés (assemblés, divisés ou modifiés) en un système satisfaisant.
Les permissions ne font pas uniquement références aux fonctionnalités existantes ou spécifiés, mais aussi aux fonctionnalités à venir. Ces dernières sont, de fait, mal définies. Il faudra accepter de prendre des décisions (concernant les rôles et permissions) basés sur l'intention de ces fonctionnalités sans digresser et entrer trop dans le détail.
Il faut noter aussi, qu'à priori les rôles pourront être attribués a un couple (utilisateur + workspace) afin d'offrir une granularité suffisante. Par exemple, les rôles généraux comme administrateur cockpit seraient directement liés à un utilisateur tandis que des rôles contextuels comme administrateur workspace seraient liés à un utilisateur et un workspace. Un même utilisateur pourra donc avoir un même rôle sur différent workspaces et ne pas l'avoir sur d'autres.
Permissions:
liste des permissions
remarques
L'accès aux différentes vues d'un workspace (topologie, services, api, modèle?, monitoring?) ne fait pas partie des permissions, il n'est pas limité en soi. Une fois que l'on a accès au workspace on a accès à ces vues. (les actions ou ressources proposés par ces vues peuvent cependant être limités) Edit: split de la permission cycle de vie jbi en deux permissions ( "deploy/undeploy/permission" et "cycle de vie")
Rôles
liste des rôles
remarques
Dans un premier temps, les rôles reprennent les utilisateurs cible de cockpit en y ajoutant deux profils d'administration. Edit: Precision de exploitant/opérateur de production en deux rôles: service déploiement et service hosting.