In dieser Anleitung erfahren Nutzer von Cloud Source Repositories (CSR), wie sich die Zugriffssteuerung in Secure Source Manager (SSM) umsetzen lässt. Für diesen Leitfaden sollten Sie sich mit IAM und CSR auskennen und grundlegende Kenntnisse von SSM haben.
Ressourcenmodelle
CSR hat eine Google Cloud Ressource, die einem Projekt untergeordnet ist:
- Ein Repository,
projects/<var>project</var>/repositories/<var>repo</var>
SSM hat zwei Ressourcen, die regionale untergeordnete Elemente eines Projekts sind:
- Eine Instanz,
projects/<var>project</var>/locations/<var>location</var>/instances/<var>instance</var> - Ein Repository, das dem CSR-Repository am ehesten entspricht und an eine SSM-Instanz im selben Projekt und am selben Standort angehängt werden muss (aber nicht untergeordnet ist),
projects/<var>project</var>/locations/<var>location</var>/repositories/<var>repo</var>
SSM hat andere Ressourcen, die jedoch als untergeordnete Elemente des Repositorys modelliert werden. In diesem Leitfaden werden sie als Teil des Repository betrachtet.
Rollen
CSR hat drei Rollen: roles/source.reader, roles/source.writer und roles/source.admin. Sie können die Rollen „Leser“ und „Autor“ an ein Repository oder Projekt binden. Sie sollten die Administratorrolle nur an ein Projekt binden, da die Berechtigung source.repos.create nur auf Projektebene gilt.
SSM hat 11 Rollen für Nutzer-Principals, was eine deutliche Steigerung im Vergleich zu Cloud Source Repositories darstellt. Sie können diese Rollen in zwei Kategorien einteilen (plus eine Superuser-Rolle).
Die Rolle „Superuser“ (roles/securesourcemanager.admin) gewährt alle SSM-Berechtigungen. Sie müssen diese Rolle an ein Projekt binden, da Instanzberechtigungen nicht gelten, wenn Sie sie an ein Repository binden, und Repositoryberechtigungen nicht gelten, wenn Sie sie an eine Instanz binden.
SSM-Instanzrollen
Instanzrollen gewähren Berechtigungen für den Zugriff auf die Benutzeroberfläche einer Secure Source Manager-Instanz und für die Verbindung mit ihr über Git. Sie müssen Nutzern mindestens eine Instanzrolle zuweisen, damit sie auf Repositorys in der Instanz zugreifen können. Sie können diese Rollen an eine Instanzressource oder ein Projekt binden.
| Rolle | Berechtigungen |
|---|---|
roles/securesourcemanager.instanceAccessor |
Auf eine Instanz und ihre Repositories zugreifen. Erforderlich, damit Rollen auf Repository-Ebene wirksam werden. |
roles/securesourcemanager.instanceManager |
Konfigurationen auf Instanzebene verwalten |
roles/securesourcemanager.instanceOwner |
Vollständige Kontrolle über Instanzkonfigurationen. |
roles/securesourcemanager.instanceRepoCreator |
Repositories in einer Instanz erstellen |
roles/securesourcemanager.sshKeyUser |
SSH-Schlüssel für die Authentifizierung bei einer Instanz verwalten Gewährt nicht automatisch Zugriff auf die Instanz. |
SSM-Repository-Rollen
Mit Repository-Rollen werden Berechtigungen für Repositories in einer Secure Source Manager-Instanz gewährt. Sie können diese Rollen an eine Repository-Ressource oder ein Projekt binden, mit Ausnahme von repoCreator, die Sie an ein Projekt binden müssen.
| Rolle | Berechtigungen |
|---|---|
roles/securesourcemanager.repoAdmin |
Vollständige Kontrolle über ein Repository, einschließlich Repository-Einstellungen und Nutzerzugriff. |
roles/securesourcemanager.repoPullRequestApprover |
Pull-Anfragen in einem Repository genehmigen |
roles/securesourcemanager.repoReader |
Repository-Inhalte lesen und Pull-Anfragen und Probleme ansehen. |
roles/securesourcemanager.repoWriter |
Repository-Inhalte lesen und schreiben sowie Pull-Anfragen und Probleme verwalten. |
roles/securesourcemanager.repoCreator |
Neue Repositories in einem Projekt erstellen |
CSR-Rollen SSM zuordnen
Damit Sie SSM effektiv nutzen können, benötigen Sie mindestens zwei Rollen: eine Instanzrolle und eine Repository-Rolle. Es gibt keine 1:1-Zuordnung von einer CSR-Rolle zu einer SSM-Rolle. Diese Rezepte bieten nur für die Quellcodeverwaltung einen gleichwertigen Zugriff, nicht für SSM-Funktionen wie Pull-Anfragen, Probleme oder Instanzverwaltung.
In CSR konnten Sie Repositories in mehreren Projekten erstellen. In Secure Source Manager gehören alle Repositories in einer Instanz zum selben Projekt wie die Instanz. Wenn Sie eine Rolle auf Projektebene in Secure Source Manager binden, gewähren Sie die Berechtigungen dieser Rolle für jedes Repository in dieser Instanz. Wenn Sie nur bestimmten Repositories Berechtigungen erteilen müssen, verwenden Sie Bindungen auf Repository-Ebene.
Source.Reader zuordnen
Wenn Sie diese Rolle auf Repository-Ebene gebunden haben, binden Sie securesourcemanager.repoReader an die Repository-Ressource und securesourcemanager.instanceAccessor an die Hostinstanz, um dasselbe Zugriffsniveau zu erreichen. Wenn Sie die Rolle auf Projektebene binden, gewährt das Binden von repoReader und instanceAccessor auf Projektebene Lesezugriff auf alle Repositories in der Instanz.
source.writer zuordnen
Wenn Sie diese Rolle auf Repository-Ebene gebunden haben, binden Sie securesourcemanager.repoWriter an die Repository-Ressource und securesourcemanager.instanceAccessor an die Hostinstanz, um dasselbe Zugriffsniveau zu erreichen. Wenn Sie die Rolle auf Projektebene binden, gewährt das Binden von repoWriter und instanceAccessor auf Projektebene Schreibzugriff auf alle Repositories in der Instanz.
source.admin zuordnen
Sie binden diese Rolle nur auf Projektebene. Sie können sie neu erstellen, indem Sie eine Kombination aus securesourcemanager.instanceAccessor, securesourcemanager.repoAdmin, securesourcemanager.instanceRepoCreator und securesourcemanager.repoCreator auf Projektebene binden. Diese Kombination von Rollen gewährt die Berechtigung, Repositories auf einer beliebigen Instanz im Projekt zu erstellen, und Administratoren Berechtigungen für alle Repositories auf einer beliebigen Instanz im Projekt. Wenn Sie alle SSM-Berechtigungen auf dieselbe Weise wie alle CSR-Berechtigungen mit source.admin gewähren möchten, binden Sie die Superuser-Rolle securesourcemanager.admin auf Projektebene.
Unterschiede zwischen SSM und CSR
In diesem Abschnitt werden die wichtigsten Änderungen im Umgang mit Rollen und Berechtigungen in Secure Source Manager im Vergleich zu Cloud Source Repositories beschrieben.
Implizite Rollenzuweisung
Wenn Sie eine neue Repository-Ressource erstellen, wird dem aufrufenden Hauptkonto automatisch die Rolle repoAdmin für die neu erstellte Repository-Ressource zugewiesen.
Neue Ressourcentypen
SSM bietet mehr Funktionen als CSR. Diese Funktionen werden als neue Ressourcentypen modelliert.
Dazu gehören neben Kommentaren zu Issues und Pull Requests auch Regeln zum Schutz von Branches, Hooks, Issues und Pull Requests. Diese Ressourcen sind untergeordnete Elemente der Repository-Ressource. Repository-Rollen enthalten Berechtigungen für diese Ressourcen.
Beispiel: repoAdmin und repoWriter bieten Schreibzugriff, während repoReader nur Lesezugriff gewährt.
Detaillierte Rollen
SSM umfasst detaillierte Rollen, die spezifische Zugriffssteuerungen ermöglichen.
roles/securesourcemanager.repoPullRequestApprovergewährt nur die Berechtigung zum Genehmigen von Pull-Anfragen. Verwenden Sie diese Rolle zusammen mitrepoReaderundinstanceAccessor, damit ein Nutzer auf eine Instanz zugreifen, das Repository durchsuchen und Pull-Anfragen genehmigen kann, ohne andere Daten zu ändern.- Mit
roles/securesourcemanager.repoCreatorwird nur die Berechtigung zum Erstellen von Repositories in einem Projekt gewährt. Da Repositories an eine Instanz angehängt werden müssen, benötigen Sie auchroles/securesourcemanager.instanceRepoCreator, um ein Repository an eine Instanz anzuhängen. Verwenden Sieroles/securesourcemanager.repoCreatormitinstanceRepoCreator, um Berechtigungen zum Erstellen von Repositories zu erteilen und sie an eine Instanz anzuhängen.