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.

Standardberechtigungen für Artifact Registry minimieren den Einrichtungsaufwand, wenn CI/CD-Pipeline implementieren 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 wie Sicherheitslücken in Images, siehe Dokumentation zur Artefaktanalyse .

Hinweise

Artifact Registry aktivieren Dazu gehört auch das Aktivieren der API und das Installieren der Google Cloud CLI.
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.

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 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. Im Projekt mit Artifact Registry erteilen Sie die Workload Identity-Pool oder Dienstkonto für jeden Dienst, erforderliche Rolle. Wenn Sie eine Verbindung zu Cloud Run herstellen, gewähren Sie den Cloud Run-Dienst-Agent die erforderliche Rolle.
Sie eine GKE-Version ohne integrierte Abrufen von Images aus Artifact Registry wird unterstützt. Weitere Informationen finden Sie in der GKE mit einer Anleitung zur Konfiguration.
Sie möchten, dass das Standarddienstkonto Lese- und Schreibzugriff auf Repositories hat. Weitere Informationen finden Sie hier:
- Compute Engine
- GKE
Sie verwenden ein vom Nutzer bereitgestelltes Dienstkonto für Ihre Laufzeitumgebungen. 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 die 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 Identitätsföderation von Arbeitslasten können Sie Identity and Access Management für folgende Aufgaben verwenden: externen Identitäten IAM-Rollen gewähren, einschließlich der Möglichkeit, die Identität von Dienstkonten zu übernehmen. Bei diesem Ansatz vermeiden Sie den mit dem Dienst verbundenen Wartungs- und Sicherheitsaufwand Kontoschlüssel.

Workload Identity-Föderation verwenden:

Erstellen Sie einen Workload Identity-Föderationspool.
Anbieter der Identitätsföderation von Arbeitslasten erstellen
Gewähren Sie der Arbeitslast die entsprechende Artifact Registry-Rolle. Identitätspool, um den Zugriff auf das Repository zuzulassen.
Drittanbieter-Client für die Authentifizierung konfigurieren Artifact Registry.
- Container-Images: Docker Helm
- Sprachpakete: Java, Node.js, Python, Go
- Betriebssystempakete: Debian U/min
- Sonstiges: Kubeflow-Pipeline-Vorlagen

Ein 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.
Drittanbieter-Client für die Authentifizierung konfigurieren Artifact Registry.
- Container-Images: Docker Helm
- Sprachpakete: Java, Node.js, Python, Go
- Betriebssystempakete: Debian U/min
- Sonstiges: Kubeflow-Pipeline-Vorlagen

GitLab in 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 Workload Identity-Föderation in dieser Partnerschaft verwendet wird, siehe Authentifizierungsübersicht

So richten Sie die Identitätsföderation von Arbeitslasten ein und IAM-Rollen für GitLab in Google Cloud – siehe GitLab-Tutorial Google Cloud Workload Identity-Föderation und IAM-Richtlinien.

Folgen Sie der GitLab-Anleitung, um Ihr Artifact Registry-Repository zu verbinden Google Artifact Registry:

Rollen und Berechtigungen

Für jede Artifact Registry API-Methode muss das Hauptkonto (Nutzer, Gruppe oder Dienstkonto), von der die Anfrage stammt, verfügt über die erforderlichen Berechtigungen, verwenden Sie die Ressource. Berechtigungen werden Hauptkonten gewährt, 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 die Artifact Registry gewähren zu erstellen.

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 gcr.io-Repositories zum Hosten von Images für die Domain gcr.io. Die enthalten keine Berechtigungen zum Erstellen anderer Repository-Formate in 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-Autor (`roles/artifactregistry.createOnPushWriter`)	Artefakte lesen und schreiben. gcr.io-Repositories erstellen
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 hohen Berechtigungen, die es schon vor der Einführung gab. von IAM. Mit einfachen Rollen können Sie Hauptkonten umfassende Zugriff auf Google Cloud-Ressourcen.

