Diese Seite wurde von der Cloud Translation API übersetzt.

Zugriffssteuerung mit IAM

Auf dieser Seite wird die Zugriffssteuerung mit Identity and Access Management (IAM) in Artifact Registry beschrieben.

Die Standardberechtigungen für Artifact Registry minimieren den Einrichtungsaufwand bei der Implementierung einer CI/CD-Pipeline. Sie können Artifact Registry auch in CI-/CD-Tools von Drittanbietern einbinden und die Berechtigungen und Authentifizierung für den Zugriff auf Repositories konfigurieren.

Wenn Sie die Artefaktanalyse für die Arbeit mit Containermetadaten verwenden, z. B. Sicherheitslücken in Images, lesen Sie die Artefaktanalyse-Dokumentation für Informationen dazu, wie Sie Zugriff zum Aufrufen oder Verwalten von Metadaten gewähren können.

Hinweis

Aktivieren Sie Artifact Registry. Dazu gehört auch die Aktivierung der API und die Installation der Google Cloud CLI.
Wenn Sie Repository-spezifische Berechtigungen anwenden möchten, erstellen Sie ein Artifact Registry-Repository für Ihre Pakete.

Übersicht

IAM-Berechtigungen und Rollen bestimmen, ob Sie Daten in einem Artifact Registry-Repository erstellen, aufrufen, bearbeiten oder löschen können.

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.

Google Cloud Standardberechtigungen

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 Ihre Dienste im selben Google Cloud Projekt befinden und die Standardberechtigungen 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, weisen Sie dem Cloud Run-Dienst-Agenten die erforderliche Rolle zu.

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:
- Compute Engine
- GKE
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 verwenden Anwendungen, die außerhalb von Google Cloud ausgeführt werden, Dienstkontoschlüssel für den Zugriff auf Google Cloud -Ressourcen. 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 Pool für die Identitätsföderation von Arbeitslasten.
Erstellen Sie einen Anbieter der Identitätsföderation von Arbeitslasten.
Gewähren Sie dem Workload Identity-Pool die entsprechende Artifact Registry-Rolle, um den Zugriff auf das Repository zu ermöglichen. Weitere Informationen finden Sie unter Externer Arbeitslast Zugriff auf Ressourcen gewähren Google Cloud .
Wenn Sie länger auf Artifact Registry zugreifen müssen, konfigurieren Sie in der Anmeldedatenkonfiguration eine längere Gültigkeitsdauer für das OIDC-Token.
Konfigurieren Sie den Client eines Drittanbieters für die Authentifizierung bei Artifact Registry.
- Container-Images: Docker, Helm
- Sprachpakete: Java, Node.js, Python, Go
- Betriebssystempakete: Debian, RPM
- Sonstiges: Kubeflow-Pipeline-Vorlagen

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.
- Container-Images: Docker, Helm
- Sprachpakete: Java, Node.js, Python, Go
- Betriebssystempakete: Debian, RPM
- Sonstiges: Kubeflow-Pipeline-Vorlagen

GitLab auf Google Cloud

Die GitLab on Google Cloud -Integration verwendet die Workload Identity-Föderation für die Autorisierung und Authentifizierung von GitLab-Arbeitslasten auf Google Cloud , ohne dass Dienstkonten oder Dienstkontoschlüssel erforderlich sind. Weitere Informationen zur Verwendung der Workload Identity-Föderation in dieser Partnerschaft finden Sie unter Google Cloud Workload Identity-Föderation und IAM-Richtlinien.

Informationen zum Einrichten der Workload Identity-Föderation und der erforderlichen IAM-Rollen für GitLab auf Google Cloudfinden Sie im GitLab-Tutorial Google Cloud Workload Identity Federation und IAM-Richtlinien.

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 der Rechtsinhaber, der die Anfrage stellt, die erforderlichen Berechtigungen zur Verwendung der Ressource hat. Berechtigungen werden Hauptkonten durch das Festlegen von Richtlinien gewährt, die dem Hauptkonto eine vordefinierte Rolle für die Ressource zuweisen.

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.

