Zugriffssteuerung mit IAM

Auf dieser Seite werden Berechtigungen zur Zugriffssteuerung auf Container Registry beschrieben.

Nachdem Sie die Berechtigungen konfiguriert haben, können Sie die Authentifizierung für Docker-Clients konfigurieren, die Sie zum Übertragen von Images per Push und Pull verwenden.

Wenn Sie die Artefaktanalyse für die Arbeit mit Containermetadaten wie Sicherheitslücken in Images, siehe Dokumentation zur Artefaktanalyse .

Hinweis

Prüfen Sie, ob Sie die Berechtigungen zum Verwalten von Nutzern haben. Sie benötigen Berechtigungen in einer der folgenden Rollen:

  • Projekt-IAM-Administrator (roles/resourcemanager.projectIamAdmin)
  • Sicherheitsadministrator (roles/iam.securityAdmin)

Anstelle der Zuweisung dieser Rollen können Sie eine benutzerdefinierte Rolle oder eine vordefinierte Rolle mit denselben Berechtigungen verwenden.

Berechtigungen und Rollen

Alle Nutzer, Dienstkonten und andere Identitäten, die mit Container Registry interagieren, müssen die entsprechenden IAM-Berechtigungen (Identity and Access Management) für Cloud Storage-Speicher haben.

  • Google Cloud-Dienste, die normalerweise auf Container Registry zugreifen, werden mit Standardberechtigungen für Registries im selben Google Cloud-Projekt konfiguriert. Wenn die Standardberechtigungen nicht Ihren Anforderungen entsprechen, müssen Sie die entsprechenden Berechtigungen konfigurieren.
  • Für andere Identitäten müssen Sie die erforderlichen Berechtigungen konfigurieren.

Sie steuern den Zugriff auf Container Registry-Hosts mit Cloud Storage-Berechtigungen. In der folgenden Tabelle sind die Cloud Storage-Rollen aufgeführt, die über die für Container Registry erforderlichen Berechtigungen verfügen.

Beim Aufrufen von Container Registry sind einige zusätzliche Berechtigungen erforderlich mit der Google Cloud Console erstellen, siehe Allgemeine Berechtigungen, die für die Verwendung der Cloud Console erforderlich sind

Erforderlicher Zugriff Rolle Berechtigungen erteilen
Images (schreibgeschützt) aus einer vorhandenen Registry abrufen Storage-Objekt-Betrachter (roles/storage.objectViewer) Weisen Sie die Rolle für den Registry-Storage-Bucket zu.
Images auf einen vorhandenen Registry-Host in ein Projekt übertragen und daraus abrufen (lesen) Autor alter Storage-Buckets (roles/storage.legacyBucketWriter) Weisen Sie die Rolle für den Registry-Storage-Bucket zu. Diese Berechtigung ist nur auf Bucket-Ebene verfügbar und kann nicht auf Projektebene erteilt werden.
Fügen Sie Registry-Hosts zu Google Cloud-Projekten hinzu und erstellen Sie die zugehörigen Storage-Buckets. Storage-Administrator (roles/storage.admin) Rolle auf Projektebene zuweisen

Für das Hochladen von Images sind Lese- und Schreibberechtigungen für Objekte sowie die Berechtigung „storage.buckets.get“. Rolle „Autor alter Storage-Buckets“ enthält die erforderlichen Berechtigungen in einer einzelnen Cloud Storage-Rolle, aber gewährt keine vollständige Kontrolle über Storage-Buckets und -Objekte.

Die Rolle „Storage-Administrator“ gewährt vollständige Kontrolle über Speicher-Buckets und ‑Objekte. Wenn Sie diese Berechtigung auf Projektebene gewähren, hat das Hauptkonto Zugriff auf alle Speicher-Buckets im Projekt, einschließlich Buckets, die nicht von Container Registry verwendet werden. Überlegen Sie sorgfältig, für welche Hauptkonten diese Rolle erforderlich ist.

  • Das Cloud Build-Dienstkonto hat standardmäßig Berechtigungen in der Rolle "Storage-Administrator". Dieses Dienstkonto kann daher mit dem ersten Push- und Push-Push-Images zu vorhandenen Registries im übergeordneten Projekt Registries für das übergeordnete Projekt hinzufügen.
  • Wenn Sie Docker oder andere Tools zum Erstellen und Übertragen von Images in eine Registry verwenden, sollten Sie Ihrem Projekt Registries mit einem Konto mit der restriktiveren Rolle des Storage-Administrators hinzufügen und dann Storage Legacy Bucket-Autor oder zuweisen. Storage Object Viewer-Rollen an andere Konten, die Images übertragen oder abrufen müssen.

