Zugriff auf Speicher-Buckets für Projekte gewähren und abrufen

Auf dieser Seite erfahren Sie, wie Sie den Zugriff auf Storage-Buckets in Google Distributed Cloud (GDC)-Projekten mit Air Gap verwalten, damit die richtigen Personen die richtigen Berechtigungen haben. Dabei werden die Voraussetzungen und Schritte zum Abrufen und Gewähren des Zugriffs für Nutzer und Dienstkonten mithilfe von Rollenbindungen und vordefinierten Rollen behandelt. Mit diesen Informationen können Sie den Zugriff auf Ihre Speicherressourcen effektiv steuern und sowohl die Sicherheit als auch die betriebliche Effizienz aufrechterhalten.

Diese Seite richtet sich an Zielgruppen wie IT-Administratoren in der Gruppe der Infrastrukturbetreiber oder Entwickler in der Gruppe der Anwendungsbetreiber, die die Zugriffseinstellungen für Storage-Buckets in GDC-Umgebungen mit Air Gap verwalten. Weitere Informationen finden Sie unter Dokumentation zu Zielgruppen für GDC mit Air Gap.

Hinweis

In einem Projekt-Namespace werden Bucket-Ressourcen auf dem Management API-Server verwaltet. Sie benötigen ein Projekt, um mit Buckets und Objekten zu arbeiten.

Bucket-Zugriff gewähren

Sie können den Zugriff auf S3 API-Ressourcen wie Buckets und Objekte in diesen Buckets für User- und ServiceAccount-Subjekte gewähren, indem Sie `RoleBinding`-Ressourcen erstellen und anwenden, die auf vordefinierte Rollen auf dem Management API-Server verweisen.

Hinweis: Group Subjekte werden nicht unterstützt, um S3 API-Berechtigungen zu gewähren. Wenn Sie ein Group Subjekt in einer RoleBinding-Ressource angeben, werden den Mitgliedern der Gruppe keine S3 API-Berechtigungen gewährt. Kubernetes API-Berechtigungen können jedoch weiterhin auf diese Weise auf Group Subjekte angewendet werden.

Hinweis: Der Gruppenzugriff wird vom System zur Zugriffssteuerung für Objekte nicht unterstützt. Es erkennt und verarbeitet nur Subjekte der Typen User oder ServiceAccount.

Vordefinierte Rollen

• project-bucket-object-viewer::Mit dieser Rolle kann ein Nutzer alle Buckets im Projekt und die Objekte in diesen Buckets auflisten sowie Objekte und Objektmetadaten lesen. Schreibvorgänge für Objekte sind nicht möglich. Beispiele: Hochladen, Überschreiben, Löschen. Hat Lesezugriff auf Buckets mit zwei Zonen in der Organisation und ihren Projekten sowie Lesezugriff auf die Objekte in diesen Buckets.

• project-bucket-object-admin::Mit dieser Rolle kann ein Nutzer alle Buckets im Projekt auflisten sowie Schreib- und Lesevorgänge für Objekte ausführen. Beispiele: Hochladen, Überschreiben, Löschen. Hat Lesezugriff auf Buckets mit zwei Zonen in der Organisation und ihren Projekten sowie Lese- und Schreibzugriff auf die Objekte in diesen Buckets.

• project-bucket-admin::Mit dieser Rolle können Nutzer alle Buckets im angegebenen Namespace sowie alle Objekte in diesen Buckets verwalten. Hat Lesezugriff auf Buckets mit zwei Zonen in der Organisation und ihren Projekten sowie Lese- und Schreibzugriff auf die Objekte in diesen Buckets.

Eine vollständige Liste der für die oben genannten Rollen gewährten Berechtigungen finden Sie im Abschnitt Berechtigungen für vordefinierte Rollen.

Sie benötigen die Rolle „Projekt-IAM-Administrator“ für das Projekt, um Rollenbindungen in diesem Projekt zu erstellen. Im Folgenden sehen Sie ein Beispiel für das Erstellen einer RoleBinding-Ressource, die einem Nutzer und einem Dienstkonto Zugriff gewährt:

