Storage-Bucket-Zugriff gewähren und erhalten

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 Dokumentation zu Zielgruppen für 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.

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. 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 IAM-Rolle „Project Admin“ 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: bob@example.com
  apiGroup: rbac.authorization.k8s.io
  # Could be bob or bob@example.com 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 Zugriffsanmeldedaten in einem Secret erstellt. Anmeldedaten sind erforderlich, um die Distributed Cloud CLI zu konfigurieren und Befehle zur Interaktion mit dem Bucket auszuführen.

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 bob@foo.com hat ein Secret mit dem Namen:

object-storage-key-std-user-l74gbpyrsbmwy4mivocr3nur6dzrnhcfhe3otyplul42i732aama

Anmeldedaten für den Nutzerzugriff abrufen

Für ein 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 die Secret-Ressourcen aufzulisten, die Sie im Namespace object-storage-access-keys aufrufen dürfen:

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

    Wenn Sie Secrets in diesem Namespace aufrufen können, wird eine Ausgabe angezeigt, die einen oder mehrere Secret-Namen enthält, die mit object-storage-key- beginnen, ähnlich wie hier:

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

    • HINWEIS: Wenn Sie ein Administrator mit der Berechtigung zum Aufrufen aller Secret-Ressourcen oder zum Übernehmen der Identität anderer Nutzer sind, können Sie einen der folgenden Befehle ausführen, um den Namen von Secrets für einen bestimmten Nutzer zu finden:

      Alle Secrets auflisten, die zu einem bestimmten Nutzer gehören:

      export USER_NAME=bob@example.com
kubectl get secrets --namespace object-storage-access-keys -o json | jq  -r --arg USER_NAME "${USER_NAME:?}" '.items[] | select( (.metadata.annotations."object.gdc.goog/subject"==$USER_NAME)) | .metadata.name'

      Wechseln Sie die Identität eines Nutzers, um zu sehen, welche Secrets er aufrufen kann:

      export USER_NAME=bob@example.com
kubectl auth can-i --list --namespace object-storage-access-keys --as "${USER_NAME:?}" | grep "object-storage-key-"

  2. Rufen Sie den Inhalt des entsprechenden Secrets ab:

    kubectl get -o yaml --namespace object-storage-access-keys secret SECRET_NAME

    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.

Für ein Dienstkonto-Subjekt wird das Secret im selben Namespace wie das Dienstkonto erstellt.

Führen Sie den folgenden Befehl aus, um zu prüfen, ob Sie Secret-Ressourcen im Namespace abrufen und auflisten können. Wenden Sie sich an Ihren Administrator, wenn dies nicht der Fall ist:

export SA_NAMESPACE=PROJECT_NAMESPACE
kubectl auth can-i --list --namespace $SA_NAMESPACE

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

export SA_NAME=SA_NAME
kubectl get secrets --namespace $SA_NAMESPACE  -o json | jq  -r --arg USER_NAME "${SA_NAME:?}" '.items[] | select( (.metadata.annotations."object.gdc.goog/subject"==$USER_NAME)) | .metadata.name'

Die Ausgabe sollte in etwa so aussehen:

object-storage-key-std-sa-mng3olp3vsynhswzasowzu3jgzct2ert72pjp6wsbzqhdwckwzbq

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

Vordefinierte Rollenberechtigungen

Beachten Sie, dass vordefinierte Rollen auch auf dem globalen API-Server für den administrativen und operativen Zugriff auf Dual-Region-Buckets verfügbar sind.

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 das Verb „project-bucket-object-viewer“ gewährt:

  • Bucket-API-Berechtigungen:

    1. get
    2. list
    3. Ansehen

  • S3-Objektspeicherberechtigungen:

    1. GetBucketVersioning
    2. GetObject
    3. GetObjectAcl
    4. GetObjectLegalHold
    5. GetObjectRetention
    6. GetObjectTagging
    7. GetObjectVersion
    8. GetObjectVersionTagging
    9. ListBucket
    10. ListBucketVersions
    11. ListBucketMultipartUploads
    12. 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.

Hier finden Sie eine Liste aller zusätzlichen Objektspeicherberechtigungen, die die Rolle 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 Rolle gewährt außerdem die folgenden zusätzlichen Berechtigungen:

  • Bucket-API-Berechtigungen:

    1. Erstellen
    2. Aktualisieren
    3. Delete