Weitere Informationen zu Cloud Storage-Rollen und -Berechtigungen finden Sie in der Dokumentation zu Cloud Storage.

IAM-Berechtigungen gewähren

Container Registry verwendet Cloud Storage-Buckets als zugrunde liegenden Speicher für Container-Images. Sie steuern den Zugriff auf Ihre Images, indem Sie dem Bucket Berechtigungen für eine Registry gewähren.

Der erste Image-Push zu einem Hostnamen fügt den Registry-Host und seinen Storage-Bucket einem Projekt hinzu. Durch den ersten Push in gcr.io/my-project wird beispielsweise der Registry-Host gcr.io dem Projekt mit der Projekt-ID my-project hinzugefügt und ein Speicher-Bucket für die Registry erstellt. Der Bucket-Name hat eines der folgenden Formate:

  • artifacts.PROJECT-ID.appspot.com für Images, die auf dem Host gcr.io gespeichert sind
  • STORAGE-REGION.artifacts.PROJECT-ID.appspot.com für Images, die auf anderen Registry-Hosts gespeichert sind

Damit dieser erste Image-Push erfolgreich durchgeführt werden kann, muss das Konto, das den Push-Vorgang ausführt, in der Rolle "Storage-Administrator" Berechtigungen haben.

Nach dem ersten Push des Images an einen Registry-Host erteilen Sie Berechtigungen für den Registry-Storage-Bucket, um den Zugriff auf Images in der Registry zu steuern:

  • Autor alter Storage-Buckets zum Übertragen und Abrufen
  • Nur Storage-Objekt-Betrachter

Berechtigungen für einen Bucket können Sie über die Google Cloud Console erteilen. oder die Google Cloud CLI.

Limits und Einschränkungen

Sie können Berechtigungen für Container Registry-Hosts nur auf Storage-Bucket-Ebene erteilen.

  • Berechtigungen für einzelne Objekte in einem Cloud Storage-Bucket werden ignoriert.
  • Sie können keine Berechtigungen für Repositories in einer Registry gewähren. Wenn Sie eine detailliertere Zugriffssteuerung benötigen, bietet Artifact Registry eine Zugriffssteuerung auf Repository-Ebene und ist möglicherweise besser auf Ihre Anforderungen abgestimmt.
  • Wenn Sie den einheitlichen Zugriff auf Bucket-Ebene für einen Container Registry-Storage-Bucket aktivieren, müssen Sie allen Nutzern und Dienstkonten, die auf Ihre Registrys zugreifen, explizit Berechtigungen erteilen. In diesem Fall erteilen die Inhaber- und Bearbeiterrolle möglicherweise nicht die erforderlichen Berechtigungen.

