Objektspeicheranmeldedaten rotieren

Der Objektspeicher für die Air-Gap-Appliance von Google Distributed Cloud (GDC) wird von OTS (ONTAP Select) bereitgestellt. OTS hat ein eigenes Nutzerverwaltungssystem für den Objektspeicher. Die Anmeldedaten für jeden OTS-Objektspeicher werden als Secret in Clustern gespeichert.

In diesem Dokument wird beschrieben, wie Sie die Anmeldedaten für den OTS-Objektspeicher rotieren. Rotieren Sie die Anmeldedaten für den Objektspeicher in den folgenden Situationen:

  • regelmäßig geplante Schlüsselrotation, um alle Nutzersicherheitsschlüssel zu rotieren.
  • Schlüsseloffenlegung zu minimieren. Sie sollten den offengelegten Nutzersicherheitsschlüssel so schnell wie möglich rotieren.

Hinweise

Gehen Sie folgendermaßen vor:

  1. Prüfen Sie, ob Sie die Voraussetzungen für Laptops erfüllen.
  2. Prüfen Sie, ob Sie sich im OTS-Cluster anmelden und vserver object-store-server-CLI-Befehle ausführen können.
  3. Achten Sie darauf, dass Sie sich mit kubectl als Administrator im Infrastrukturcluster und im Verwaltungscluster anmelden können.

Übersetzungs-UID

Jeder Object Storage-Nutzer hat einen Zugriffsschlüssel und einen geheimen Schlüssel, die als Kubernetes-Secret gespeichert und von Kubernetes-Arbeitslasten verwendet werden, um auf den Backend-Object Storage zuzugreifen. Beim Rotieren der Nutzersicherheitsschlüssel werden alle Secrets aktualisiert.

Sie können eine Liste der Objektspeicher-Nutzer abrufen, indem Sie sich mit einem der drei Knoten anmelden:

vserver object-store-server user show

Die Ausgabe ist eine Liste von UIDs und sollte in etwa so aussehen:

[
    "root",
    "k8ssa_gpc-system_inventory-export-images",
    "k8ssa_gpc-system_inventory-export-hardware",
    "k8su_test-user@example.com"
]

Es gibt drei Arten von Nutzern:

Objektspeicher-Nutzer
UID Nutzertyp Secret-Name Secret-Namespace
root Systemadministratoren objectstorage-tenant-bucket-controller-standard-system-s3-sa gpc-system
objectstorage-tenant-bucket-controller-standard-user-s3-sa
objectstorage-tenant-bucket-controller-nearline-user-s3-sa
k8ssa_&ltnamespace>_&ltsa> Kubernetes-Dienstkonto object-storage-key-std-sa-&ltencoded-sa> &ltnamespace>
k8su_&ltusername> Kubernetes-Nutzer object-storage-key-std-user-&ltencoded-username> object-storage-access-keys

Der root-Nutzer hat drei identische Secrets, die die Struktur des Rechenzentrums widerspiegeln, das mehrere Speicherklassen und Mandantenkategorien umfasst. Im Gegensatz dazu bietet Appliance nur eine Ebene für den Objektspeicher. Alle drei mit dem Root-Nutzer verknüpften Secrets müssen gleichzeitig rotiert werden.

Die Nutzer-ID (UID) mit Ausnahme des root-Nutzers muss entweder dem Format k8ssa_<namespace>_<sa> oder k8su_<username> entsprechen. Rufen Sie entweder die <encoded-sa> oder die <encoded-username> ab:

echo -n 'UID_SUFFIX' | shasum -a 256 | cut -d " " -f 1 | xxd -r -p | base32 | awk '{print tolower($0)}' | sed 's/=*$//g'

Ersetzen Sie UID_SUFFIX durch <sa> in der UID. Das Ergebnis ist <encoded-sa>.

Ersetzen Sie UID_SUFFIX durch <username> in der UID. Das Ergebnis ist <encoded-username>.

Nutzer-Schlüssel rotieren

  1. Melden Sie sich beim OTS-Cluster an.

  2. Ruft eine Liste mit Nutzer-UIDs für den Objektspeicher ab.

    vserver object-store-server user show
    

    Das Ergebnis ist eine Liste von UIDs. Beispiele finden Sie unter Translate UID. Wiederholen Sie die folgenden Schritte für jede UID in der Liste.

  3. Rufen Sie den alten Zugriffsschlüssel und den alten geheimen Schlüssel für den Zielnutzer ab.

    set -privilege advanced
    vserver object-store-server user show -user UID
    

    Ersetzen Sie UID durch die UID des Zielnutzers.

  4. Generieren Sie einen neuen Zugriffsschlüssel und einen neuen Secret-Schlüssel für den Zielnutzer im Objektspeicher. Nach diesem Schritt sind der alte und der neue Schlüssel gleichzeitig vorhanden und können beide für den Zugriff verwendet werden.

    vserver object-store-server user regenerate-keys -vserver root-admin -user UID
    
  5. Aktualisieren Sie das Kubernetes-Secret mit dem neuen Zugriffsschlüssel und dem neuen geheimen Schlüssel. Sie müssen das Secret nur im Root-Infrastrukturcluster oder Managementcluster aktualisieren. Das Secret wird bei Bedarf auf andere Cluster übertragen.

    kubectl --kubeconfig KUBECONFIG patch secret -n SECRET_NAMESPACE SECRET_NAME --type='json' -p='[{"op": "replace", "path": "/data/access-key-id", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}, {"op": "replace", "path": "/data/secret-access-key", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}]'
    

    Ersetzen Sie Folgendes:

    • KUBECONFIG: Der Pfad zur kubeconfig-Datei. Der API-Server muss der API-Server der Steuerungsebene für den Nutzer root sein. Andernfalls muss es der Management-API-Server sein.
    • SECRET_NAME: Der Secret-Name für den Nutzer, der aus dem Abschnitt Translate UID abgeleitet werden kann. Wenn der Nutzer mehrere Kubernetes-Secrets hat (d.h. root-Nutzer) ersetzen Sie durch jeden Secret-Namen und führen Sie den Befehl aus.
    • SECRET_NAMESPACE: Der Secret-Namespace für den Nutzer, der aus dem Abschnitt Nutzer-UID übersetzen abgeleitet werden kann.
    • ACCESS_KEY: der neue Zugriffsschlüssel, der im vorherigen Schritt generiert wurde.
    • SECRET_KEY: Der neue geheime Schlüssel, der im vorherigen Schritt generiert wurde.
  6. Die Arbeitslast, die das Secret verwendet, muss so implementiert werden, dass es automatisch aktualisiert wird. Andernfalls müssen Sie die Arbeitslast neu starten, damit die Änderung des Secrets übernommen wird.

    Für den Nutzer root müssen Sie beispielsweise die folgenden Arbeitslasten im Infrastrukturcluster neu starten:

    kubectl --kubeconfig KUBECONFIG rollout restart deployment obj-bucket-cm-backend-controller -n obj-system
    

Validierung

Folgen Sie der Anleitung unter Bucket erstellen und Objekt hochladen und herunterladen, um einen neuen Bucket zu erstellen und den Zugriff mithilfe von RBAC zu gewähren. Die Rotation des Objekt-Speicherschlüssels ist abgeschlossen, wenn der Bucket erfolgreich erstellt wurde und das Subjekt die erforderlichen Berechtigungen für den Zugriff darauf hat.