Rode as credenciais de armazenamento de objetos

O armazenamento de objetos do dispositivo isolado do Google Distributed Cloud (GDC) é fornecido pelo OTS (ONTAP Select). O OTS tem o seu próprio sistema de gestão de utilizadores de armazenamento de objetos. Cada OTS credencial de utilizador de armazenamento de objetos é armazenada como um segredo nos clusters.

Este documento descreve os passos para rodar as credenciais de utilizador do armazenamento de objetos OTS. Rode as credenciais de utilizador do armazenamento de objetos nas seguintes situações:

  • Rotação de chaves agendada regularmente para rodar todas as chaves de utilizador.
  • mitigar a exposição de chaves. Deve rodar a chave do utilizador exposta assim que possível.

Antes de começar

Conclua os seguintes passos:

  1. Verifique se cumpre os pré-requisitos do portátil.
  2. Certifique-se de que consegue iniciar sessão no cluster do OTS e executar comandos da CLI vserver object-store-server.
  3. Certifique-se de que consegue iniciar sessão como administrador no cluster de infraestrutura e no cluster de gestão através do comando kubectl.

UID de tradução

Cada utilizador do armazenamento de objetos tem uma chave de acesso e uma chave secreta que são armazenadas como um segredo do Kubernetes e usadas por cargas de trabalho do Kubernetes para aceder ao armazenamento de objetos de back-end. A rotação das chaves de utilizador inclui a atualização de todos os segredos.

Pode obter uma lista de utilizadores do armazenamento de objetos iniciando sessão num dos três nós através do seguinte comando:

vserver object-store-server user show

O resultado é uma lista de UIDs e deve ser semelhante a:

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

Existem três tipos de utilizadores:

Utilizadores do armazenamento de objetos
UID Tipo de utilizador Nome secreto Espaço de nomes secreto
raiz Administrador de sistemas 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> Conta de serviço do Kubernetes object-storage-key-std-sa-&ltencoded-sa> &ltnamespace>
k8su_&ltusername> Utilizador do Kubernetes object-storage-key-std-user-&ltencoded-username> object-storage-access-keys

O utilizador root tem três segredos idênticos, o que reflete a estrutura do centro de dados, que abrange várias classes de armazenamento e categorias de inquilinos. Por outro lado, o Appliance só tem um nível de armazenamento de objetos. Todos os três segredos associados ao utilizador raiz têm de ser rodados em simultâneo.

A identificação do utilizador (UID), excluindo o utilizador root, deve seguir o formato k8ssa_<namespace>_<sa> ou k8su_<username>. Obtenha o <encoded-sa> ou 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'

Substitua UID_SUFFIX por <sa> no UID e vai receber <encoded-sa>.

Substitua UID_SUFFIX por <username> no UID, e recebe <encoded-username>.

Alterne a chave do utilizador

  1. Inicie sessão no cluster OTS.

  2. Obtenha uma lista de UIDs de utilizadores do armazenamento de objetos.

    vserver object-store-server user show

    O resultado é uma lista de UIDs. Pode encontrar exemplos em Traduzir UID. Repita os passos seguintes para cada UID na lista.

  3. Obtenha a chave de acesso antiga e a chave secreta do utilizador de destino.

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

    Substitua UID pelo UID do utilizador de destino.

  4. Gere uma nova chave de acesso e uma chave secreta para o utilizador de destino no armazenamento de objetos. As chaves antigas e novas coexistem após este passo, e ambas podem ser usadas para acesso.

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

  5. Atualize o secret do Kubernetes com a nova chave de acesso e chave secreta. Só tem de atualizar o segredo no cluster de infraestrutura raiz ou no cluster de gestão, e o segredo é propagado para outros clusters, se necessário.

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

    Substitua o seguinte:

    • KUBECONFIG: o caminho para o kubeconfig. O servidor da API tem de ser o servidor da API do plano de controlo para o utilizador root; caso contrário, tem de ser o servidor da API de gestão.
    • SECRET_NAME: o nome secreto do utilizador, que pode ser derivado da secção Traduzir UID. Se o utilizador tiver vários segredos do Kubernetes (ou seja, root user), substitua pelo nome de cada segredo e execute o comando.
    • SECRET_NAMESPACE: o espaço de nomes secreto para o utilizador, que pode ser derivado da secção Traduzir UID.
    • ACCESS_KEY: a nova chave de acesso gerada no passo anterior.
    • SECRET_KEY: a nova chave secreta gerada no passo anterior.

  6. A carga de trabalho que consome o segredo tem de ser implementada para ser atualizada automaticamente. Caso contrário, tem de reiniciar a carga de trabalho para refletir a alteração no segredo.

    Por exemplo, para o utilizador root, tem de reiniciar as seguintes cargas de trabalho no cluster de infraestrutura:

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

Validação

Siga os passos em Object Storage create bucket e upload and download object para criar um novo contentor e conceder acesso através do RBAC. A rotação da chave de armazenamento de objetos está concluída se o contentor for criado com êxito e o assunto tiver as autorizações necessárias para aceder ao mesmo.