Berechtigungen erteilen

  1. Wenn der Registry-Host noch nicht im Projekt vorhanden ist, muss ein Konto mit Berechtigungen in der Rolle "Storage-Administrator" das erste Image in die Registry übertragen. Dadurch wird der Storage-Bucket für den Registry-Host erstellt.

    Cloud Build hat die erforderlichen Berechtigungen zum Ausführen des ersten Image-Push-Vorgangs im selben Projekt. Wenn Sie Images mit einem anderen Tool hochladen, prüfen Sie die Berechtigungen für das Google Cloud-Konto, mit dem Sie sich bei Container Registry authentifizieren.

    Weitere Informationen zum Hochladen des ersten Images mit Docker finden Sie unter Registry hinzufügen.

  2. Erteilen Sie im Projekt mit Container Registry die entsprechenden Berechtigungen für den Cloud Storage-Bucket, der vom Registry-Host verwendet wird.

    Console

    1. Rufen Sie in der Google Cloud Console die Seite „Cloud Storage“ auf.
    2. Klicken Sie auf den Link artifacts.PROJECT-ID.appspot.com oder STORAGE-REGION.artifacts.PROJECT-ID.appspot.com für den Bucket.

      Ersetzen Sie PROJECT-ID durch die Google Cloud-Projekt-ID des Projekts, das Container Registry hostet, und STORAGE-REGION durch die Multiregion (asia, eu, oder us) der Registry, die das Image hostet.

    3. Wählen Sie den Tab Berechtigungen.

    4. Klicken Sie auf Add.

    5. Geben Sie im Feld Hauptkonten die E-Mail-Adressen der Konten, die Zugriff benötigen, durch Kommas getrennt ein. Die E-Mail-Adresse kann mit Folgendem verknüpft sein:

      • ein Google-Konto, (z. B. someone@example.com)
      • eine Google-Gruppe (z. B. my-developer-team@googlegroups.com)
      • ein IAM-Dienstkonto

        In der Liste der Google Cloud-Dienste, die in der Regel auf Registrys zugreifen, ist die E-Mail-Adresse des zugehörigen Dienstkontos enthalten. Wenn der Dienst in einem anderen Projekt als Container Registry ausgeführt wird, achten Sie darauf, dass Sie die E-Mail-Adresse des Dienstkontos im anderen Projekt verwenden.

    6. Wählen Sie im Drop-down-Menü Rolle auswählen die Kategorie Cloud Storage und dann die entsprechende Berechtigung aus.

      • Storage-Objekt-Betrachter, um nur Images herunterzuladen
      • Autor von Legacy-Storage-Buckets zum Übertragen und Abrufen von Images
    7. Klicken Sie auf Add.

    gcloud

    1. Führen Sie den folgenden Befehl aus, um Buckets im Projekt aufzulisten:

      gcloud storage ls
      

      Die Antwort sieht in etwa so aus:

      gs://[BUCKET_NAME1]/
      gs://[BUCKET_NAME2]/
      gs://[BUCKET_NAME3]/ ...
      

      Suchen Sie den Bucket für den Registry-Host in der Liste der zurückgegebenen Buckets. Der Bucket, in dem Ihre Images gespeichert sind, hat den Namen BUCKET-NAME in einem der folgenden Formate:

      • artifacts.PROJECT-ID.appspot.com für Images, die auf dem Host gcr.io gespeichert sind
      • STORAGE-REGION.artifacts.PROJECT-ID.appspot.com für Images, die auf anderen Registry-Hosts gespeichert sind

      Dabei gilt:

      • PROJECT-ID ist Ihre Google Cloud-Projekt-ID.
      • STORAGE-REGION ist der Speicherort des Storage-Buckets:
        • us für Registries im Host us.gcr.io
        • eu für Registrys im Host eu.gcr.io
        • asia für Registrys im Host asia.gcr.io
    2. Führen Sie den folgenden Befehl in der Shell oder im Terminalfenster aus:

      gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
      --member=TYPE:EMAIL-ADDRESS \
      --role=ROLE
      

      Dabei gilt:

      • BUCKET_NAME ist der Name des Cloud Storage-Buckets im Format artifacts.PROJECT-ID.appspot.com oder STORAGE-REGION.artifacts.PROJECT-ID.appspot.com
      • TYPE kann eines der Folgenden sein:
        • serviceAccount, wenn EMAIL-ADDRESS ein Dienstkonto angibt.
        • user, wenn die EMAIL-ADDRESS ein Google-Konto ist.
        • group, wenn EMAIL-ADDRESS eine Google-Gruppe ist.
      • EMAIL-ADDRESS kann eines der Folgenden sein:

        • ein Google-Konto, (z. B. someone@example.com)
        • eine Google-Gruppe (z. B. my-developer-team@googlegroups.com)
        • ein IAM-Dienstkonto

          In der Liste der Google Cloud-Dienste, die in der Regel auf Registrys zugreifen, ist die E-Mail-Adresse des zugehörigen Dienstkontos enthalten. Wenn der Dienst in einem anderen Projekt als Container Registry ausgeführt wird, achten Sie darauf, dass Sie die E-Mail-Adresse des Dienstkontos im anderen Projekt verwenden.

      • ROLE ist die Cloud Storage-Rolle, die Sie zuweisen möchten.

        • objectViewer, um Images herunterzuladen
        • legacyBucketWriter Images hoch- und herunterladen

    Dieser Befehl gewährt dem Dienstkonto my-account@my-project.iam.gserviceaccount.com beispielsweise Berechtigungen zum Hoch- und Herunterladen von Images in den Bucket my-example-bucket:

    gcloud storage buckets add-iam-policy-binding gs://my-example-bucket \
      --member=serviceAccount:my-account@my-project.iam.gserviceaccount.com \
      --role=roles/storage.objectUser
    

    Mit dem Befehl gcloud storage buckets add-iam-policy-binding ändern Sie die IAM-Berechtigungen des Storage-Buckets, in dem die Registry gehostet wird. Weitere Beispiele sind in der Dokumentation zur gcloud CLI.

  3. Wenn Sie den Zugriff für Compute Engine-VMs oder GKE-Knoten konfigurieren, die Images in Container Registry übertragen, finden Sie unter VMs und Cluster konfigurieren weitere Konfigurationsschritte.