Vordefinierte Rollen für Repository verwenden wenn möglich, sodass Nutzer und Dienstkonten nur über Berechtigungen erforderlich.

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, sind diese gelten für alle Upstream-Repositories, die über die virtuelle Repository unabhängig von den einzelnen Repository-Berechtigungen.

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 einen Nutzer oder ein Dienstkonto hinzu und gewähren ihm ein Artifact Registry-Rolle:

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äß 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

Aktivieren Sie Cloud Shell in der Google Cloud Console.

Cloud Shell aktivieren

Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
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.

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.
Hinweis: Durch das Anwenden einer Richtliniendatei auf ein Projekt werden alle IAM-Berechtigungen zurückgesetzt. Richtlinien für dieses Projekt. Verwenden Sie diese Option daher mit Vorsicht.

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.

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

Aktivieren Sie Cloud Shell in der Google Cloud Console.

Cloud Shell aktivieren

Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
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-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 in policy.yaml definierten Richtlinie festzulegen:
```
gcloud artifacts repositories set-iam-policy my-repo policy.yaml --location=us-central1
```
Hinweis: Durch das Anwenden einer Richtliniendatei auf ein Repository werden alle IAM-Richtlinien für dieses Repository. Verwenden Sie diese Option daher mit Vorsicht geboten.

Terraform

Verwenden Sie die Ressource google_artifact_registry_repository_iam, um IAM-Richtlinie 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 öffentlichen Lesezugriff zu konfigurieren, gewähren Sie den Rolle „Artifact Registry-Leser“ für das Hauptkonto allUsers. Außerdem empfehlen wir, Begrenzung der Kontingente für Nutzeranfragen, sodass eine einzelne Nutzer kann das Gesamtkontingent Ihres Projekts nicht aufbrauchen.

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

gcloud

Aktivieren Sie Cloud Shell in der Google Cloud Console.

Cloud Shell aktivieren

Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
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 Limit pro Nutzer für Artifact Registry API-Anfragen fest, um zu verhindern Missbrauch durch nicht authentifizierte Nutzer. Eine Anleitung finden Sie unter Nutzung einschränken.

Berechtigungen aufheben

Entfernen Sie das Hauptkonto aus der Liste der autorisierten Konten, um den Zugriff auf ein Repository zu widerrufen Hauptkonten.

Entfernen Sie das allUsers-Hauptkonto, um den öffentlichen Zugriff auf ein 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, erweitern Sie das allUsers-Hauptkonto.
Klicken Sie auf Hauptkonto entfernen, um den Zugriff zu widerrufen.

gcloud

Aktivieren Sie Cloud Shell in der Google Cloud Console.

Cloud Shell aktivieren

Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
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 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 Hauptkonto, 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-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 am 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 verwalten Sie sie in Resource Manager. Wenn Sie ein Tag an eine Artifact Registry-Repository ist, können Administratoren das Tag mit IAM-Bedingungen zum Gewähren von bedingtem Zugriff auf das Repository.

Sie können keine Tags an einzelne Artefakte anhängen.

Weitere Informationen finden Sie in der folgenden Dokumentation:

Administratoren, die Tags und Zugriffssteuerung einrichten <ph type="x-smartling-placeholder">
- Tags erstellen und verwalten
- Tags und Zugriffssteuerung:
Entwickler, die Tags an Repositories anhängen <ph type="x-smartling-placeholder">
- Tagging-Repositories

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 eine Standarddienstkonto oder Dienst-Agent, mit dem Sie interagieren können innerhalb desselben Projekts.

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.
nutzen Sie ein von einem Nutzer bereitgestelltes Dienstkonto, Artifact Registry anstelle des Standarddienstkontos verwenden.

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	Google App Engine Dienstkonto	`PROJECT-ID`@appspot.gserviceaccount.com	Bearbeiter, kann in Repositories lesen und schreiben
Compute Engine	<ph type="x-smartling-placeholder"></ph> Compute Engine-Standarddienstkonto	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	Rolle „Bearbeiter“, beschränkt auf Lesezugriff auf Repositories
Cloud Build	Cloud Build-Dienst Konto	`PROJECT-NUMBER`@cloudbuild.gserviceaccount.com Hinweis: Das Cloud Build-Standarddienstkonto zum Ausführen von Builds geändert wird. Weitere Informationen Weitere Informationen finden Sie unter Änderung des Cloud Build-Dienstkontos.	Standardberechtigungen Lese- und Schreibzugriff auf Repositories und die Möglichkeit, gcr.io-Repositories
Cloud Run	<ph type="x-smartling-placeholder"></ph> Cloud Run-Dienst-Agent Der Dienst-Agent für `run.googleapis.com`.	service-`PROJECT-NUMBER`@serverless-robot-prod.iam.gserviceaccount.com	Leseberechtigungen, beschränkt auf Lesezugriff auf Repositories
GKE	<ph type="x-smartling-placeholder"></ph> Compute Engine-Standarddienstkonto Das Standarddienstkonto für Knoten.	`PROJECT-NUMBER`-compute@developer.gserviceaccount.com	Rolle „Bearbeiter“, 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.

