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

Auf dieser Seite wird beschrieben, wie Sie den Zugriff auf Storage-Buckets in Google Distributed Cloud (GDC) mit Air Gap-Projekten verwalten, damit die richtigen Personen die richtigen Berechtigungen haben. Es 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 IT-Administratoren in der Gruppe der Infrastrukturbetreiber oder Entwickler in der Gruppe der Anwendungsoperatoren, die Zugriffseinstellungen für Storage-Buckets in GDC-Umgebungen mit Air Gap verwalten. Weitere Informationen finden Sie unter Zielgruppen für die Dokumentation zu GDC mit Air Gap.

Hinweis

Ein Projekt-Namespace verwaltet Bucket-Ressourcen im Management API-Server. Sie benötigen ein Projekt, um mit Buckets und Objekten arbeiten zu können.

Bucket-Zugriff gewähren

Sie können User- und ServiceAccount-Subjekten Zugriff auf S3 API-Ressourcen wie Buckets und Objekte in diesen Buckets gewähren, indem Sie RoleBindings erstellen und anwenden, die auf vordefinierte Rollen im Management API-Server verweisen.

Hinweis: Group-Subjekte werden für die Erteilung von S3 API-Berechtigungen nicht unterstützt. Wenn Sie ein Group-Subjekt in einer RoleBinding 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 Objektzugriffssteuerung nicht unterstützt. Es werden nur Subjekte vom Typ User oder ServiceAccount erkannt und verarbeitet.

Vordefinierte Rollen

• project-bucket-object-viewer: Damit kann ein Nutzer alle Buckets im Projekt auflisten, Objekte in diesen Buckets auflisten und Objekte und Objektmetadaten lesen. Sie können damit keine Schreibvorgänge für Objekte ausführen. Beispiele: Hochladen, Überschreiben, Löschen. Hat Lesezugriff auf Dual-Region-Buckets innerhalb der Organisation und ihrer Projekte sowie Lesezugriff auf die Objekte in diesen Buckets.

• project-bucket-object-admin: Damit kann ein Nutzer alle Buckets im Projekt auflisten und Schreib- und Lesevorgänge für Objekte ausführen. Beispiele: Hochladen, Überschreiben, Löschen. Hat Lesezugriff auf Dual-Region-Buckets innerhalb der Organisation und ihrer Projekte sowie Lese-/Schreibzugriff auf die Objekte in diesen Buckets.

• project-bucket-admin: Damit können Nutzer alle Buckets im angegebenen Namespace sowie alle Objekte in diesen Buckets verwalten. Hat Lesezugriff auf Dual-Region-Buckets innerhalb der Organisation und ihrer Projekte sowie Lese-/Schreibzugriff auf die Objekte in diesen Buckets.

Eine vollständige Liste der Berechtigungen, die für die vorherigen Rollen gewährt wurden, finden Sie im Abschnitt Berechtigungen für vordefinierte Rollen.

Sie benötigen die Rolle „IAM-Projektadministrator“ für das Projekt, um Rollenbindungen in diesem Projekt zu erstellen. Im Folgenden finden 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 Zugangsdaten in einem Secret erstellt.

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

• Werte für STORAGE_CLASS sind:
  • std für die Speicherklasse Standard.
• Werte für SUBJECT_TYPE sind:
  • user für Nutzer.
  • sa für ServiceAccount.
• SUBJECT_HASH ist der Base32-codierte SHA256-Hash des Antragstellernamens.

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

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

Nutzerzugriff erhalten

Bei einem Nutzerobjekt 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 Namen des Secrets zu ermitteln:

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

   Die Ausgabe sollte in etwa so aussehen:

   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 sollte in etwa so aussehen:

   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 sollte in etwa so aussehen:

   0HX3O0YC2J722EJLPJEO
   Rjt1TeySxJhBIRanigT00m2YsB/FRUzwjGBnaXbT
   

4. Folgen Sie dem Abschnitt gdcloud CLI konfigurieren mit den resultierenden Informationen.

Zugriff auf Dienstkonto erhalten

Die geheimen S3-Anmeldedaten werden nur erstellt und sind nur verfügbar, wenn im Projekt-Namespace ein Bucket vorhanden ist.

Hinweis: Nutzer dürfen keine Arbeitslasten, die als Dienstkonten ausgeführt werden, auf dem Management API-Server ausführen, auf dem die Secrets für die Zugriffsschlüssel der Dienstkonten ursprünglich erstellt wurden. Nutzer können Arbeitslasten im 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 den Secret-Namen aus dem Nutzercluster.

1. Führen Sie für die Standard Storage-Klasse 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. Suchen Sie manuell in den aufgelisteten Secret-Namen oder verwenden Sie grep, um object-storage-key-(std|nl) zu finden:

   kubectl get -n=PROJECT_NAME \
       serviceaccount SA_NAME \
       -o=jsonpath='{.secrets}{"\n"}' | grep -E 'object-storage-key-(std|nl)'
   

   Ersetzen Sie Folgendes:

   • PROJECT_NAME: Name Ihres Projekts
   • SA_NAME: Name Ihres Dienstkontos.

3. Sie können das Secret in Ihrem Pod als Umgebungsvariablen oder Dateien referenzieren.

Voreingestellte Rollenberechtigungen

Im globalen API-Server sind vordefinierte Rollen für den administrativen und operativen Zugriff auf Dual-Region-Buckets verfügbar. Diese Rollen gewähren auch Zugriff auf zonale Buckets, aber 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.

Im Folgenden finden Sie eine Liste aller Objektspeicherberechtigungen, die der Projekt-Bucket-Objekt-Betrachter 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 project-bucket-object-viewer gewährt.

Eine Liste aller zusätzlichen Objektspeicherberechtigungen, die Role gewährt:

• 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 Projekt-Bucket-Administratoren

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

Die Role gewährt außerdem die folgenden Berechtigungen:

• Bucket-API-Berechtigungen:

  1. Erstellen
  2. Aktualisieren
  3. Delete