Ruota le credenziali di archiviazione degli oggetti

L'archiviazione di oggetti dell'appliance con air gap di Google Distributed Cloud (GDC) è fornita da OTS (ONTAP Select). OTS ha un proprio sistema di gestione degli utenti di archiviazione degli oggetti. Ogni credenziale utente di archiviazione oggetti OTS viene archiviata come secret nei cluster.

Questo documento descrive i passaggi per la rotazione delle credenziali utente di OTS object storage. Ruota le credenziali utente di Object Storage nelle seguenti situazioni:

  • rotazione della chiave pianificata regolarmente per ruotare tutte le chiavi utente.
  • mitigando l'esposizione delle chiavi. Devi ruotare la chiave utente esposta il prima possibile.

Prima di iniziare

Completa i seguenti passaggi:

  1. Verifica di soddisfare i prerequisiti per il laptop.
  2. Assicurati di poter accedere al cluster OTS ed eseguire i comandi CLI vserver object-store-server.
  3. Assicurati di poter accedere come amministratore al cluster di infrastruttura e al cluster di gestione utilizzando kubectl.

Traduci UID

Ogni utente di object storage dispone di una chiave di accesso e di una chiave segreta archiviate come secret Kubernetes e utilizzate dai workload Kubernetes per accedere all'object storage di backend. La rotazione delle chiavi utente include l'aggiornamento di tutti i secret.

Puoi ottenere un elenco di utenti dell'archiviazione di oggetti accedendo a uno dei tre nodi utilizzando:

vserver object-store-server user show

L'output è un elenco di UID e dovrebbe essere simile a:

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

Esistono tre tipi di utenti:

Utenti dell'archiviazione di oggetti
UID Tipo di utente Nome secret Spazio dei nomi secret
root Amministratore di sistema 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> Service account Kubernetes object-storage-key-std-sa-&ltencoded-sa> &ltnamespace>
k8su_&ltusername> Utente Kubernetes object-storage-key-std-user-&ltencoded-username> object-storage-access-keys

L'utente root ha tre secret identici, che rispecchiano la struttura di Data Center, che comprende più classi di archiviazione e categorie di tenant. Al contrario, Appliance ha un solo livello di spazio di archiviazione degli oggetti. Tutti e tre i segreti associati all'utente root devono essere ruotati contemporaneamente.

L'identificazione utente (UID), escluso l'utente root, deve rispettare il formato k8ssa_<namespace>_<sa> o k8su_<username>. Ottieni <encoded-sa> o <encoded-username>:

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

Sostituisci UID_SUFFIX con <sa> nell'UID e otterrai <encoded-sa>.

Sostituisci UID_SUFFIX con <username> nell'UID e otterrai <encoded-username>.

Ruota la chiave utente

  1. Accedi al cluster OTS.

  2. Recupera un elenco degli UID utente di Object Storage.

    vserver object-store-server user show

    Il risultato è un elenco di UID. Puoi trovare esempi in Translate UID. Ripeti i seguenti passaggi per ogni UID nell'elenco.

  3. Ottieni la vecchia chiave di accesso e la chiave segreta per l'utente di destinazione.

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

    Sostituisci UID con l'UID dell'utente di destinazione.

  4. Genera una nuova chiave di accesso e una nuova chiave segreta per l'utente di destinazione nell'archiviazione di oggetti. Le chiavi precedenti e quelle nuove coesistono dopo questo passaggio ed entrambe possono essere utilizzate per l'accesso.

    vserver object-store-server user regenerate-keys -vserver root-admin -user UID

  5. Aggiorna il secret Kubernetes con la nuova chiave di accesso e la chiave segreta. Devi aggiornare il secret solo nel cluster di infrastruttura root o nel cluster di gestione e il secret viene propagato ad altri cluster, se necessario.

    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)"'"}]'

    Sostituisci quanto segue:

    • KUBECONFIG: il percorso del file kubeconfig. Il server API deve essere il server API del piano di controllo per l'utente root; in caso contrario, deve essere il server API di gestione.
    • SECRET_NAME: il nome segreto dell'utente, che può essere derivato dalla sezione Traduci UID. Se l'utente ha più secret Kubernetes (ad es. root user), sostituisci con il nome di ogni secret ed esegui il comando.
    • SECRET_NAMESPACE: lo spazio dei nomi segreto per l'utente, che può essere derivato dalla sezione Translate UID.
    • ACCESS_KEY: la nuova chiave di accesso generata nel passaggio precedente.
    • SECRET_KEY: la nuova chiave segreta generata nel passaggio precedente.

  6. Il workload che utilizza il secret deve essere implementato per l'aggiornamento automatico. In caso contrario, devi riavviare il workload per riflettere la modifica del secret.

    Ad esempio, per l'utente root, devi riavviare i seguenti workload nel cluster dell'infrastruttura:

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

Convalida

Segui le istruzioni per creare un bucket e caricare e scaricare oggetti di Object Storage per creare un nuovo bucket e concedere l'accesso utilizzando il controllo dell'accesso basato sui ruoli (RBAC). La rotazione della chiave di archiviazione degli oggetti è completata se il bucket viene creato correttamente e il soggetto dispone delle autorizzazioni necessarie per accedervi.