Öffentlichen Zugriff auf Images konfigurieren

Container Registry ist öffentlich zugänglich, wenn der dem Hoststandort zugrunde liegende Storage-Bucket öffentlich zugänglich ist. Innerhalb eines Projekts sind alle Images an jedem Hoststandort entweder öffentlich oder nicht. Innerhalb des Hosts eines Projekts ist es nicht möglich, nur bestimmte Images öffentlich bereitzustellen. Wenn Sie bestimmte Images öffentlich zugänglich machen möchten:

  • legen Sie diese an einem eigenen Hoststandort ab, den Sie öffentlich freigeben, oder
  • Erstellen Sie ein neues Projekt für öffentlich zugängliche Images.

So machen Sie den zugrunde liegenden Storage-Bucket öffentlich zugänglich, um Container-Images öffentlich bereitzustellen:

  1. Prüfen Sie, ob ein Image per Push an Container Registry übertragen wurde und der zugrunde liegende Storage-Bucket vorhanden ist.

  2. Suchen Sie den Namen des Cloud Storage-Buckets für diese Registry. Listen Sie dazu die Buckets auf:

    gcloud storage ls
    

    Die URL des Container Registry-Buckets wird als gs://artifacts.PROJECT-ID.appspot.com oder gs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com aufgeführt. Dabei gilt:

    • PROJECT-ID ist Ihre Google Cloud-Projekt-ID. Auf eine Domain beschränkte Projekte enthalten den Domainnamen in der Projekt-ID.
    • STORAGE-REGION ist der Speicherort des Storage-Buckets:
      • us für Registries im Host us.gcr.io
      • eu für Registrys im Host eu.gcr.io
      • asia für Registrys im Host asia.gcr.io
  3. Machen Sie den Storage-Bucket von Container Registry mit dem folgenden Befehl öffentlich zugänglich. Dadurch werden alle Images in der Registry öffentlich zugänglich.

    gcloud storage buckets add-iam-policy-binding gs://BUCKET-NAME \
        --member=allUsers --role=roles/storage.objectViewer
    

    Dabei gilt:

    • gs://BUCKET-NAME ist die URL des Container Registry-Buckets.

Öffentlichen Zugriff auf Images entfernen

Console

  1. Prüfen Sie, ob ein Image per Push an Container Registry übertragen wurde und der zugrunde liegende Storage-Bucket vorhanden ist.

  2. Öffnen Sie in der Google Cloud Console die Seite Container Registry.

    Seite "Container Registry" öffnen

  3. Klicken Sie im linken Bereich auf Einstellungen.

  4. Ändern Sie die Sichtbarkeit unter Öffentlicher Zugriff auf der Seite Einstellungen zu Privat. Diese Einstellung steuert den Zugriff auf den zugrunde liegenden Storage-Bucket.

gcloud-Speicher

  1. Suchen Sie den Namen des Cloud Storage-Buckets für diese Registry. Listen Sie dazu die Buckets auf:

    gcloud storage ls
    

    Die URL des Container Registry-Buckets wird als gs://artifacts.PROJECT-ID.appspot.com oder gs://STORAGE-REGION.artifacts.PROJECT-ID.appspot.com aufgeführt. Dabei gilt:

    • PROJECT-ID ist Ihre Projekt-ID in der Google Cloud Console. Auf eine Domain beschränkte Projekte enthalten den Domainnamen in der Projekt-ID.
    • STORAGE-REGION ist der Speicherort des Storage-Buckets:
      • us für Registries im Host us.gcr.io
      • eu für Registrys im Host eu.gcr.io
      • asia für Registrys im Host asia.gcr.io
  2. Führen Sie den folgenden Befehl aus, um den öffentlichen Zugriff auf Ihren Storage-Bucket zu entfernen im Shell- oder Terminalfenster:

    gcloud storage bucket remove-iam-policy-binding gs://BUCKET-NAME \
      --member=allUsers --role=roles/storage.objectViewer
    

