Rôles, groupes de permissions et accès

Les trois niveaux qui décident de ce que chaque membre peut faire, les groupes dont dispose toute organisation dès le départ, et les règles qui empêchent quiconque de s'élever.

Chaque personne d'une organisation a un rôle. En plus, elle peut être placée dans des groupes de permissions, qui ajoutent des permissions à l'échelle de l'organisation, et recevoir un accès à des ressources individuelles. Ce qu'un membre peut faire, c'est l'ensemble de ce que ces trois niveaux lui donnent.

Aucun niveau ne retire jamais une permission. Un refus est simplement l'absence d'accès accordé, ce qui permet toujours de répondre à « pourquoi peut-il faire cela ? » en regardant le rôle du membre, ses groupes et les accès qui le nomment.

Niveau 1 : les rôles de l'organisation

Trois rôles, volontairement grossiers.

Rôle Ce qu'il couvre
Propriétaire Tout. Un seul par organisation.
Administrateur Tout, sauf nommer des administrateurs et modifier les informations légales de l'organisation.
Développeur Crée des ressources et travaille sur ce qu'il a créé ou reçu. Ne voit rien d'autre.

Un développeur peut créer des applications, des réseaux, des coffres, des namespaces d'images, des bases de données, des instances de bases de données, des services gérés et des solutions ; connecter son propre compte GitHub ou GitLab ; utiliser l'agent de code et créer des projets studio ; et voir qui d'autre fait partie de l'organisation. Il ne voit que ce qu'il a créé et ce qu'on lui a donné. L'application d'un collègue n'apparaît pas dans sa liste et ne répond pas à son nom.

La personne qui crée une ressource détient tout sur elle, quel que soit son rôle.

Ce que seul le propriétaire peut faire

Deux permissions appartiennent au seul propriétaire :

  • Nommer et révoquer des administrateurs. Un administrateur capable de nommer des administrateurs ne pourrait jamais être rétrogradé.
  • Modifier les informations légales de l'organisation : la raison sociale, les numéros d'immatriculation et l'adresse auxquels sont établis les factures et les contrats.

Ces permissions ne peuvent être placées dans un groupe de permissions ni confiées à un identifiant de la CLI, par personne, propriétaire compris.

Niveau 2 : les groupes de permissions

Les rôles sont grossiers à dessein, et la plupart des équipes ont besoin d'un intermédiaire : quelqu'un qui déploie sans supprimer, quelqu'un qui s'occupe des bases de données, quelqu'un qui gère la boutique. Un groupe de permissions est un ensemble nommé de permissions d'organisation. Y placer un membre ajoute ces permissions à son rôle.

Les groupes héritent. Un groupe peut désigner d'autres groupes comme parents, et ses membres détiennent tout ce que détiennent les parents, de manière transitive. Élargir un parent élargit chaque groupe construit dessus. Un groupe ne peut pas hériter de lui-même, même par l'intermédiaire d'autres.

Les groupes intégrés

Toute organisation dispose de ces groupes dès le départ. Ils sont définis par la plateforme : vous pouvez y placer des membres et construire vos propres groupes par-dessus, mais vous ne pouvez ni les modifier ni les supprimer. Une mise à niveau de la plateforme qui ajoute une permission à l'un d'eux s'applique à toutes les organisations à la fois.

Groupe Hérite de Ajoute En pratique
application-viewers application:read-any, member:read Voir toutes les applications et lire leurs journaux.
deployers application-viewers application:create, application:deploy-any, network:create, git:connect Créer des applications, et déployer, démarrer et arrêter toutes les applications. Ne peut ni modifier leur configuration ni les supprimer.
application-maintainers deployers application:update-any Modifier aussi la configuration, les secrets et l'exposition de toutes les applications.
application-administrators application-maintainers application:write-any, application:delete-any Tout sur toutes les applications, y compris leur suppression.
vault-managers vault:create, vault:manage-any Créer des coffres et gérer tous les coffres et tous les secrets.
database-administrators database:create, database:manage-any, database-instance:create, database-instance:manage-any Créer et gérer toutes les bases de données et instances de bases de données, y compris les sauvegardes et les restaurations.
service-operators service:create, service:manage-any Créer et exploiter tous les services gérés : Keycloak, Kafka, RabbitMQ, Redis.
solution-managers solution:create, solution:manage-any Déployer et gérer toutes les solutions : WordPress, WooCommerce, Odoo, n8n et les autres.
agent-users agent:use, project:create Créer des projets studio et utiliser l'agent de code, en dépensant le crédit de l'organisation.
agent-administrators agent-users project:manage-any Tout ce que peuvent faire les utilisateurs de l'agent, sur tous les projets studio.
iam-administrators member:read, member:manage, iam:manage Inviter et gérer les membres, gérer les groupes et accorder l'accès aux ressources — uniquement ce qu'ils détiennent eux-mêmes.
billing-viewers billing:read Consulter le solde, le grand livre et les dépenses.
platform-engineers application-maintainers, database-administrators, service-operators, vault-managers network:manage-any, namespace:create, namespace:manage-any Les quatre réunis, plus tous les réseaux et namespaces d'images.