Verwenden Sie die folgenden vordefinierten Rollen für Repositories in der Domain pkg.dev:

Rolle	Beschreibung
Artifact Registry-Leser (`roles/artifactregistry.reader`)	Artefakte ansehen und abrufen, Repository-Metadaten ansehen
Artifact Registry-Writer (`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, die für die Migration von Container Registry zu Artifact Registry erforderlich sind.

Rolle	Beschreibung
Container Registry -> Artifact Registry Migration Admin (`roles/artifactregistry.containerRegistryMigrationAdmin`)	Enthält alle Berechtigungen, die zum Ausführen von Migrationstools erforderlich sind
Artifact Registry Create-on-push Writer (`roles/artifactregistry.createOnPushWriter`)	Artefakte lesen und schreiben Erstellen Sie gcr.io-Repositories, wenn Sie auf `gcr.io`-URLs pushen.
Artifact Registry Create-on-push Repository Administrator (`roles/artifactregistry.createOnPushRepoAdmin`)	Artefakte lesen, schreiben und löschen Erstellen Sie gcr.io-Repositories.

Eine vollständige Liste der einzelnen Berechtigungen in den einzelnen Rollen finden Sie unter Artifact Registry-Rollen. Mit dem Befehl gcloud iam roles describe können Sie sich auch eine Liste der Berechtigungen in den einzelnen Rollen anzeigen lassen.

Einfache IAM-Rollen

Einfache Rollen sind Rollen mit sehr weitreichenden Berechtigungen, die es schon vor der Einführung von IAM gab. In einer Produktionsumgebung sollten Sie keine einfachen Rollen zuweisen, Sie können sie aber in einer Entwicklungs- oder Testumgebung 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 in der Referenz zu einfachen und vordefinierten IAM-Rollen.

Rollen werden gewährt

Weisen Sie Rollen auf Projektebene zu, wenn für alle Repositories im Projekt dieselben Rollen gelten. Wenn für einige Konten unterschiedliche Zugriffsebenen erforderlich sind, erteilen Sie Rollen auf Repository-Ebene.

Wenn Sie Rollen für ein virtuelles Repository gewähren, gelten diese Rollen für alle Upstream-Repositories, die über das virtuelle Repository verfügbar sind, unabhängig von den Berechtigungen für einzelne Repositories.

Wenn Sie Rollen mit dem Befehl gcloud zuweisen, können Sie eine einzelne Rollenbindung für ein Hauptkonto angeben oder umfangreiche Richtlinienänderungen vornehmen, indem Sie die Zulassungsrichtlinie einer Ressource abrufen, ändern und dann die geänderte Zulassungsrichtlinie festlegen. Weitere Informationen finden Sie unter Mehrere Rollen programmatisch zuweisen oder widerrufen.

Projektweite Rollen 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.
Zur 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äß dem Sicherheitsprinzip der geringsten Berechtigung sollten Sie die geringstmögliche Berechtigung einräumen, um auf die erforderlichen Artifact Registry-Ressourcen zuzugreifen. Informationen zu vordefinierten Rollen und Berechtigungen für Artifact Registry finden Sie unter Vordefinierte Artifact Registry-Rollen.
Klicken Sie auf Speichern.

gcloud

In the Google Cloud console, activate Cloud Shell.

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 oder domain:domain.
  
  Beispiele: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com, oder domain:example.domain.com.
- ROLE ist die Rolle, die Sie erteilen möchten.
Weitere Informationen finden Sie in der Dokumentation zu add-iam-policy-binding.

Informationen zum Zuweisen von Rollen mithilfe einer Richtliniendatei finden Sie unter Mehrere Rollen programmatisch zuweisen oder widerrufen.

Repository-spezifische Rollen zuweisen

Rollen 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.

Zur 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 Groups als Hauptkonten hinzufügen.
Wählen Sie eine Rolle für das Hauptkonto aus. Gemäß dem Sicherheitsprinzip der geringsten Berechtigung sollten Sie die geringstmögliche Berechtigung einräumen, um auf die erforderlichen Artifact Registry-Ressourcen zuzugreifen. Informationen zu vordefinierten Rollen und Berechtigungen für Artifact Registry finden Sie unter Vordefinierte Artifact Registry-Rollen.
Klicken Sie auf Speichern.

gcloud

In the Google Cloud console, activate Cloud Shell.

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 oder domain:domain.
  
  Beispiele: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com, oder domain: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 Nutzer write@gmail.com mit dem Repository my-repo am Standort --us-west1 hinzufügen möchten, führen Sie Folgendes aus:
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
--location=us-west1 --member=user:write@gmail.com --role=roles/artifactregistry.writer
```
Wenn Sie Rollen mithilfe einer Richtliniendatei zuweisen möchten, verwenden Sie die unter Mehrere Rollen programmatisch zuweisen oder widerrufen beschriebene Vorgehensweise mit den Befehlen gcloud artifacts repositories get-iam-policy und gcloud artifacts repositories set-iam-policy.

Terraform

Verwenden Sie die Ressource google_artifact_registry_repository_iam, um eine IAM-Richtlinie zu konfigurieren. Im folgenden Beispiel wird ein Dienstkonto mit dem Ressourcennamen repo-account definiert und ihm Lesezugriff auf ein Repository mit dem Ressourcennamen my-repo gewährt.

Wenn Sie Terraform für Google Cloudnoch nicht kennen, lesen Sie die Seite Erste Schritte – Google Cloud auf der HashiCorp-Website.

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 zur Ressource 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 Nutzer 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.

Zur 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 allUsers ein.
Wählen Sie die Rolle Artifact Registry-Leser aus.
Legen Sie ein nutzerbezogenes Limit für Artifact Registry API-Anfragen fest, um Missbrauch durch nicht authentifizierte Nutzer zu verhindern. Eine Anleitung finden Sie unter Nutzung begrenzen.

gcloud

In the Google Cloud console, activate Cloud Shell.

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 zuweisen möchten.
- LOCATION ist der regionale oder multiregionale Speicherort für das Repository.
Konfigurieren Sie beispielsweise das Repository my-repo am Speicherort --us-west1 als öffentlich:
```
gcloud artifacts repositories add-iam-policy-binding my-repo \
 --location=us-west1 --member=allUsers --role=roles/artifactregistry.reader
```
Legen Sie ein nutzerbezogenes Limit für Artifact Registry API-Anfragen fest, um Missbrauch durch nicht authentifizierte Nutzer zu verhindern. Eine Anleitung finden Sie unter Nutzung begrenzen.

Rollen werden entzogen

Wenn Sie den Zugriff auf ein Repository widerrufen möchten, entfernen Sie das Hauptkonto aus der Liste der autorisierten 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.

Zur 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, maximieren Sie das Prinzipal allUsers.
Klicken Sie auf Rechteinhaber entfernen, um den Zugriff zu widerrufen.

gcloud

In the Google Cloud console, activate Cloud Shell.

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 Mitglied, für das die Bindung entfernt werden soll. Verwenden Sie das Format user|group|serviceAccount:email oder domain:domain.
  
  Beispiele: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com, oder domain: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 Mitglied, für das die Bindung entfernt werden soll. Verwenden Sie das Format user|group|serviceAccount:email oder domain:domain.
  
  Beispiele: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com, oder domain: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 Nutzer write@gmail.com mit dem Repository my-repo am Standort --us-west1 zu entfernen:
```
gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location=us-west1 \
   --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-west1 zu widerrufen:
```
gcloud artifacts repositories remove-iam-policy-binding my-repo \
   --location=us-west1 \
   --member=allUsers \
   --role=roles/artifactregistry.reader
```

Bedingten Zugriff mit Tags gewähren

Projektadministratoren können Tags für Ressourcen in Google Clouderstellen und in 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 Zugriffssteuerung einrichten
- Tags erstellen und verwalten
- Tags und Zugriffssteuerung
Entwickler, die Tags an Repositories anhängen
- Tagging-Repositories

Integration mit Google Cloud -Diensten

Für die meisten Google Cloud Dienstkonten müssen für die Konfiguration des Zugriffs auf eine Registry nur die entsprechenden IAM-Rollen erteilt werden.

Standarddienstkonten 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.
Sie verwenden ein von Nutzern bereitgestelltes Dienstkonto für die Interaktion mit Artifact Registry anstelle des Standarddienstkontos.
Die Konfiguration Ihrer Organisationsrichtlinie verhindert die automatische Rollenzuweisung für Standarddienstkonten.

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
Flexible App Engine-Umgebung	App Engine-Dienstkonto	`PROJECT-ID`@appspot.gserviceaccount.com
Compute Engine	Standardmäßiges Compute Engine-Dienstkonto	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com
Cloud Build	Compute Engine-Dienstkonto oder Legacy Cloud Build-Dienstkonto	Je nach Ihren Organisationseinstellungen lautet die E-Mail-Adresse des Standarddienstkontos eine der folgenden: Compute Engine: `PROJECT-NUMBER`-compute@developer.gserviceaccount.com Cloud Build: `PROJECT-NUMBER`@cloudbuild.gserviceaccount.com Hinweis:Das Cloud Build-Standarddienstkonto, das zum Ausführen von Builds verwendet wird, wurde vom Cloud Build-Legacy-Dienstkonto in das Compute Engine-Standarddienstkonto geändert. Weitere Informationen finden Sie unter Änderung des Cloud Build-Dienstkontos.
Cloud Run	Cloud Run-Dienst-Agent Der Dienst-Agent für `run.googleapis.com`.	service-`PROJECT-NUMBER`@serverless-robot-prod.iam.gserviceaccount.com
GKE	Compute Engine-Standarddienstkonto Das Standarddienstkonto für Knoten.	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com

Abhängig von der Konfiguration Ihrer Organisationsrichtlinie kann dem Standarddienstkonto für Ihr Projekt automatisch die Rolle "Bearbeiter" zugewiesen werden. Wir empfehlen dringend, die automatische Rollenzuweisung zu deaktivieren, indem Sie die Einschränkung der Organisationsrichtlinien iam.automaticIamGrantsForDefaultServiceAccounts erzwingen. Wenn Sie Ihre Organisation nach dem 3. Mai 2024 erstellt haben, wird diese Einschränkung standardmäßig erzwungen.

Wenn Sie die automatische Rollenzuweisung deaktivieren, müssen Sie entscheiden, welche Rollen den Standarddienstkonten zugeteilt werden sollen, und diese Rollen dann selbst zuweisen.

Wenn das Standarddienstkonto bereits die Rolle „Bearbeiter“ hat, sollten Sie die Rolle „Bearbeiter“ durch weniger strikte Rollen ersetzen.Verwenden Sie zum sicheren Ändern der Rollen des Dienstkontos den Policy Simulator, um die Auswirkungen der Änderung zu sehen, und weisen Sie die entsprechenden Rollen zu und widerrufen Sie sie.

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 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 der Compute Engine, einschließlich schreibgeschützten Zugriffs 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 Rollen 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 hat das 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.
1. Stoppen Sie die VM-Instanz. Siehe Instanz beenden.
2. Ä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 – Daten einschließlich Metadaten imGoogle Cloud -Dienst ansehen und verwalten
  - Verwenden Sie für andere Formate den Bereich cloud-platform.
3. 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 ohne zusätzliche Konfiguration abrufen, wenn die 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:
- Verwenden Sie die Standardzugriffsbereiche der Compute Engine.
- Gewähren Sie den Zugriffsbereich cloud-platform oder einen anderen Bereich, der Lesezugriff auf den Speicher umfasst.
Sie führen eine unterstützte Version von GKE aus

Wenn Ihre GKE-Umgebung diese Anforderungen nicht erfüllt, hängt die Anleitung für die Gewährung des Zugriffs davon ab, ob Sie das Compute Engine-Standarddienstkonto oder ein von Nutzern bereitgestelltes Dienstkonto als Identität für die Knoten verwenden.

Standarddienstkonto

Die folgenden Konfigurationsanforderungen gelten für das Compute Engine-Standarddienstkonto:

Befindet sich GKE in einem anderen Projekt als Artifact Registry, gewähren Sie dem Dienstkonto die erforderlichen Berechtigungen.
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.
Wenn Sie keine unterstützte Version von GKE verwenden, 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:

Gewähren Sie dem Dienstkonto die erforderlichen Berechtigungen aus demGoogle Cloud -Projekt, in dem Artifact Registry ausgeführt wird.
Wenn Sie einen Cluster oder Knotenpool mit einem vom Nutzer bereitgestellten Dienstkonto erstellen, wird standardmäßig der Zugriffsbereich cloud-platform gewährt.

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 alte Methode zum Festlegen der Autorisierung für 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 cloud-platform-Bereich, der für die meistenGoogle Cloud -Dienste erforderlich ist.

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 zu gewährenden Zugriffsbereiche.
- 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 – Daten einschließlich Metadaten imGoogle Cloud -Dienst ansehen und verwalten
- Wenn Sie auf andere Repositories zugreifen möchten, 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 nach dem Compute Engine-Standarddienstkonto. Die E-Mail-Adresse des Kontos hat das Suffix @developer.gserviceaccount.com.
Laden Sie den Dienstkontoschlüssel für das Dienstkonto herunter.

Hinweis: Dienstkontoschlüssel stellen ein Sicherheitsrisiko dar, wenn sie nicht ordnungsgemäß verwaltet werden. Sie sollten nach Möglichkeit eine sicherere Alternative zu Dienstkontoschlüsseln auswählen. Wenn Sie sich mit einem Dienstkontoschlüssel authentifizieren müssen, sind Sie für die Sicherheit des privaten Schlüssels und für andere Vorgänge verantwortlich, die unter Best Practices für die Verwaltung von Dienstkontoschlüsseln beschrieben werden. Wenn Sie keinen Dienstkontoschlüssel erstellen können, ist das Erstellen von Dienstkontoschlüsseln für Ihre Organisation möglicherweise deaktiviert. Weitere Informationen finden Sie unter Standardmäßig sichere Organisationsressourcen verwalten.
Wenn Sie den Dienstkontoschlüssel von einer externen Quelle erhalten haben, müssen Sie ihn vor der Verwendung validieren. Weitere Informationen finden Sie unter Sicherheitsanforderungen für extern abgerufene Anmeldedaten.
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 namens artifact-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)"
```
Ersetzen Sie Folgendes:
- LOCATION ist der regionale oder multiregionale Speicherort des Repositorys.
- 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, das bei der Interaktion mit Google Cloud-Diensten im Namen von Artifact Registry agiert. Weitere Informationen zu dem Konto und seinen 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
Language packages: Java, Node.js, Python, Go
OS packages: Debian, RPM

Sie können Downloads von Artefakten mit Downloadregeln einschränken.

Zugriffssteuerung mit IAM

Hinweis

Übersicht

Google Cloud Standardberechtigungen

Integration von Drittanbietern

GitLab auf Google Cloud

Rollen und Berechtigungen

Vordefinierte Artifact Registry-Rollen

Einfache IAM-Rollen

Rollen werden gewährt

Projektweite Rollen gewähren

Console

gcloud

Repository-spezifische Rollen zuweisen

Console

gcloud

Terraform

Öffentlichen Zugriff auf ein Repository konfigurieren

Console

gcloud

Rollen werden entzogen

Console

gcloud

Bedingten Zugriff mit Tags gewähren

Integration mit Google Cloud -Diensten

Standarddienstkonten für Google Cloud Dienste

Zugriff auf Compute Engine-Instanzen gewähren

Zugriff auf Google Kubernetes Engine-Cluster gewähren

Zugriffsbereiche festlegen

imagePullSecret konfigurieren

Artifact Registry-Dienstkonto

Nächste Schritte

`imagePullSecret` konfigurieren