Zugriffssteuerung konfigurieren

Auf dieser Seite wird beschrieben, wie Sie Artifact Registry-Repositories gewähren.

Hinweis

Aktivieren Sie Artifact Registry. Dazu gehört auch die Aktivierung der API und die Installation des Cloud SDK.
Erstellen Sie die Repositories für Ihre Pakete, wenn Sie Repository-spezifische Berechtigungen anwenden möchten.

Übersicht

Artifact Registry ist vollständig in Google Cloud-Dienste eingebunden, um eine CI/CD-Pipeline mit Standardberechtigungen zu implementieren, die die Einrichtung vereinfachen. 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 Container Analysis für die Arbeit mit Containermetadaten verwenden, z. B. gefundene Sicherheitslücken-Images, lesen Sie die Container Analysis-Dokumentation für Informationen dazu, wie Sie Zugriff zum Aufrufen oder Verwalten von Metadaten gewähren können.

Google Cloud-Integration

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. Gewähren Sie im Projekt mit Artifact Registry dem Dienstkonto für jeden Dienst die erforderliche Rolle.
Sie eine GKE-Version verwenden, 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 für Ihre Laufzeitumgebungen ein benutzerdefiniertes Dienstkonto anstelle des Standarddienstkontos verwenden. Weisen Sie Ihrem Dienstkonto im Projekt mit Artifact Registry die erforderliche Rolle zu.

Integration von Drittanbietern

Für Drittanbieterclients müssen Sie sowohl Berechtigungen als auch die Authentifizierung konfigurieren.

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 Drittanbieterclient für die Authentifizierung bei Artifact Registry.
- Container-Images: Docker, Helm
- Sprachpakete: Java, Node.js, Python
- Betriebssystempakete (Vorschau): Debian, RPM

Rollen und Berechtigungen

Erteilen Sie eine IAM-Berechtigung (Identity and Access Management), indem Sie eine Rolle zuweisen, die die Berechtigung enthält. Verwenden Sie die Artifact Registry-Rollen, um den Zugriff auf Ihre Repositories zu steuern. Sie können Berechtigungen auf Projekt- oder Repository-Ebene erteilen.

Sie können zwar die grundlegenden Rollen Owner, Editor und Viewer verwenden, um Zugriff auf Repositories zu gewähren, aber mit den Artifact Registry-Rollen können Sie das Sicherheitsprinzip der geringsten Berechtigung anwenden, damit Nutzer und Dienstkonten nur die notwendigen Berechtigungen haben.

Artifact Registry-Berechtigungen

In der folgenden Tabelle sind die IAM-Rollen von Artifact Registry und deren Berechtigungen aufgeführt:

Rolle	Beschreibung	Berechtigungen
`roles/artifactregistry.reader`	Artifact Registry-Leser Artefakte ansehen und abrufen	`artifactregistry.repositories.list` `artifactregistry.repositories.get` `artifactregistry.repositories.downloadArtifacts` `artifactregistry.files.list` `artifactregistry.files.get` `artifactregistry.packages.list` `artifactregistry.packages.get` `artifactregistry.tags.list` `artifactregistry.tags.get` `artifactregistry.versions.list` `artifactregistry.versions.get`
`roles/artifactregistry.writer`	Artifact Registry-Autor Artefakte lesen und schreiben	Alle `roles/artifactregistry.reader`-Berechtigungen und: `artifactregistry.repositories.uploadArtifacts` `artifactregistry.tags.create` `artifactregistry.tags.update`
`roles/artifactregistry.repoAdmin`	Repository-Administrator für Artifact Registry Artefakte lesen, schreiben und löschen	Alle `roles/artifactregistry.writer`-Berechtigungen und: `artifactregistry.repositories.deleteArtifacts` `artifactregistry.packages.delete` `artifactregistry.projectsettings.update` `artifactregistry.tags.delete` `artifactregistry.versions.delete`
`roles/artifactregistry.admin`	Artifact Registry-Administrator Repositories und Artefakte erstellen und verwalten	Alle `roles/artifactregistry.repoAdmin`-Berechtigungen und: `artifactregistry.repositories.create` `artifactregistry.repositories.update` `artifactregistry.repositories.delete` `artifactregistry.repositories.getIamPolicy` `artifactregistry.repositories.setIamPolicy`

