Dépôts, groupes et accès

Décider qui peut construire depuis un dépôt, gérer les groupes de permissions et savoir qui détient quoi, depuis le terminal.

Deux groupes de commandes couvrent l'accès. isogrid repos décide qui, dans l'organisation, peut utiliser un dépôt connecté. isogrid iam liste les membres et gère les groupes de permissions. Les deux font ce que font les pages d'accès de la console, et peuvent donc être scriptés : pour intégrer une équipe, ou pour vérifier lors d'une revue qui détient quoi.

Les principes sous-jacents sont expliqués dans Rôles, groupes de permissions et accès et Dépôts Git. Cette page présente les commandes.

Dépôts : isogrid repos

repos répond aussi à repo et repositories. Un dépôt se désigne par son nom complet (acme/api, ou platform/backend/api pour un projet GitLab dans des groupes imbriqués), par une URL collée depuis le navigateur, ou par son identifiant.

Les lister

isogrid repos list [--provider github|gitlab] [--search TEXT] [--json]

REPOSITORY         PROVIDER  ACCESS                   OWNER               YOU
acme/api           github    organization             samir@acme.example  view,create-app,deploy,update,delete,share
acme/website       github    private (default)        aziz@acme.example   view,create-app,deploy
platform/billing   gitlab    administrators           lina@acme.example   view

• ACCESS indique qui peut accéder au dépôt : private, administrators ou organization. (default) signifie que le dépôt n'a pas de réglage propre et suit la valeur par défaut de sa connexion.
• OWNER est le membre par le compte GitHub ou GitLab duquel le dépôt arrive. C'est lui qui décide qui d'autre peut l'utiliser.
• YOU est ce que vous pouvez faire avec, sans le préfixe repo:.

Seuls les dépôts que vous pouvez voir sont listés. Le dépôt privé d'un collègue n'apparaît pas et ne répond pas non plus à son nom, sauf s'il vous l'accorde.

Définir qui peut y accéder

isogrid repos access <repo> [--visibility private|administrators|organization|inherit]
                            [--org-capabilities CAP,...]

--org-capabilities est ce que chaque membre détient sous organization. Sans cette option, les membres peuvent voir le dépôt, créer des applications à partir de lui, les déployer et modifier leur configuration, mais pas supprimer les applications des autres ni partager le dépôt plus loin.

Seul le propriétaire peut modifier ce réglage, ou un administrateur une fois que le propriétaire a quitté l'organisation.

# Open the API to everyone, but only to deploy what exists
isogrid repos access acme/api --visibility organization \
  --org-capabilities repo:view,repo:deploy

# Close it again
isogrid repos access acme/api --visibility private

L'accorder à un membre ou à un groupe

isogrid repos grant <repo> (--member EMAIL | --group SLUG) [--preset NAME] [--capabilities CAP,...]

Indiquez un préréglage, une liste de capacités, ou les deux ; c'est l'union qui est accordée.

Aucun préréglage n'inclut repo:share : décider qui d'autre peut entrer reste l'affaire de la personne qui a connecté le compte. Vous ne pouvez accorder que des capacités que vous détenez vous-même.

# A contractor who may deploy the applications built from the API
isogrid repos grant acme/api --member contractor@partner.example --preset repo-deployer

# The QA group may see the code and redeploy, but not create applications
isogrid repos grant acme/api --group qa --capabilities repo:view,repo:deploy

Un accès accordé couvre toutes les applications construites à partir du dépôt, y compris celles créées après.

Voir et retirer les accès accordés

isogrid repos grants <repo> [--json]
isogrid repos revoke <repo> <grant-id|email|group>

isogrid repos grants acme/api
# ID        SUBJECT  WHO                          CAPABILITIES              GRANTED
# 9c1e4a2b  user     contractor@partner.example   view,create-app,deploy    3 days ago
# 51aa07fe  group    qa                           view,deploy               1 hour ago

isogrid repos revoke acme/api contractor@partner.example
isogrid repos revoke acme/api 51aa

Un accès se désigne par le début de son identifiant (quatre caractères ou plus), ou par l'adresse e-mail ou le groupe à qui il a été accordé. Vous ne pouvez retirer qu'un accès qui ne donne pas plus que ce que vous détenez vous-même.

Membres et groupes : isogrid iam

Membres

isogrid iam members [--search TEXT] [--role owner|administrator|developer]
                    [--status active|suspended] [--group SLUG] [--limit N] [--page N] [--json]