Dabei gilt:

  • BUCKET-NAME ist der Name des jeweiligen Buckets.

Berechtigungen widerrufen

Führen Sie die folgenden Schritte aus, um IAM-Berechtigungen aufzuheben.

Console

  1. Rufen Sie in der Google Cloud Console die Seite „Cloud Storage“ auf.
  2. Klicken Sie auf den Link artifacts.PROJECT-ID.appspot.com oder STORAGE-REGION.artifacts.PROJECT-ID.appspot.com für den Bucket. Hier ist PROJECT-ID die Google Cloud-Projekt-ID des Projekts, das Container Registry hostet, und STORAGE-REGION ist die Mehrfachregion (asia, eu, oder us) der Registry, in der das Image gehostet wird.

  3. Wählen Sie den Tab Berechtigungen.

  4. Klicken Sie auf das Papierkorbsymbol neben jedem Hauptkonto, das Sie entfernen möchten.

gcloud

Führen Sie den folgenden Befehl in der Shell oder im Terminalfenster aus:

gcloud storage bucket remove-iam-policy-binding gs://BUCKET-NAME \
    --member=PRINCIPAL --all

Dabei gilt:

  • BUCKET-NAME ist der Name des jeweiligen Buckets.
  • PRINCIPAL kann eines der Folgenden sein:
    • user:EMAIL-ADDRESS für ein Google-Konto
    • serviceAccount:EMAIL-ADDRESS für ein IAM-Dienstkonto
    • group:EMAIL-ADDRESS für eine Google-Gruppe
    • allUsers für den Widerruf des öffentlichen Zugriffs

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 Container 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 von der VM in eine Registry hochladen möchten, müssen Sie die Berechtigungen für das VM-Dienstkonto ändern oder sich mit einem Konto bei der Registry authentifizieren, das über Schreibzugriff auf den Speicher verfügt.
  • Sie verwenden ein benutzerdefiniertes Dienstkonto für die Interaktion mit Container Registry.

Die folgenden Dienstkonten greifen normalerweise auf Container Registry zu. Die E-Mail-Adresse für das Dienstkonto enthält die Projekt-ID oder Projektnummer des Google Cloud-Projekts des Projekts, in dem der Dienst ausgeführt wird.

Dienst Dienstkonto E-Mail-Adresse Berechtigungen
Flexible App Engine-Umgebung App Engine-Standarddienstkonto PROJECT-ID@appspot.gserviceaccount.com Bearbeiterrolle, kann in den Speicher lesen und schreiben
Compute Engine Standardmäßiges Compute Engine-Dienstkonto PROJECT-NUMBER-compute@developer.gserviceaccount.com Bearbeiterrolle, auf Lesezugriff beschränkt
Cloud Build Cloud Build-Dienstkonto PROJECT-NUMBER@cloudbuild.gserviceaccount.com Standardberechtigungen umfassen das Erstellen von Storage-Buckets sowie Lese- und Schreibzugriff auf den Speicher.
Cloud Run Compute Engine-Standarddienstkonto
Das Standardlaufzeitdienstkonto für Überarbeitungen.
PROJECT-NUMBER-compute@developer.gserviceaccount.com Bearbeiterrolle, auf Lesezugriff beschränkt
GKE Compute Engine-Standarddienstkonto
Das Standarddienstkonto für Knoten.
PROJECT-NUMBER-compute@developer.gserviceaccount.com Bearbeiterrolle, auf Lesezugriff beschränkt

VMs und Cluster für die Übertragung von Images konfigurieren

Compute Engine und jeder Google Cloud-Dienst, der Compute Engine verwendet, hat das Compute Engine-Standarddienstkonto als Standardidentität.

Sowohl IAM-Berechtigungen als auch Zugriffsbereiche wirken sich auf die Lese- und Schreibvorgänge von VMs im Speicher aus.

  • IAM-Berechtigungen bestimmen den Zugriff auf Ressourcen.
  • Mit Zugriffsbereichen werden die standardmäßigen OAuth-Bereiche für Anfragen festgelegt, die auf der VM-Instanz über die gcloud CLI und Clientbibliotheken erfolgen. 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.
    • Zum Herunterladen eines privaten Images muss das VM-Dienstkonto die Berechtigung read für den Storage-Bucket des Images haben.
    • Zum Hochladen privater Images muss das VM-Dienstkonto den Zugriffsbereich read-write, cloud-platform oder full-control für den Storage-Bucket des Images haben.

