Auf dieser Seite wird die Zugriffssteuerung mit Identity and Access Management (IAM) in Artifact Registry.
Die Standardberechtigungen für Artifact Registry minimieren den Einrichtungsaufwand bei der Implementierung einer CI/CD-Pipeline. Sie können auch Artifact Registry mit CI/CD-Tools von Drittanbietern und konfigurieren Sie die Berechtigungen und die Authentifizierung die für den Zugriff auf Repositories erforderlich sind.
Wenn Sie die Artefaktanalyse für die Arbeit mit Containermetadaten verwenden, z. B. gefundene Sicherheitslücken-Images, lesen Sie die Artefaktanalyse-Dokumentation für Informationen dazu, wie Sie Zugriff zum Aufrufen oder Verwalten von Metadaten gewähren können.
Hinweise
- Artifact Registry aktivieren die API aktivieren und die Google Cloud CLI installieren.
- Wenn Sie Repository-spezifische Berechtigungen anwenden möchten, gilt: Artifact Registry-Repository erstellen für Ihre Pakete.
Übersicht
IAM-Berechtigungen und Rollen bestimmen, ob Sie in der Lage sind, Daten in einem Artifact Registry-Repository bearbeiten oder löschen.
Eine Rolle ist eine Sammlung von Berechtigungen. Sie können einem Hauptkonto Berechtigungen nicht direkt erteilen. Stattdessen weisen Sie ihm eine Rolle zu. Wenn Sie einem Hauptkonto eine Rolle zuweisen, erhält er alle mit ihr verknüpften Berechtigungen. Einem Hauptkonto können mehrere Rollen zugewiesen werden.
Standardberechtigungen für Google Cloud
Standardmäßig gelten die folgenden Berechtigungen für Google Cloud CI/CD-Dienste im selben Projekt wie Artifact Registry:
- Cloud Build-Berechtigungen umfassen Berechtigungen zum Hochladen und Herunterladen von Artefakten.
- Compute Engine, unterstützte Google Kubernetes Engine-Versionen und Cloud Run verwenden das Standarddienstkonto von Compute Engine mit Lesezugriff.
Wenn sich alle Dienste im selben Google Cloud-Projekt befinden und das Standard- Berechtigungen Ihren Anforderungen entsprechen, müssen Sie keine Berechtigungen konfigurieren.
Sie müssen Artifact Registry-Berechtigungen für diese Dienste konfigurieren, wenn:
- Sie mit diesen Diensten auf Artifact Registry in einem anderen Projekt zugreifen möchten. Weisen Sie im Projekt mit Artifact Registry dem Workload Identity-Pool oder dem Dienstkonto für jeden Dienst die erforderliche Rolle zu. Wenn Sie eine Verbindung zu Cloud Run herstellen, gewähren Sie den Cloud Run-Dienst-Agent die erforderliche Rolle.
- Sie verwenden eine GKE-Version, die keine integrierte Unterstützung für den Abruf von Images aus Artifact Registry bietet. Konfigurationsanweisungen finden Sie im Abschnitt GKE.
- Sie möchten, dass das Standarddienstkonto Lese- und Schreibzugriff auf Repositories hat. Weitere Informationen finden Sie hier:
- Sie verwenden für Ihre Laufzeitumgebungen ein von Nutzern bereitgestelltes Dienstkonto anstelle des Standarddienstkontos. Weisen Sie Ihrem Dienstkonto im Projekt mit Artifact Registry die erforderliche Rolle zu.
Integration von Drittanbietern
Für Drittanbieter-Clients müssen Sie sowohl Berechtigungen als auch Authentifizierung konfigurieren.
Traditionell nutzen Anwendungen, die außerhalb von Google Cloud ausgeführt werden, Dienstkontoschlüssel um auf Google Cloud-Ressourcen zuzugreifen. Dienstkontoschlüssel sind jedoch leistungsstarke Anmeldedaten und können ein Sicherheitsrisiko darstellen, wenn sie nicht ordnungsgemäß verwaltet werden.
Mit der Workload Identity-Föderation können Sie externen Identitäten mithilfe der Identitäts- und Zugriffsverwaltung (IAM) IAM-Rollen zuweisen. Somit bietet sich auch die Möglichkeit, die Identität von Dienstkonten zu übernehmen. Bei diesem Ansatz entfallen die mit Dienstkontoschlüsseln verbundenen Wartungs- und Sicherheitsaufwand.
Workload Identity-Föderation verwenden:
- Erstellen Sie einen Workload Identity-Föderationspool.
- Anbieter der Identitätsföderation von Arbeitslasten erstellen
- Gewähren Sie dem Workload Identity-Pool die entsprechende Artifact Registry-Rolle, um den Zugriff auf das Repository zu ermöglichen.
Drittanbieter-Client für die Authentifizierung konfigurieren Artifact Registry.
Dienstkonto verwenden:
- Erstellen Sie ein Dienstkonto, das für Ihre Anwendung agiert, oder wählen Sie ein vorhandenes Dienstkonto für die CI-/CD-Automatisierung aus.
- Gewähren Sie dem Dienstkonto die entsprechende Artifact Registry-Rolle, um den Zugriff auf das Repository zu ermöglichen.
Konfigurieren Sie den Client eines Drittanbieters für die Authentifizierung bei Artifact Registry.
GitLab on Google Cloud
Die Integration von GitLab in Google Cloud Workload Identity-Föderation zur Autorisierung und Authentifizierung für GitLab-Arbeitslasten in Google Cloud ohne Dienstkonten oder Dienstkontoschlüssel. Weitere Informationen zur Verwendung der Identitätsföderation von Arbeitslasten in dieser Partnerschaft finden Sie unter Authentifizierung.
Informationen zum Einrichten der Workload Identity-Föderation und der erforderlichen IAM-Rollen für GitLab in Google Cloud finden Sie im GitLab-Tutorial Google Cloud Workload Identity Federation and IAM policies (Google Cloud-Richtlinien für die Workload Identity-Föderation und IAM).
Folgen Sie der GitLab-Anleitung für die Google Artifact Registry, um eine Verbindung zu Ihrem Artifact Registry-Repository herzustellen.
Rollen und Berechtigungen
Für jede Artifact Registry API-Methode ist es erforderlich, dass das Hauptkonto (Nutzer, Gruppe oder Dienstkonto), das die Anfrage sendet, die erforderlichen Berechtigungen zur Verwendung der Ressource hat. Berechtigungen werden Hauptkonten erteilt, indem Richtlinien festgelegt werden, die Gewähren Sie dem Hauptkonto eine vordefinierte Rolle für die Ressource.
Sie können Rollen für das Google Cloud-Projekt oder das Artifact Registry-Repository zuweisen.
Vordefinierte Artifact Registry-Rollen
IAM bietet vordefinierte Rollen für den Zugriff auf bestimmte Google Cloud-Ressourcen. Mit diesen Rollen wird der unbefugte Zugriff auf andere Ressourcen verhindert.
Verwenden Sie die folgenden vordefinierten Rollen für die Rollen „Standard“, „Virtual“ und „Remote“
Repositories in der Domain pkg.dev
:
Rolle | Beschreibung |
---|---|
Artifact Registry-Leser ( roles/artifactregistry.reader ) |
Artefakte ansehen und abrufen, Repository-Metadaten ansehen. |
Artifact Registry-Autor ( roles/artifactregistry.writer ) |
Artefakte lesen und schreiben |
Artifact Registry-Repository-Administrator ( roles/artifactregistry.repoAdmin ) |
Artefakte lesen, schreiben und löschen. |
Artifact Registry-Administrator ( roles/artifactregistry.admin ) |
Repositories und Artefakte erstellen und verwalten |
Die folgenden zusätzlichen vordefinierten Rollen enthalten Berechtigungen zum Erstellen von gcr.io-Repositories zum Hosten von Bildern für die gcr.io
-Domain. Die Rollen enthalten keine Berechtigungen zum Erstellen anderer Repository-Formate in der Artifact Registry in der Domain pkg.dev
. Diese Rollen unterstützen rückwärts
Kompatibilität mit Container Registry, da Container Registry die erste
ein Container-Image hochladen, um jede multiregionale Registry zu erstellen.
Rolle | Beschreibung |
---|---|
Artifact Registry Create-on-push Writer (roles/artifactregistry.createOnPushWriter ) |
Artefakte lesen und schreiben Erstellen Sie gcr.io-Repositories. |
Artifact Registry-Repository-Administrator für Erstellung und Push-Funktion
(roles/artifactregistry.createOnPushRepoAdmin ) |
Artefakte lesen, schreiben und löschen. gcr.io-Repositories erstellen |
Eine vollständige Liste der einzelnen Berechtigungen der einzelnen Rollen finden Sie unter
Artifact Registry-Rollen.
Sie können auch die
gcloud iam roles describe
um eine Liste der Berechtigungen für jede Rolle aufzurufen.
Einfache IAM-Rollen
Einfache Rollen sind Rollen mit sehr weitreichenden Berechtigungen, die es schon vor der Einführung von IAM gab. Mithilfe einfacher Rollen können Sie Berechtigten umfassenden Zugriff auf Google Cloud-Ressourcen gewähren.
Verwenden Sie nach Möglichkeit vordefinierte Rollen für den Repositoryzugriff, damit Nutzer und Dienstkonten nur die erforderlichen Berechtigungen haben.
Weitere Informationen zu einfachen Rollen finden Sie unter Referenz zu einfachen und vordefinierten IAM-Rollen
Berechtigungen gewähren
Berechtigungen auf Projektebene gewähren, wenn für alle Repositories im Projekt dieselben Berechtigungen gelten. Wenn für einige Konten unterschiedliche Zugriffsebenen erforderlich sind, erteilen Sie Rollen auf Repository-Ebene.
Wenn Sie Berechtigungen für ein virtuelles Repository gewähren, gelten diese Berechtigungen unabhängig von den Berechtigungen für einzelne Repositories für alle Upstream-Repositories, die über das virtuelle Repository verfügbar sind.
Wenn Sie Rollen mit dem Befehl gcloud
zuweisen, können Sie einen einzelnen
Rollenbindung für ein Hauptkonto an oder verwenden Sie eine Richtliniendatei, um mehrere Bindungen zu definieren.
Projektweite Berechtigungen gewähren
Sie weisen eine Rolle auf Projektebene zu, wenn für alle Repositories im Projekt dieselben Berechtigungen gelten.
So fügen Sie einem Projekt ein Nutzer- oder Dienstkonto hinzu und weisen ihm eine Artifact Registry-Rolle zu:
Console
Öffnen Sie in der Google Cloud Console die Seite IAM.
Klicken Sie auf Projekt auswählen, wählen Sie das Projekt aus, in dem Artifact Registry ausgeführt wird, und klicken Sie auf Öffnen.
Klicken Sie auf Add.
Geben Sie eine E-Mail-Adresse ein. Sie können Einzelpersonen, Dienstkonten oder Google Groups als Hauptkonten hinzufügen.
Wählen Sie eine Rolle für das Hauptkonto aus. Gemäß den Sicherheitsstandards Prinzip der geringsten Berechtigung erwägen, das Prinzip der geringsten Berechtigung Berechtigung erforderlich, um auf die erforderlichen Artifact Registry-Ressourcen zuzugreifen. Informationen zur Vordefinierte Rollen und Berechtigungen von Artifact Registry, siehe Vordefinierte Artifact Registry-Rollen.
Klicken Sie auf Speichern.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Führen Sie den folgenden Befehl aus, um einem einzelnen Hauptkonto eine Rolle zuzuweisen:
gcloud projects add-iam-policy-binding PROJECT \ --member=PRINCIPAL \ --role=ROLE
Dabei gilt:
- PROJECT ist die ID des Projekts, in dem Artifact Registry ausgeführt wird.
PRINCIPAL ist das Mitglied, für das die Bindung eingefügt werden soll. Verwenden Sie das Format
user|group|serviceAccount:email
oderdomain:domain
.Beispiele:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
, oderdomain:example.domain.com
.ROLE ist die Rolle, die Sie erteilen möchten.
Weitere Informationen finden Sie in der Dokumentation zu add-iam-policy-binding.
Führen Sie den folgenden Befehl aus, um Rollen mithilfe einer Richtliniendatei zuzuweisen:
gcloud projects set-iam-policy PROJECT /PATH/TO/policy.yaml
Dabei gilt:
- PROJECT ist die ID des Projekts oder die voll qualifizierte Kennzeichnung für das Projekt, in dem Artifact Registry ausgeführt wird.
- /PATH/TO/policy.yaml ist der Pfad und der Dateiname der Richtliniendatei.
Führen Sie den folgenden Befehl aus, um die aktuell konfigurierte Richtlinie abzurufen:
gcloud projects get-iam-policy PROJECT
Dabei ist PROJECT die ID des Projekts oder die vollqualifizierte Kennzeichnung für das Projekt.
Weitere Informationen finden Sie in der set-iam-policy.
Repository-spezifische Berechtigungen erteilen
Berechtigungen auf Repository-Ebene gewähren Sie, wenn Sie Nutzern oder Dienstkonten für jedes Repository in Ihrem Projekt unterschiedliche Zugriffsrechte gewähren möchten.
Console
So gewähren Sie Zugriff auf ein bestimmtes Repository:
Öffnen Sie in der Cloud Console die Seite Repositories.
Wählen Sie das entsprechende Repository aus.
Wenn das Infofeld nicht angezeigt wird, klicken Sie in der Menüleiste auf Infofeld ansehen.
Klicken Sie auf dem Tab „Berechtigungen“ auf Hauptkonto hinzufügen.
Geben Sie eine E-Mail-Adresse ein. Sie können Einzelpersonen, Dienstkonten oder Google Gruppen als Hauptkonten.
Wählen Sie eine Rolle für das Hauptkonto aus. Gemäß den Sicherheitsstandards Prinzip der geringsten Berechtigung erwägen, das Prinzip der geringsten Berechtigung Berechtigung erforderlich, um auf die erforderlichen Artifact Registry-Ressourcen zuzugreifen. Für Informationen zu vordefinierten Rollen und Berechtigungen in Artifact Registry Siehe Vordefinierte Artifact Registry-Rollen.
Klicken Sie auf Speichern.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Sie können IAM-Sets einzelner Richtlinienbindungen festlegen oder eine Richtliniendatei verwenden.
Führen Sie den folgenden Befehl aus, um einem einzelnen Hauptkonto eine Rolle zuzuweisen:
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION \ --member=PRINCIPAL \ --role=ROLE
Dabei gilt:
- REPOSITORY ist die ID des Repositorys.
PRINCIPAL ist das Mitglied, für das die Bindung eingefügt werden soll. Verwenden Sie das Format
user|group|serviceAccount:email
oderdomain:domain
.Beispiele:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
, oderdomain:example.domain.com
.ROLE ist die Rolle, die Sie erteilen möchten.
LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
Wenn Sie beispielsweise eine IAM-Richtlinienbindung für die Rolle
roles/artifactregistry.writer
für den Nutzerwrite@gmail.com
mit dem Repositorymy-repo
am Standort--us-central1
hinzufügen möchten, führen Sie Folgendes aus:gcloud artifacts repositories add-iam-policy-binding my-repo \ --location=us-central1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
Führen Sie den folgenden Befehl aus, um Rollen mithilfe einer Richtliniendatei zuzuweisen:
gcloud artifacts repositories set-iam-policy REPOSITORY /PATH/TO/policy.yaml --location=LOCATION
Dabei gilt:
- REPOSITORY ist die ID des Repositorys.
- /PATH/TO/policy.yaml ist der Pfad und der Dateiname der Richtliniendatei.
- LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
Führen Sie folgenden Befehl aus, um beispielsweise die IAM-Richtlinie für das Repository
my-repo
am Standort--us-central1
mit der inpolicy.yaml
definierten Richtlinie festzulegen:gcloud artifacts repositories set-iam-policy my-repo policy.yaml --location=us-central1
Terraform
Verwenden Sie die Ressource google_artifact_registry_repository_iam, um eine IAM-Richtlinie zu konfigurieren. Im folgenden Beispiel wird ein Dienst definiert,
mit dem Ressourcennamen repo-account
und gewährt ihm Lesezugriff auf ein
Repository mit dem Ressourcennamen my-repo
.
Wenn Sie Terraform für Google Cloud zum ersten Mal verwenden, lesen Sie die Seite Erste Schritte – Google Cloud auf der Website von HashiCorp.
provider "google" {
project = "PROJECT-ID"
}
resource "google_artifact_registry_repository" "my-repo" {
provider = google-beta
location = "LOCATION"
repository_id = "REPOSITORY"
description = "DESCRIPTION"
format = "FORMAT"
}
resource "google_service_account" "repo-account" {
provider = google-beta
account_id = "ACCOUNT-ID"
display_name = "Repository Service Account"
}
resource "google_artifact_registry_repository_iam_member" "repo-iam" {
provider = google-beta
location = google_artifact_registry_repository.my-repo.location
repository = google_artifact_registry_repository.my-repo.name
role = "roles/artifactregistry.reader"
member = "serviceAccount:${google_service_account.repo-account.email}"
}
ACCOUNT-ID ist die ID des Dienstkontos. Dies ist der Teil des E-Mail-Felds des Dienstkontos vor dem Symbol @
.
Weitere Beispiele finden Sie in der Dokumentation zum google_artifact_registry_repository_iam .
Öffentlichen Zugriff auf ein Repository konfigurieren
Wenn Sie Artefakte haben, die allen Nutzern im Internet ohne Authentifizierung zugänglich gemacht werden sollen, speichern Sie diese in einem von Ihnen veröffentlichten Repository.
Um ein Repository für den schreibgeschützten Zugriff zu konfigurieren, weisen Sie dem Principal allUsers
die Rolle „Artifact Registry-Leser“ zu. Wir empfehlen außerdem, Kontingente für Nutzeranfragen festzulegen, damit ein einzelner Nutzer das Gesamtkontingent Ihres Projekts nicht aufbrauchen kann.
Console
Öffnen Sie in der Cloud Console die Seite Repositories.
Wählen Sie das entsprechende Repository aus.
Wenn das Infofeld nicht angezeigt wird, klicken Sie in der Menüleiste auf Infofeld ansehen.
Klicken Sie auf dem Tab „Berechtigungen“ auf Hauptkonto hinzufügen.
Geben Sie im Feld Neue Hauptkonten den Wert
allUsers
ein.Wählen Sie die Rolle Artifact Registry-Leser aus.
Legen Sie ein Nutzerlimit für Artifact Registry API-Anfragen fest, um Missbrauch durch nicht authentifizierte Nutzer zu verhindern. Eine Anleitung finden Sie unter Nutzung einschränken.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Führen Sie dazu diesen Befehl aus:
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --location=LOCATION --member=allUsers --role=ROLE
Dabei gilt:
REPOSITORY ist die ID des Repositorys.
ROLE ist die Rolle, die Sie erteilen möchten.
LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
Konfigurieren Sie beispielsweise das Repository
my-repo
am Speicherort--us-central1
als öffentlich:gcloud artifacts repositories add-iam-policy-binding my-repo \ --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader
Legen Sie ein Nutzerlimit für Artifact Registry API-Anfragen fest, um Missbrauch durch nicht authentifizierte Nutzer zu verhindern. Eine Anleitung finden Sie unter Nutzung begrenzen.
Berechtigungen aufheben
Entfernen Sie das Hauptkonto aus der Liste der autorisierten Konten, um den Zugriff auf ein Repository zu widerrufen Hauptkonten.
Entfernen Sie das Hauptkonto allUsers
, um den öffentlichen Zugriff aus einem Repository zu entfernen.
Console
So widerrufen Sie Berechtigungen:
Öffnen Sie in der Cloud Console die Seite Repositories.
Wählen Sie das entsprechende Repository aus.
Wenn das Infofeld nicht angezeigt wird, klicken Sie in der Menüleiste auf Infofeld ansehen.
Maximieren Sie auf dem Tab „Berechtigungen“ das entsprechende Hauptkonto. Wenn Sie ein öffentliches Repository privat machen, erweitern Sie das
allUsers
-Hauptkonto.Klicken Sie auf Rechteinhaber entfernen, um den Zugriff zu widerrufen.
gcloud
-
In the Google Cloud console, activate Cloud Shell.
At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
Führen Sie den folgenden Befehl aus, um eine Rolle auf Projektebene zu widerrufen:
gcloud projects remove-iam-policy-binding PROJECT \ --member=PRINCIPAL \ --role=ROLE
- PROJECT ist die Projekt-ID.
PRINCIPAL ist das Hauptkonto, für das die Bindung entfernt werden soll. Verwenden Sie das Format
user|group|serviceAccount:email
oderdomain:domain
.Beispiele:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
, oderdomain:example.domain.com
.ROLE ist die Rolle, die Sie aufheben möchten.
Führen Sie den folgenden Befehl aus, um die Rolle eines Repositorys zu widerrufen:
gcloud artifacts repositories remove-iam-policy-binding REPOSITORY --location=LOCATION \ --member=PRINCIPAL \ --role=ROLE
Dabei gilt:
- REPOSITORY ist die ID des Repositorys.
PRINCIPAL ist das Hauptkonto, für das die Bindung entfernt werden soll. Verwenden Sie das Format
user|group|serviceAccount:email
oderdomain:domain
.Beispiele:
user:test-user@gmail.com
,group:admins@example.com
,serviceAccount:test123@example.domain.com
, oderdomain:example.domain.com
.Geben Sie das Hauptkonto
allUsers
an, um den öffentlichen Zugriff auf das Repository zu widerrufen.ROLE ist die Rolle, die Sie aufheben möchten.
Führen Sie beispielsweise Folgendes aus, um eine Richtlinienbindung für die Rolle
roles/artifactregistry.writer
für den Nutzerwrite@gmail.com
mit dem Repositorymy-repo
am Standort--us-central1
zu entfernen:gcloud artifacts repositories remove-iam-policy-binding my-repo \ --location=us-central1 \ --member=user:write@gmail.com \ --role=roles/artifactregistry.writer
Führen Sie folgenden Befehl aus, um den öffentlichen Zugriff auf
my-repo
für den Standort--us-central1
zu widerrufen:gcloud artifacts repositories remove-iam-policy-binding my-repo \ --location=us-central1 \ --member=allUsers \ --role=roles/artifactregistry.reader
Bedingten Zugriff mit Tags gewähren
Projektadministratoren können Tags für Ressourcen in Google Cloud erstellen und im Resource Manager verwalten. Wenn Sie ein Tag an ein Artifact Registry-Repository anhängen, können Administratoren das Tag mit IAM-Bedingungen verwenden, um bedingten Zugriff auf das Repository zu gewähren.
Sie können einzelnen Artefakten keine Tags zuweisen.
Weitere Informationen finden Sie in der folgenden Dokumentation:
- Administratoren, die Tags und die Zugriffssteuerung einrichten
- Entwickler, die Tags an Repositories anhängen
In Google Cloud-Dienste einbinden
Für die meisten Google Cloud-Dienstkonten müssen für die Konfiguration des Zugriffs auf eine Registry nur die entsprechenden IAM-Berechtigungen erteilt werden.
Standardberechtigungen für Google Cloud-Dienste
Google Cloud-Dienste wie Cloud Build oder Google Kubernetes Engine verwenden ein Standarddienstkonto oder einen Dienst-Agenten, um mit Ressourcen innerhalb desselben Projekts zu interagieren.
In folgenden Fällen müssen Sie Berechtigungen selbst konfigurieren oder ändern:
- Der Google Cloud-Dienst befindet sich in einem anderen Projekt als Artifact Registry.
- Die Standardberechtigungen erfüllen Ihre Anforderungen nicht. Beispielsweise hat das Compute Engine-Standarddienstkonto schreibgeschützten Zugriff auf den Speicher im selben Projekt. Wenn Sie ein Image per Push von einer VM an Artifact Registry übertragen möchten, müssen Sie kann Berechtigungen für das VM-Dienstkonto ändern oder ein anderes Konto verwenden mit den erforderlichen Berechtigungen.
- Sie verwenden ein von Nutzern bereitgestelltes Dienstkonto für die Interaktion mit Artifact Registry anstelle des Standarddienstkontos.
Die folgenden Dienstkonten greifen normalerweise auf Artifact Registry zu. Die E-Mail-Adresse für das Dienstkonto enthält die Google Cloud Projekt-ID oder Projektnummer des Projekts, in dem der Dienst ausgeführt wird.
Dienst | Dienstkonto | E-Mail-Adresse | Berechtigungen |
---|---|---|---|
Flexible App Engine-Umgebung | App Engine-Dienstkonto | PROJECT-ID@appspot.gserviceaccount.com | Bearbeiterrolle, kann in Repositories lesen und schreiben |
Compute Engine | Compute Engine-Standarddienstkonto | PROJECT-NUMBER-compute@developer.gserviceaccount.com | Bearbeiterrolle, beschränkt auf Lesezugriff auf Repositories |
Cloud Build | Cloud Build-Dienstkonto | PROJECT-NUMBER@cloudbuild.gserviceaccount.com |
Die Standardberechtigungen umfassen Lese- und Schreibzugriff auf Repositories sowie die Möglichkeit, gcr.io-Repositories zu erstellen. |
Cloud Run |
Cloud Run-Dienst-Agent Der Dienst-Agent für run.googleapis.com . |
service-PROJECT-NUMBER@serverless-robot-prod.iam.gserviceaccount.com | Leserberechtigungen, auf Lesezugriff beschränkt |
GKE |
Compute Engine-Standarddienstkonto Das Standarddienstkonto für Knoten. |
PROJECT-NUMBER-compute@developer.gserviceaccount.com | Bearbeiterrolle, beschränkt auf Lesezugriff auf Repositories |
Zugriff auf Compute Engine-Instanzen gewähren
Für VM-Instanzen, die auf Repositories zugreifen, müssen sowohl die Artifact Registry-Berechtigungen als auch der Zugriffsbereich konfiguriert sein.
Die Zugriffsebene eines Dienstkontos wird anhand der IAM-Rollen festgelegt, die dem Dienstkonto zugewiesen sind. Mit den Zugriffsbereichen auf einer VM-Instanz werden die standardmäßigen OAuth-Bereiche für Anfragen festgelegt, die über die gcloud CLI und Clientbibliotheken auf der Instanz gestellt werden. Dies hat zur Folge, dass mit Zugriffsbereichen bei der Authentifizierung mit Standardanmeldedaten für Anwendungen der Zugriff auf API-Methoden weiter eingeschränkt werden kann.
In der Compute Engine werden die folgenden Standardeinstellungen verwendet:
- Das Compute Engine-Standarddienstkonto ist die Identität für die VM. Instanzen. Die E-Mail-Adresse des Dienstkontos hat das Suffix @developer.gserviceaccount.com.
- Das Standarddienstkonto hat die einfache IAM-Rolle „Bearbeiter“, sofern Sie dieses Verhalten nicht deaktiviert haben.
- Instanzen, die Sie mit dem Standarddienstkonto erstellen, haben die
Standardzugriffsbereiche von Compute Engine, einschließlich
Lesezugriff auf den Speicher. Die Rolle „Bearbeiter“ gewährt zwar in der Regel Schreibzugriff, aber der Zugriffsbereich für den Speicher
read-only
beschränkt das Instanzdienstkonto auf das Herunterladen von Artefakten aus allen Repositories im selben Projekt.
Sie müssen den Zugriffsbereich des Dienstkontos in folgenden Fällen konfigurieren:
- Das VM-Dienstkonto muss auf ein Repository in einem anderen Projekt zugreifen.
- Das VM-Dienstkonto muss neben dem Lesen von Artefakten aus Repositories weitere Aktionen ausführen. Dies wendet in der Regel Drittanbietertools auf einer VM an, die Images übertragen oder die Artifact Registry-Befehle
gcloud
ausführen muss.
So konfigurieren Sie Berechtigungen und legen den Zugriffsbereich fest:
Rufen Sie im Projekt mit Ihrer VM-Instanz den Namen des Compute Engine-Standarddienstkontos ab. Die E-Mail-Adresse des Dienstkontos enthält die Suffix @developer.gserviceaccount.com.
Weisen Sie dem Projekt mit dem Repository die Berechtigungen zu, damit das Dienstkonto auf das Repository zugreifen kann.
Legen Sie den Zugriffsbereich mit der Option --scopes fest.
Stoppen Sie die VM-Instanz. Siehe Instanz beenden.
Ändern Sie den Zugriffsbereich mit dem folgenden Befehl.
gcloud compute instances set-service-account INSTANCE --scopes=SCOPE
Ersetzen Sie SCOPE durch den entsprechenden Wert.
Für Docker werden die folgenden Optionen unterstützt:
storage-ro
– Gewährt Lesezugriff für das Abrufen von Images.storage-rw
– Gewährt Lese- und Schreibberechtigung für das Hoch- und Herunterladen von Images.cloud-platform
– Anzeige und Verwaltung von Daten einschließlich Metadaten in allen Google Cloud-Diensten
Verwenden Sie für andere Formate den Bereich
cloud-platform
.
Starten Sie die VM-Instanz neu. Siehe Beendete Instanz starten.
Zugriff auf Google Kubernetes Engine-Cluster gewähren
GKE-Cluster und Knotenpools können Container abrufen, zusätzliche Konfiguration, wenn alle folgenden Anforderungen erfüllt sind:
- GKE befindet sich im selben Projekt wie Artifact Registry
- Knoten verwenden das Standarddienstkonto, also das Compute Engine-Standarddienstkonto.
- Knoten wurden mit Lesezugriff auf den Speicher erstellt von:
- Über die Standardzugriffsbereiche von Compute Engine.
- Gewähren Sie den Zugriffsbereich
cloud-platform
oder einen anderen Bereich, der Lesezugriff auf den Speicher umfasst.
- Sie verwenden eine unterstützte Version von GKE.
Wenn Ihre GKE-Umgebung diese Anforderungen nicht erfüllt, Wie Sie den Zugriff gewähren, hängt davon ab, ob Sie den Compute Engine-Standarddienstkonto oder ein vom Nutzer bereitgestelltes Dienstkonto als die Identität für Ihre Knoten.
- Standarddienstkonto
Die folgenden Konfigurationsanforderungen gelten für das Compute Engine-Standarddienstkonto:
Wenn sich GKE in einem anderen Projekt befindet als Artifact Registry: Gewähren Sie dem Dienstkonto.
Wenn Sie Images pushen, mit Repositories für andere Formate als Container interagieren oder
gcloud
-Befehle von Ihrem Cluster ausführen möchten, müssen Sie beim Erstellen des Clusters oder Knotenpools Zugriffsbereiche für das Dienstkonto festlegen.Falls Sie keine unterstützte Version von GKE, konfigurieren Sie imagePullSecrets.
- Vom Nutzer bereitgestelltes Dienstkonto
Wenn Sie ein von Nutzern bereitgestelltes Dienstkonto als Identität für einen Cluster verwenden möchten, müssen Sie Folgendes tun:
Weisen Sie dem Dienstkonto die erforderlichen Berechtigungen aus dem Google Cloud-Projekt zu, in dem Artifact Registry ausgeführt wird.
Standardmäßig einen Cluster oder Knotenpool mit einem vom Nutzer bereitgestellten Dienst erstellen Konto gewährt den Zugriffsbereich
cloud-platform
.Wenn Sie das Flag
--scopes
mit dem Befehl gcloud container clusters create oder gcloud container node-pools create verwenden, müssen Sie die entsprechenden Zugriffsbereiche für die Verwendung mit der Artifact Registry angeben.
Zugriffsbereiche festlegen
Zugriffsbereiche sind die bisherige Methode, Compute Engine-VMs Damit GKE-Knoten Images aus Artifact Registry-Repositories abrufen können, müssen sie den Lesezugriff auf den Speicher oder einen anderen Speicherzugriffsbereich haben, der Lesezugriff auf den Speicher umfasst.
Sie können Zugriffsbereiche nur beim Erstellen eines Clusters oder Knotenpools festlegen. Sie können die Zugriffsbereiche auf vorhandenen Knoten nicht ändern.
- Wenn Sie das Compute Engine-Standarddienstkonto verwenden, erstellt GKE Knoten mit den Standardzugriffsbereichen der Compute Engine, einschließlich Lesezugriff auf den Speicher.
- Wenn Sie ein vom Nutzer bereitgestelltes Dienstkonto verwenden, erstellt GKE
Knoten mit dem Bereich
cloud-platform
, der für die meisten Google Cloud-Dienste.
Führen Sie den folgenden Befehl aus, um beim Erstellen eines Clusters Zugriffsbereiche anzugeben:
gcloud container clusters create NAME --scopes=SCOPES
Führen Sie den folgenden Befehl aus, um beim Erstellen eines Knotenpools Zugriffsbereiche anzugeben:
gcloud container node-pools create NAME --scopes=SCOPES
Ersetzen Sie die folgenden Werte:
- NAME ist der Name des Clusters oder Knotenpools.
SCOPES ist eine durch Kommas getrennte Liste der Zugriffsbereiche, die zugewiesen werden sollen.
Verwenden Sie einen der folgenden Zugriffsbereiche, um auf Docker-Repositories zuzugreifen:
storage-ro
– Gewährt Lesezugriff für das Abrufen von Images.storage-rw
– Gewährt Lese- und Schreibberechtigung für das Hoch- und Herunterladen von Images.cloud-platform
– Anzeige und Verwaltung von Daten einschließlich Metadaten in allen Google Cloud-DienstenFür den Zugriff auf andere Repositories müssen Sie den Bereich
cloud-platform
verwenden.
Eine vollständige Liste der Bereiche finden Sie in der Dokumentation zu gcloud container clusters create oder gcloud container node-pools create.
Weitere Informationen zu Bereichen, die Sie beim Erstellen eines neuen Clusters festlegen können, finden Sie in der Dokumentation zum Befehl gcloud container clusters create.
imagePullSecret konfigurieren
So konfigurieren Sie ein imagePullSecret
:
Suchen Sie im Projekt mit GKE die Compute Engine-Standardeinstellung Dienstkonto. Die E-Mail-Adresse des Kontos hat das Suffix @developer.gserviceaccount.com
Laden Sie den Dienstkontoschlüssel für das Dienstkonto herunter.
Bestätigen Sie im Projekt mit dem Repository, dass Sie dem Repository Berechtigungen erteilt haben.
Erstellen Sie im Projekt mit Ihrem Cluster ein
imagePullSecret
-Secret namensartifact-registry
mit dem Dienstkontoschlüssel.kubectl create secret docker-registry artifact-registry \ --docker-server=https://LOCATION-docker.pkg.dev \ --docker-email=SERVICE-ACCOUNT-EMAIL \ --docker-username=_json_key \ --docker-password="$(cat KEY-FILE)"
Wo
- LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
- SERVICE-ACCOUNT-EMAIL ist die E-Mail-Adresse des Compute Engine-Dienstkontos.
- KEY-FILE ist der Name der Dienstkonto-Schlüsseldatei. Beispiel:
key.json
.
Öffnen Sie Ihr Standarddienstkonto:
kubectl edit serviceaccount default --namespace default
Jeder Namespace in Ihrem Kubernetes-Cluster hat ein Standarddienstkonto namens
default
. Dieses Standarddienstkonto wird verwendet, um Ihr Container-Image abzurufen.Fügen Sie das neu erstellte
imagePullSecret
-Secret Ihrem Standarddienstkonto hinzu:imagePullSecrets: - name: artifact-registry
Ihr Dienstkonto sollte nun so aussehen:
apiVersion: v1 kind: ServiceAccount metadata: name: default namespace: default ... secrets: - name: default-token-zd84v # The secret you created: imagePullSecrets: - name: artifact-registry
Jetzt ist für alle neuen Pods, die im aktuellen default
-Namespace erstellt werden, das imagePullSecret
-Secret definiert.
Artifact Registry-Dienstkonto
Der Artifact Registry-Dienst-Agent ist ein von Google verwaltetes Dienstkonto, handelt bei der Interaktion mit Google Cloud im Namen von Artifact Registry Dienstleistungen. Weitere Informationen zum Konto und zu den Berechtigungen finden Sie unter Artifact Registry-Dienstkonto.
Nächste Schritte
Nachdem Sie Berechtigungen eingerichtet haben, sollten Sie sich näher über die Arbeit mit Ihren Artefakten informieren.
- Container-Images: Docker, Helm
- Sprachpakete: Java, Node.js, Python, Go
- Betriebssystempakete: Debian, RPM