1. Erstellen Sie auf Ihrem System eine YAML-Datei, z. B. rolebinding-object-admin-all-buckets.yaml.

   # Example file name:
   # rolebinding-object-admin-all-buckets.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     namespace: PROJECT_NAMESPACE
     name: readwrite-all-buckets
   roleRef:
     kind: Role
     name: project-bucket-object-admin
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: ServiceAccount
     namespace: PROJECT_NAMESPACE
     name: SA_NAME
   - kind: User
     namespace: PROJECT_NAMESPACE
     name: [e-mail]
     apiGroup: rbac.authorization.k8s.io
     # Could be bob or [e-mail] based on your organization settings.
   

   Ersetzen Sie Folgendes:

   • PROJECT_NAMESPACE: der Name des Projekt-Namespace
   • SA_NAME: der Name des Dienstkontos

2. Wenden Sie die YAML-Datei an:

   kubectl apply \
   -f rolebinding-object-admin-all-buckets.yaml
   

Anmeldedaten für den Bucket-Zugriff abrufen

Sobald Sie Zugriff auf einen Bucket gewähren, werden die Anmeldedaten in einem Secret erstellt.

Das Format des Secret-Namens ist object-storage-key-STORAGE_CLASS-SUBJECT_TYPE-SUBJECT_HASH.

• Mögliche Werte für STORAGE_CLASS:
  • std für die Speicherklasse Standard.
• Mögliche Werte für SUBJECT_TYPE:
  • user für Nutzer.
  • sa für Dienstkonto.
• SUBJECT_HASH ist der Base32-codierte SHA256-Hash des Subjektnamens.

Beispiel: Der Nutzer [e-mail] hat zwei Secrets mit den folgenden Namen:

1. object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja

Nutzerzugriff abrufen

Für ein Nutzersubjekt befindet sich das Secret im Namespace object-storage-access-keys auf dem Management API-Server.

1. Führen Sie den folgenden Befehl aus, um den Secret-Namen zu ermitteln:

   kubectl auth can-i --list --namespace object-storage-access-keys | grep "object-storage-key-"
   

   Die Ausgabe sieht in etwa so aus:

   secrets        []        [object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja]        [get]
   

2. Rufen Sie den Inhalt des entsprechenden Secrets ab, um auf Buckets in der Speicherklasse Standard zuzugreifen:

   kubectl get -o yaml --namespace object-storage-access-keys secret object-storage-key-std-user-oy6jdqd6bxfoqcecn2ozv6utepr5bgh355vfku7th5pmejqubdja
   

   Die Ausgabe sieht in etwa so aus:

   data:
     access-key-id: MEhYM08wWUMySjcyMkVKTFBKRU8=
     create-time: MjAyMi0wNy0yMiAwMTowODo1OS40MTQyMTE3MDMgKzAwMDAgVVRDIG09KzE5OTAuMzQ3OTE2MTc3
     secret-access-key: Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==
   

3. Decodieren Sie die Zugriffsschlüssel-ID und das Secret:

   echo "MEhYM08wWUMySjcyMkVKTFBKRU8=" | base64 -d \
       && echo \
       && echo "Ump0MVRleVN4SmhCSVJhbmlnVDAwbTJZc0IvRlJVendqR0JuYVhiVA==" | base64 -d
   

   Die Ausgabe sieht in etwa so aus:

   0HX3O0YC2J722EJLPJEO
   Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT
   

4. Folgen Sie der Anleitung unter gdcloud CLI konfigurieren und verwenden Sie dabei die Ergebnisse.

Zugriff für Dienstkonto abrufen

Die S3-Secret-Anmeldedaten werden nur erstellt und können nur abgerufen werden, wenn im Projekt-Namespace ein Bucket vorhanden ist.