Das Compute Engine-Standarddienstkonto hat standardmäßig die Bearbeiterrolle, die Berechtigungen zum Erstellen und Aktualisieren von Ressourcen für die meisten Google Cloud-Dienste enthält. Sowohl für das Standarddienstkonto als auch für ein benutzerdefiniertes Dienstkonto, das Sie einer VM zuordnen, ist der Standardzugriffsbereich für Storage-Buckets jedoch schreibgeschützt. Das bedeutet, dass VMs standardmäßig keine Images übertragen können.

Wenn Sie nur Images in Umgebungen wie Compute Engine und GKE bereitstellen möchten, müssen Sie den Zugriffsbereich nicht ändern. Wenn Sie in diesen Umgebungen Anwendungen ausführen möchten, die Images in die Registry übertragen, müssen Sie zusätzliche Konfigurationen vornehmen.

Die folgenden Konfigurationen erfordern Änderungen an IAM-Berechtigungen oder des Zugriffsbereichs.

Images von einer VM oder einem Cluster herunterladen
Wenn Sie Images per Push übertragen möchten, muss das Dienstkonto der VM-Instanz den Bereich storage-rw anstelle von storage-ro haben.
Die VM und die Container Registry befinden sich in separaten Projekten
Sie müssen dem Dienstkonto IAM Berechtigungen zum Zugriff auf den von Container Registry verwendeten Storage-Bucket erteilen.
gcloud-Befehle auf VMs ausführen
Das Dienstkonto muss den Bereich cloud-platform haben. Dieser Bereich gewährt Berechtigungen zum Hoch- und Herunterladen von Images sowie zum Ausführen von gcloud-Befehlen.

Die Schritte zum Konfigurieren von Bereichen finden Sie in den folgenden Abschnitten.

Bereiche für VMs konfigurieren

Verwenden Sie die Option --scopes, um beim Erstellen einer VM Zugriffsbereiche festzulegen.

gcloud compute instances create INSTANCE --scopes=SCOPE

Dabei gilt:

  • INSTANCE ist der Name der VM-Instanz.
  • SCOPE ist der Bereich, den Sie für das VM-Dienstkonto konfigurieren möchten:
    • Images abrufen: storage-ro
    • Images per Pull und Push übertragen: storage-rw
    • Images hoch- und herunterladen und gcloud-Befehle ausführen: cloud-platform

So ändern Sie Bereiche für eine vorhandene VM-Instanz:

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
    

    Dabei gilt:

    • INSTANCE ist der Name der VM-Instanz.
    • SCOPE ist der Bereich, den Sie für das VM-Dienstkonto konfigurieren möchten:
      • Images abrufen: storage-ro
      • Images per Pull und Push übertragen: storage-rw
      • Images hoch- und herunterladen und gcloud-Befehle ausführen: cloud-platform
  3. Starten Sie die VM-Instanz neu. Siehe Beendete Instanz starten.

Wenn Sie anstelle des Standarddienstkontos ein benutzerdefiniertes Dienstkonto für VMs verwenden möchten, können Sie das Dienstkonto und die Zugriffsbereiche angeben, die beim Erstellen der VM oder Ändern der VM-Einstellungen verwendet werden sollen.

Bereiche für Google Kubernetes Engine-Cluster konfigurieren

Standardmäßig werden neue GKE-Cluster mit Leseberechtigungen für Cloud Storage-Buckets erstellt.

Wenn Sie beim Erstellen eines Google Kubernetes Engine-Clusters den read-write-Speicherbereich festlegen möchten, verwenden Sie die Option --scopes. Der folgende Befehl erstellt beispielsweise einen Cluster mit den Bereichen bigquery, storage-rw und compute-ro:

gcloud container clusters create example-cluster \
--scopes=bigquery,storage-rw,compute-ro

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.

Das Container Registry-Dienstkonto

Der Container Registry-Dienst-Agent handelt im Namen von Container Registry. Dienst hat der Agent die mindestens erforderlichen Berechtigungen, wenn Sie den Container Registry API nach dem 5. Oktober 2020. Der Dienst-Agent zuvor hatte die Rolle Bearbeiter. Weitere Informationen zum Dienst-Agent und zum Ändern seiner Berechtigungen finden Sie unter Container Registry-Dienstkonto.

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie einfach ein Konto, um die Leistungsfähigkeit von Container Registry in der Praxis prüfen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Container Registry kostenlos testen