Während die Zugriffsebene eines Dienstkontos vom Dem Dienstkonto zugewiesene IAM-Rollen, Zugriffsbereiche auf eine VM-Instanz die standardmäßigen OAuth-Bereiche für Anfragen, die über die gcloud CLI und Clientbibliotheken auf der Instanz. Daher werden Zugriffsbereiche den Zugriff auf API-Methoden bei der Authentifizierung mit Standardanmeldedaten für Anwendungen.

Compute Engine verwendet die folgenden Standardeinstellungen:

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 das IAM-Basic Rolle „Bearbeiter“, wenn 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 Bearbeiterrolle gewährt in der Regel Schreibrechte, schränkt der Speicherzugriffsbereich read-only den Instanzdienst ein Artefakte nur aus einem beliebigen Repository im selben Projekt herunterzuladen.

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 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 – Anzeige und Verwaltung von Daten einschließlich Metadaten in allen Google Cloud-Diensten
  - 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 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: <ph type="x-smartling-placeholder">
- Über die Standardzugriffsbereiche von Compute Engine.
- Gewähren des Zugriffsbereichs cloud-platform oder eines anderen Bereichs, der Folgendes beinhaltet: Lesezugriff auf den Speicher.
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.
Um Bilder zu übertragen, interagieren Sie mit Repositories für andere Formate als Container oder gcloud-Befehle in Ihrem Cluster ausführen, müssen Sie Zugriffsbereiche für das Dienstkonto, wenn Sie den oder Knotenpools.
Falls Sie keine unterstützte Version von GKE, konfigurieren Sie imagePullSecrets.

Vom Nutzer bereitgestelltes Dienstkonto

Wenn Sie ein vom Nutzer bereitgestelltes Dienstkonto verwenden möchten als Identität für einen Cluster festlegen, müssen Sie:

Gewähren Sie dem Dienstkonto die erforderlichen Berechtigungen aus der Google Cloud-Projekt, 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 Parameter gcloud container clusters create oder gcloud container node-pools create-Befehl hinzufügen, müssen Sie die entsprechenden Zugriffsbereiche zur Verwendung mit Artifact Registry.

Zugriffsbereiche festlegen

Zugriffsbereiche sind die bisherige Methode, Compute Engine-VMs So rufen Sie Images aus Artifact Registry-Repositories ab: GKE-Knoten müssen den schreibgeschützten Speicherzugriffsbereich haben oder einen weiteren Speicherzugriffsbereich, der den Speicherlesezugriff umfasst.

Sie können Zugriffsbereiche nur beim Erstellen eines Clusters oder Knotenpools festlegen. Ich Zugriffsbereiche auf vorhandenen Knoten können nicht geändert werden.

Wenn Sie das Compute Engine-Standarddienstkonto verwenden, GKE erstellt Knoten mit der Compute Engine Standardzugriffsbereiche, einschließlich Lesezugriff auf Speicherplatz.
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 Bereiche, um auf Docker-Repositories zuzugreifen:
- storage-ro: Gewährt Lesezugriff auf 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
- Fü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.
Dienstkontoschlüssel herunterladen für das Dienstkonto.

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.
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)"
```
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 . 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