In der folgenden Tabelle sind die einfachen Rollen aufgelistet, die es bereits vor IAM gab, sowie die Artifact Registry-IAM-Rollen:

Rolle	Rollentitel	Umfasst die Rolle
`roles/viewer`	Betrachter	`roles/artifactregistry.reader`
`roles/editor`	Bearbeiter	`roles/artifactregistry.writer`
`roles/owner`	Inhaber	`roles/artifactregistry.repoAdmin` `roles/artifactregistry.admin`

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 Rollen mit dem Befehl gcloud zuweisen, können Sie eine einzelne Rollenbindung für ein Mitglied angeben oder eine Richtliniendatei verwenden, um mehrere Bindungen zu definieren.

Die folgende Referenzrichtlinienvorlage wird für die Beispiele auf dieser Seite verwendet. Die Referenzrichtliniendatei hat den Namen policy.yaml. Die Vorlage enthält Beispielnutzer- und Dienstkontonamen. Ersetzen Sie diese Beispielbenutzer und Dienstkonten entsprechend Ihrem Projekt.

Weitere Informationen zum Richtlinienformat finden Sie in der Dokumentation zu IAM-Richtlinien.

bindings:

- members:
  - user: user@gmail.com
  role: roles/owner

- members:
  - serviceAccount: repo-readonly@iam.gserviceaccount.com
  - user: user2@gmail.com
  role: roles/artifactregistry.reader

- members:
  - serviceAccount: repo-write@iam.gserviceaccount.com
  role: roles/artifactregistry.writer

- members:
  - serviceAccount: repo-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.repoAdmin

- members:
  - serviceAccount: ar-admin@iam.gserviceaccount.com
  role: roles/artifactregistry.admin

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 Teammitglied hinzu und weisen ihm eine Artifact Registry-Rolle zu:

Console

Öffnen Sie in der 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 Mitglieder hinzufügen. Zur Verwendung von Alphafeatures in der Cloud Console müssen sich die Mitglieder in der Alphanutzergruppe ar-trusted-testers@googlegroups.com befinden.
Wählen Sie eine Rolle für das Mitglied aus. Gemäß dem Sicherheitsprinzip der geringsten Berechtigung sollten Sie die geringstmögliche Berechtigung einräumen, um unerwünschten Zugriff auf andere Ressourcen zu verhindern.
Klicken Sie auf Speichern.

gcloud

Führen Sie den folgenden Befehl aus, um einem einzelnen Mitglied eine Rolle zuzuweisen:

gcloud projects add-iam-policy-binding PROJECT --member=MEMBER --role=ROLE

Dabei gilt:

PROJECT ist die ID des Projekts, in dem Artifact Registry ausgeführt wird.
MEMBER 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.

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 im Tab Berechtigungen auf Mitglied hinzufügen.
Geben Sie eine E-Mail-Adresse ein. Sie können Einzelpersonen, Dienstkonten oder Google Groups als Mitglieder hinzufügen. Zur Verwendung von Alphafeatures in der Cloud Console müssen sich die Mitglieder in der Alphanutzergruppe ar-trusted-testers@googlegroups.com befinden.
Wählen Sie eine Rolle für das Mitglied aus. Wir empfehlen, Mitgliedern immer nur die niedrigsten Berechtigungen zu erteilen, die sie für ihre Aufgaben benötigen.
Klicken Sie auf Speichern.

gcloud

Sie können IAM-Sets einzelner Richtlinienbindungen festlegen oder eine Richtliniendatei verwenden.

Führen Sie den folgenden Befehl aus, um einem einzelnen Mitglied eine Rolle zuzuweisen:

gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
--location LOCATION --member=MEMBER --role=ROLE

Dabei gilt:

REPOSITORY ist die ID des Repositorys.
MEMBER 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

Terraform

Informationen zum Verwenden von Terraform für das Bereitstellen von Repositories und für das Gewähren von Repository-Berechtigungen finden Sie unter In Terraform einbinden.