Les permissions sur les applications sont des sous-ensembles les unes des autres :

Permission Sur toutes les applications de l'organisation
application:read-any La voir et lire ses journaux.
application:deploy-any En plus, la construire, la déployer, la démarrer et l'arrêter.
application:update-any La voir, lire ses journaux, modifier sa configuration et ses secrets, parcourir ses volumes.
application:delete-any La voir et la supprimer.
application:write-any Tout.

isogrid iam permissions liste chaque permission avec une description d'une ligne, et isogrid iam groups get <group> montre exactement ce que détient un groupe, héritage compris. Voir Dépôts, groupes et accès.

Niveau 3 : l'accès à une ressource

Un accès accordé donne à un membre, ou à un groupe, un ensemble de capacités sur une ressource : une application, une base de données, un coffre, un dépôt. C'est ainsi qu'un développeur entre dans quelque chose qu'il n'a pas créé, et qu'une personne extérieure accède à une seule chose, et une seule.

Les capacités sont précises. Sur une application, par exemple :

Capacité Permet de
app:view La voir et lire sa configuration. Impliquée par toutes les autres.
app:logs Lire les journaux de construction et d'exécution.
app:deploy La construire et la déployer.
app:lifecycle La démarrer et l'arrêter.
app:configure Modifier les ressources, les réseaux, l'environnement et l'exposition.
app:secrets Définir les secrets de conteneur et lister leurs noms.
app:files Parcourir ses volumes.
app:share Décider qui d'autre peut l'utiliser.
app:delete La supprimer.

Chaque autre type de ressource a son propre ensemble, sur le même modèle : view, les actions possibles sur la ressource, share et delete.

Les préréglages regroupent les cas courants, si bien que la plupart des accès se résument à un seul choix :