isogrid iam members --role administrator
isogrid iam members --group deployers
isogrid iam members --search @partner.example --status active

Les résultats sont paginés, 50 par page par défaut et 200 au maximum. Inviter des membres et changer leur rôle se fait dans la console.

Groupes

isogrid iam groups list
isogrid iam groups get <group>
isogrid iam groups create --name NAME [--slug SLUG] [--description TEXT] [--permissions P,...] [--inherits GROUP,...]
isogrid iam groups update <group> [--name NAME] [--description TEXT] [--permissions P,...] [--inherits GROUP,...]
isogrid iam groups delete <group> [--yes]
isogrid iam groups add-member <group> <email>
isogrid iam groups remove-member <group> <email>

groups répond aussi à group.

get affiche les permissions propres d'un groupe, celles dont il hérite et ses membres. C'est la commande à lancer pour savoir ce que rejoindre un groupe donnerait réellement à quelqu'un.

create prend des permissions d'organisation et les slugs des groupes dont hériter. Les membres du nouveau groupe détiennent ses permissions propres et tout ce que détiennent ses parents, de manière transitive.

update ne modifie que ce que vous indiquez, mais --permissions et --inherits remplacent la liste entière. --inherits "" la vide.

Les groupes intégrés ne peuvent être ni modifiés ni supprimés. Pour en ajuster un, créez votre propre groupe qui en hérite et ajoute ce dont vous avez besoin.

delete demande confirmation, et exige --yes sans terminal. Les membres restent dans l'organisation mais perdent ce que le groupe leur donnait, et les accès accordés au groupe sont supprimés avec lui.

Modifier des groupes exige la permission iam:manage, et chaque modification est vérifiée par rapport à ce que vous détenez : vous ne pouvez pas créer un groupe avec une permission que vous n'avez pas, faire hériter un groupe d'un autre qui détient plus que vous, ni ajouter quelqu'un à un tel groupe.

# Release managers: deploy anything, and read billing
isogrid iam groups create --name "Release managers" \
  --inherits deployers --permissions billing:read

isogrid iam groups add-member release-managers lina@acme.example
isogrid iam groups get release-managers

Ce qui peut être accordé

isogrid iam permissions [--json]

Affiche chaque permission d'organisation, en signalant celles que seul le propriétaire peut détenir ; puis, pour chaque type de ressource, ses capacités et les préréglages qui les regroupent. C'est la référence des valeurs acceptées par --permissions, --capabilities et --org-capabilities, et elle correspond toujours à la plateforme à laquelle vous êtes connecté.

Scripter les accès

Chaque listing accepte --json, qui affiche la réponse de l'API sur la sortie standard. Les messages vont sur la sortie d'erreur.

Une revue périodique de qui peut construire depuis quel dépôt :

for repo in $(isogrid repos list --json | jq -r '.[].full_name'); do
  echo "== $repo"
  isogrid repos grants "$repo"
done

Intégrer une équipe à partir d'un fichier d'adresses e-mail :

while read -r email; do
  isogrid iam groups add-member deployers "$email"
done < new-team.txt

Identifiants délégués et commandes d'accès

Un identifiant de la CLI ne porte iam:manage et member:manage que si vous les avez cochées lors de son approbation ; elles sont désactivées par défaut. Sans iam:manage, les commandes iam groups qui modifient quelque chose sont refusées, tandis que les listings fonctionnent toujours.

Accorder et retirer un accès sur un dépôt ne dépend pas de iam:manage : cela dépend de la détention de repo:share sur ce dépôt, ce qui est toujours le cas de son propriétaire.

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

« is not a repository you have been given access to ». Ne rien détenir sur un dépôt revient au même que s'il n'existait pas : un dépôt privé ne peut donc pas être découvert en devinant son nom. Demandez l'accès à son propriétaire.

« You cannot grant capabilities you do not hold yourself ». Vous avez tenté de donner plus que ce que vous avez. L'erreur liste ce qui manque.

« These permissions belong to the owner alone ». Nommer des administrateurs et modifier les informations légales de l'organisation ne peuvent être placés dans un groupe, par personne.

« A group cannot inherit from itself, even indirectly ». L'héritage demandé formerait une boucle.

repos access est refusé sur un dépôt que vous administrez. Les administrateurs accèdent aux dépôts qui leur sont ouverts, mais le choix de qui d'autre peut entrer reste à la personne qui a connecté le compte, tant qu'elle est membre.