Ö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 Mitglied die Rolle „Artifact Registry-Leser” zuallUsers, um die Option zu aktivieren. Außerdem empfehlen wir, Nutzeranfragekontingente zu begrenzen, damit ein Nutzer das Gesamtkontingent Ihres Projekts nicht ausschöpfen 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 im Tab Berechtigungen auf Mitglied hinzufügen.
Geben Sie im Feld Neue Mitglieder 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 Missbrauch durch nicht authentifizierte Nutzer zu verhindern. Eine Anleitung finden Sie unter Nutzung einschränken.

gcloud

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.
- MEMBER 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.
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 Missbrauch durch nicht authentifizierte Nutzer zu verhindern. Eine Anleitung finden Sie unter Nutzung einschränken.

Berechtigungen aufheben

Wenn Sie den Zugriff auf ein Repository widerrufen möchten, entfernen Sie das Mitglied aus der Liste der autorisierten Mitglieder.

Entfernen Sie das Mitglied 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 Mitglied. Wenn Sie ein öffentliches Repository privat machen, maximieren Sie das Mitglied allUsers.
Klicken Sie auf Mitglied entfernen, um den Zugriff zu widerrufen.

gcloud

Führen Sie den folgenden Befehl aus, um eine Rolle auf Projektebene zu widerrufen:

gcloud projects remove-iam-policy-binding PROJECT --member=MEMBER --role=ROLE

PROJECT ist die Projekt-ID.
MEMBER 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 --member=MEMBER --role=ROLE

Dabei gilt:

REPOSITORY ist die ID des Repositorys.
MEMBER 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 Mitglied 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-policy-binding my-repo \
 --location=us-central1 --member=user:write@gmail.com --role=roles/artifactregistry.writer

Führen Sie folgenden Befehl aus, um den Zugriff auf my-repo für den Standort --us-central1 zu widerrufen:

gcloud artifacts repositories remove-policy-binding my-repo \
 --location=us-central1 --member=allUsers --role=roles/artifactregistry.reader

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 das gcloud-Tool und die Client-Bibliotheken 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.

Standardmäßig verfügt das Compute Engine-Standarddienstkonto über die Berechtigung "Bearbeiter" für Ressourcen im selben Projekt und den Speicherzugriffsbereich read-only. Die E-Mail-Adresse des Dienstkontos hat das Suffix @developer.gserviceaccount.com.

Während die Bearbeiterberechtigungen in der Regel Schreibzugriff gewähren, beschränkt der Zugriffsbereich read-only 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 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 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.
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 benutzerdefiniertes Dienstkonto als Identität für die Knoten verwenden.

Standarddienstkonto

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

Zum Übertragen von Images, zur Interaktion mit Repositories für andere Formate als Container oder zum Ausführen von gcloud-Befehlen in Ihrem Cluster müssen Sie beim Erstellen des Clusters Zugriffsbereiche für das Dienstkonto festlegen.
Befindet sich GKE in einem anderen Projekt als Artifact Registry, gewähren Sie dem Dienstkonto die erforderlichen Berechtigungen.
Wenn Sie keine unterstützte Version von GKE verwenden, konfigurieren Sie imagePullSecrets.

Zugriffsbereiche festlegen

Führen Sie den folgenden Befehl aus, um beim Erstellen eines Clusters einen Zugriffsbereich festzulegen:

gcloud container clusters create CLUSTER-NAME --scopes=SCOPE

Dabei gilt:

CLUSTER-NAME ist der Name des Clusters. SCOPE ist ein Bereich, der Ihren Anforderungen entspricht:

Wählen Sie für Docker-Repositories eine der folgenden Optionen aus:
- 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
Für andere Repositories müssen Sie den Bereich cloud-platform verwenden.

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

Benutzerdefiniertes Dienstkonto konfigurieren

Bei Clustern, die ein benutzerdefiniertes Dienstkonto als Identität verwenden, müssen Sie dem Dienstkonto die erforderlichen Berechtigungen aus dem Google Cloud-Projekt erteilen, in dem Artifact Registry ausgeführt wird.

Artifact Registry-Dienstkonto

Der Artifact Registry-Dienst-Agent ist ein von Google verwaltetes Dienstkonto, das bei der Interaktion mit Google Cloud-Diensten im Auftrag von Artifact Registry agiert. Weitere Informationen zum 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
Sprachpakete: Java, Node.js, Python
Betriebssystempakete (Vorschau): Debian, RPM