Ce guide explique aux utilisateurs de Cloud Source Repositories (CSR) comment ses contrôles d'accès se traduisent dans Secure Source Manager (SSM). Pour suivre ce guide, vous devez connaître IAM et les CSR, et avoir une compréhension de base de SSM.
Modèles de ressources
CSR dispose d'une ressource Google Cloud qui est un enfant d'un projet :
- Un dépôt,
projects/<var>project</var>/repositories/<var>repo</var>
SSM comporte deux ressources régionales enfants d'un projet :
- Une instance,
projects/<var>project</var>/locations/<var>location</var>/instances/<var>instance</var> - Un dépôt, qui est l'équivalent le plus direct d'un dépôt CSR et qui doit être associé à une instance SSM (mais n'en est pas un enfant) dans le même projet et le même emplacement,
projects/<var>project</var>/locations/<var>location</var>/repositories/<var>repo</var>
SSM dispose d'autres ressources, mais elles sont modélisées en tant qu'enfants du dépôt. Ce guide les considère comme faisant partie du dépôt.
Rôles
Le CSR comporte trois rôles : roles/source.reader, roles/source.writer et roles/source.admin. Vous pouvez associer les rôles de lecteur et d'auteur à un dépôt ou à un projet. Vous ne devez associer le rôle Administrateur qu'à un projet, car l'autorisation source.repos.create ne s'applique qu'au niveau du projet.
SSM dispose de 11 rôles pour les comptes principaux utilisateur, ce qui représente une augmentation significative par rapport à Cloud Source Repositories. Vous pouvez regrouper ces rôles dans deux catégories (plus un rôle de super-administrateur).
Le rôle Super-utilisateur (roles/securesourcemanager.admin) accorde toutes les autorisations SSM. Vous devez associer ce rôle à un projet, car les autorisations d'instance ne s'appliquent pas si vous les associez à un dépôt, et les autorisations de dépôt ne s'appliquent pas si vous les associez à une instance.
Rôles d'instance SSM
Les rôles d'instance accordent des autorisations permettant d'accéder à l'interface utilisateur d'une instance Secure Source Manager et de s'y connecter à l'aide de Git. Vous devez attribuer aux utilisateurs au moins un rôle d'instance pour leur permettre d'accéder aux dépôts de l'instance. Vous pouvez associer ces rôles à une ressource d'instance ou à un projet.
| Rôle | Autorisations |
|---|---|
roles/securesourcemanager.instanceAccessor |
Accédez à une instance et à ses dépôts. Obligatoire pour que les rôles au niveau du dépôt soient effectifs. |
roles/securesourcemanager.instanceManager |
Gérez les configurations au niveau de l'instance. |
roles/securesourcemanager.instanceOwner |
Contrôle total des configurations d'instance. |
roles/securesourcemanager.instanceRepoCreator |
Créez des dépôts sur une instance. |
roles/securesourcemanager.sshKeyUser |
Gérez les clés SSH pour l'authentification à une instance. N'accorde pas l'accès à l'instance en soi. |
Rôles du dépôt SSM
Les rôles de dépôt accordent des autorisations sur les dépôts d'une instance Secure Source Manager. Vous pouvez associer ces rôles à une ressource de dépôt ou à un projet, à l'exception de repoCreator, que vous devez associer à un projet.
| Rôle | Autorisations |
|---|---|
roles/securesourcemanager.repoAdmin |
Contrôle total sur un dépôt, y compris sur les paramètres du dépôt et l'accès des utilisateurs. |
roles/securesourcemanager.repoPullRequestApprover |
Approuver les requêtes d'extraction dans un dépôt |
roles/securesourcemanager.repoReader |
Lire le contenu du dépôt et afficher les demandes d'extraction et les problèmes. |
roles/securesourcemanager.repoWriter |
Lire et écrire le contenu du dépôt, et gérer les demandes d'extraction et les problèmes. |
roles/securesourcemanager.repoCreator |
Créer des dépôts dans un projet |
Mapper les rôles CSR sur SSM
Pour utiliser efficacement SSM, vous avez besoin d'au moins deux rôles : un rôle d'instance et un rôle de dépôt. Il n'existe pas de mappage parfait entre un rôle CSR et un rôle SSM. Ces recettes ne fournissent un accès équivalent que pour le contrôle du code source, et non pour les fonctionnalités SSM telles que les requêtes d'extraction, les problèmes ou la gestion des instances.
Dans CSR, vous pouvez créer des dépôts dans plusieurs projets. Dans Secure Source Manager, tous les dépôts d'une instance appartiennent au même projet que l'instance. Si vous associez un rôle au niveau du projet dans Secure Source Manager, vous accordez les autorisations de ce rôle à tous les dépôts de cette instance. Si vous devez accorder des autorisations à des dépôts spécifiques uniquement, utilisez des liaisons au niveau du dépôt.
Mappage de source.reader
Si vous avez lié ce rôle au niveau du dépôt, liez securesourcemanager.repoReader à la ressource de dépôt et securesourcemanager.instanceAccessor à l'instance hôte pour recréer le même niveau d'accès. Si vous avez lié le rôle au niveau du projet, la liaison repoReader et instanceAccessor au niveau du projet accorde un accès en lecture à tous les dépôts de l'instance.
Mappage de source.writer
Si vous avez lié ce rôle au niveau du dépôt, liez securesourcemanager.repoWriter à la ressource de dépôt et securesourcemanager.instanceAccessor à l'instance hôte pour recréer le même niveau d'accès. Si vous avez associé le rôle au niveau du projet, l'association de repoWriter et instanceAccessor au niveau du projet accorde un accès en écriture à tous les dépôts de l'instance.
Mappage de source.admin
Vous n'associez ce rôle qu'au niveau du projet. Vous pouvez le recréer en associant une combinaison de securesourcemanager.instanceAccessor, securesourcemanager.repoAdmin, securesourcemanager.instanceRepoCreator et securesourcemanager.repoCreator au niveau du projet. Cette combinaison de rôles autorise la création de dépôts sur n'importe quelle instance du projet et accorde aux administrateurs des autorisations pour tous les dépôts sur n'importe quelle instance du projet. Pour accorder toutes les autorisations SSM de la même manière que source.admin accordait toutes les autorisations CSR, associez le rôle de super-utilisateur, securesourcemanager.admin, au niveau du projet.
Différences entre SSM et CSR
Cette section décrit les principaux changements apportés à la gestion des rôles et des autorisations dans Secure Source Manager par rapport à Cloud Source Repositories.
Attribution de rôle implicite
Lorsque vous créez une ressource de dépôt, le compte principal appelant reçoit automatiquement le rôle repoAdmin sur la ressource de dépôt nouvellement créée.
Nouveaux types de ressources
SSM offre plus de fonctionnalités que CSR. Ces fonctionnalités sont modélisées en tant que nouveaux types de ressources.
Ces fonctionnalités incluent les règles de protection des branches, les hooks, les problèmes et les demandes d'extraction, en plus des commentaires sur les problèmes et les demandes d'extraction. Ces ressources sont des enfants de la ressource de dépôt. Les rôles de dépôt incluent des autorisations pour ces ressources.
Par exemple, repoAdmin et repoWriter fournissent un accès en écriture, tandis que repoReader n'accorde qu'un accès en lecture.
Rôles précis
SSM inclut des rôles précis qui fournissent des contrôles d'accès spécifiques.
roles/securesourcemanager.repoPullRequestApprovern'accorde que l'autorisation d'approuver les demandes d'extraction. Utilisez ce rôle avecrepoReaderetinstanceAccessorpour permettre à un utilisateur d'accéder à une instance, de parcourir le dépôt et d'approuver les demandes d'extraction sans modifier d'autres données.roles/securesourcemanager.repoCreatorn'accorde que l'autorisation de créer des dépôts dans un projet. Étant donné que les dépôts doivent être associés à une instance, vous devez également disposer deroles/securesourcemanager.instanceRepoCreatorpour associer un dépôt à une instance. Utilisezroles/securesourcemanager.repoCreatoravecinstanceRepoCreatorpour accorder les autorisations permettant de créer des dépôts et de les associer à une instance.