Ressource Préréglages
Application viewer (voir, journaux) · operator (en plus déployer, démarrer et arrêter, parcourir les fichiers) · maintainer (tout sauf supprimer)
Dépôt repo-viewer · repo-deployer · repo-maintainer · repo-admin
Base de données database-user (se connecter) · database-owner
Instance de base de données instance-user · instance-operator (en plus exploiter et sauvegarder) · instance-manager (tout sauf supprimer)
Coffre vault-consumer (associer des secrets à des applications) · vault-editor (en plus les modifier) · vault-manager
Namespace d'images namespace-puller · namespace-publisher (en plus pousser) · namespace-manager
Image image-consumer (déployer à partir d'elle) · image-manager
Réseau network-user (y rattacher des applications) · network-manager
Service géré service-user (informations de connexion) · service-operator (en plus exploiter) · service-manager (tout sauf supprimer)
Solution solution-user · solution-operator · solution-manager (tout sauf supprimer)
Projet studio project-viewer · project-collaborator (solliciter l'agent, modifier, réveiller le sandbox) · project-maintainer (tout sauf supprimer)

Un préréglage est développé au moment où l'accès est enregistré. L'accès lui-même est un simple ensemble de capacités : vous pouvez donc partir d'un préréglage et en retirer un élément.

Un accès couvre la ressource, pas une copie de celle-ci. Un accès sur une application couvre son service, ses constructions et ses volumes. Un accès sur un dépôt couvre toutes les applications construites à partir de lui, y compris celles créées plus tard.

Les accès s'accordent depuis les paramètres de partage de la ressource dans la console, ou, pour les dépôts, avec isogrid repos grant.

Vous ne pouvez donner que ce que vous détenez

C'est la règle qui permet de confier sans risque la gestion des accès à d'autres personnes que le propriétaire. Elle s'applique partout :

  • Créer ou modifier un groupe. Vous ne pouvez pas donner à un groupe une permission que vous ne détenez pas, ni le faire hériter d'un groupe qui détient plus que vous.
  • Placer quelqu'un dans un groupe. Vous ne pouvez pas ajouter un membre à un groupe qui détient une permission que vous n'avez pas.
  • Accorder un accès sur une ressource. Il vous faut la capacité share de cette ressource, et vous ne pouvez accorder que les capacités que vous y détenez vous-même. Quelqu'un qui peut déployer une application ne peut donner à personne le droit de la supprimer.
  • Retirer un accès. Vous ne pouvez retirer qu'un accès qui ne donne pas plus que ce que vous détenez. Un accès accordé par quelqu'un disposant de plus de droits reste en place jusqu'à ce qu'une personne disposant d'autant de droits le retire.

Gérer les groupes exige aussi la permission iam:manage, que détiennent les propriétaires et les administrateurs et qu'ajoute iam-administrators. Ainsi, un administrateur IAM qui peut gérer les membres mais pas la facturation ne peut pas créer un groupe « Facturation » et s'y ajouter.

Identifiants de la CLI

Un identifiant créé avec isogrid login agit en votre nom, dans une seule organisation, et il est limité de trois façons :

Il ne détient jamais plus que vous. Ses portées sont un plafond, vérifié par rapport à votre rôle et à vos groupes à chaque requête plutôt que copié au moment de sa création. Retirez quelqu'un d'un groupe, ou rétrogradez-le, et chaque identifiant qu'il a créé est réduit au même instant.

Il ne détient que ce qui est resté coché sur la page d'approbation. member:manage, iam:manage, organization:manage et network:share sont proposées mais pas cochées par défaut, car leurs effets touchent d'autres personnes.

Certaines choses lui sont toujours interdites, quoi qu'il demande et qui que ce soit qui l'approuve : consulter ou modifier la facturation, nommer des administrateurs, modifier les informations légales de l'organisation, ou créer et révoquer des identifiants. Cela exige une personne devant un clavier.

Les portées restreignent les permissions d'organisation. L'accès qui provient d'un accès accordé sur une ressource, ou du fait de l'avoir créée, n'est pas concerné : un identifiant restreint atteint donc toujours ce à quoi vous avez été invité. isogrid whoami affiche ce qu'un identifiant sera réellement autorisé à faire ; c'est la liste à lire quand quelque chose est refusé. Voir Déployer depuis la CI/CD pour en créer un destiné à un pipeline.

Exemples

Laisser l'équipe QA déployer, mais pas supprimer

Créez un groupe qa et placez-y les testeurs. Ce qu'il faut lui donner dépend de l'étendue de leur travail :

  • Toutes les applications : faites hériter qa de deployers. Ils peuvent créer des applications et déployer, démarrer et arrêter toutes les applications, sans pouvoir en modifier ni en supprimer aucune.
  • Seulement les applications de préproduction : laissez le groupe sans permissions, et accordez-lui le préréglage operator sur chaque application de préproduction. Ils peuvent y déployer, démarrer, arrêter et lire les journaux, et ne voient rien d'autre.
isogrid iam groups create --name QA --inherits deployers
isogrid iam groups add-member qa tester@acme.example

Quand quelqu'un rejoint l'équipe QA, l'ajouter au groupe suffit à l'intégrer. Quand il la quitte, il perd d'un coup tout ce que le groupe lui donnait.

Confier une solution à une agence marketing

Le contact de l'agence doit gérer la boutique, et rien d'autre.

  1. Invitez-le dans l'organisation en tant que développeur. Par lui-même, il ne voit rien qu'il n'ait créé.
  2. Sur la solution de la boutique, accordez-lui le préréglage solution-operator : il peut la voir, lire ses informations de connexion et ses identifiants d'administration, la démarrer, l'arrêter et la redéployer. Choisissez solution-manager s'il doit aussi modifier ses paramètres ; aucun des deux préréglages ne lui permet de la supprimer.
  3. À la fin de la mission, retirez l'accès ou retirez-le de l'organisation.

Il ne voit jamais vos applications, vos bases de données ni votre facture, et ne peut pas confier la boutique à quelqu'un d'autre, car aucun des deux préréglages n'inclut sol:share.

Donner un seul dépôt à un prestataire

Voir Dépôts Git : le membre qui a connecté le dépôt accorde au prestataire repo-deployer sur celui-ci, et le prestataire peut construire et déployer les applications qui en sont issues sans qu'on doive lui donner chacune d'elles.

Cas particuliers à connaître avant d'y être confronté

Un membre ne trouve pas une application qui existe. Ne rien détenir sur une ressource revient au même que si elle n'existait pas : les membres ne peuvent donc pas découvrir ce que font tourner leurs collègues en devinant des noms. Accordez-leur l'accès, ou placez-les dans un groupe qui voit toutes les applications.

« You do not have 'app:deploy' on this application » pour quelqu'un qui peut la voir. Il détient quelque chose, donc la ressource n'est pas masquée, mais pas cette capacité. L'erreur liste ce qu'il détient.

Un administrateur ne peut pas construire depuis le dépôt privé d'un collègue. Les dépôts suivent leurs propres règles : c'est le membre qui a connecté le compte qui décide, et un dépôt privé est fermé même au propriétaire. Voir Dépôts Git.

Un groupe intégré ne peut pas être modifié. Construisez le vôtre par-dessus avec --inherits.

Une commande de la CLI est refusée alors qu'elle fonctionne dans la console. L'identifiant a été approuvé avec moins de permissions que vous n'en détenez. isogrid whoami indique lesquelles ; isogrid login --force en approuve un plus large.

Pour continuer