Hinweis: Nutzer dürfen auf dem Management API-Server, auf dem die Secrets für den Zugriffsschlüssel des Dienstkontos ursprünglich erstellt wurden, keine Arbeitslasten ausführen, die als Dienstkonten ausgeführt werden. Nutzer können Arbeitslasten auf dem Management API-Server keinen Zugriff auf diese Secrets gewähren. Diese Secrets werden an die Projekt-Namespaces in den entsprechenden Nutzerclustern weitergegeben, wo Nutzer darauf zugreifen können (wenn sie die entsprechenden RBAC-Rollen in diesem Projekt haben).

Suchen Sie für ein Dienstkonto-Subjekt (Service Account, SA) den Secret-Namen im Nutzercluster.

1. Führen Sie für die Speicherklasse „Standard“ den folgenden Befehl aus, um den Secret-Namen abzurufen:

   kubectl get -n=<PROJECT-NAME> serviceaccount <SA-NAME> -o json | jq -r '.secrets[] | select(.name | test("object-storage-key-std"))'
   

2. Anschließend können Sie die aufgelisteten Secret-Namen manuell durchsuchen oder grep verwenden, um nach object-storage-key-(std|nl) zu suchen. Führen Sie für die zweite Option Folgendes aus:

   kubectl get -n=<PROJECT-NAME> serviceaccount <SA-NAME> -o=jsonpath='{.secrets}{"\n"}' | grep object-storage-key-(std|nl)
   

3. Sie können im Pod als Umgebungsvariablen oder Dateien auf das Secret verweisen.

Vordefinierte Rollenberechtigungen

Vordefinierte Rollen sind auf dem globalen API-Server für den administrativen und betrieblichen Zugriff auf Buckets mit zwei Zonen verfügbar. Diese Rollen gewähren auch Zugriff auf zonale Buckets, jedoch nur, wenn eine IAMRoleBinding-Ressource anstelle einer RoleBinding- oder ClusterRoleBinding-Ressource verwendet wird. Weitere Informationen zu Rollenbindungen finden Sie unter Zugriff gewähren und entziehen.

Berechtigungen für „project-bucket-object-viewer“

Diese Rolle gewährt Berechtigungen zum Abrufen und Auflisten von Objekten und Objektmetadaten im Bucket.

Die folgende Liste enthält alle Berechtigungen für den Objektspeicher, die die Rolle „project-bucket-object-viewer“ Role gewährt:

• Bucket API-Berechtigungen:

  1. get
  2. list
  3. Ansehen

• S3-Objektspeicherberechtigungen:

  1. GetObject
  2. GetObjectAcl
  3. GetObjectLegalHold
  4. GetObjectRetention
  5. GetObjectTagging
  6. GetObjectVersion
  7. GetObjectVersionTagging
  8. ListBucket
  9. ListBucketVersions
  10. ListBucketMultipartUploads
  11. ListMultipartUploadParts

Berechtigungen für „project-bucket-object-admin“

Diese Rolle gewährt Berechtigungen zum Einfügen und Löschen von Objekten sowie Objektversionen und -Tags im Bucket. Außerdem werden alle Berechtigungen in der Rolle project-bucket-object-viewer gewährt.

Die folgende Liste enthält alle zusätzlichen Berechtigungen für den Objektspeicher, die die Role gewährt, sind die folgenden:

• S3-Objektspeicherberechtigungen:

  1. AbortMultipartUpload
  2. DeleteObject
  3. DeleteObjectTagging
  4. DeleteObjectVersion
  5. DeleteObjectVersionTagging
  6. PutObject
  7. PutObjectTagging
  8. PutObjectVersionTagging
  9. PutOverwriteObject
  10. RestoreObject

Berechtigungen für „project-bucket-admin“

Diese Rolle gewährt Berechtigungen zum Erstellen, Aktualisieren oder Löschen von Bucket-Ressourcen im Projekt-Namespace. Außerdem werden alle Berechtigungen in der Rolle project-bucket-object-admin gewährt.

Die folgende Liste enthält die zusätzlichen Berechtigungen, die die Role gewährt:

• Bucket API-Berechtigungen:

  1. Erstellen
  2. Aktualisieren
  3. Delete