Alternar credenciais de armazenamento de objetos

O armazenamento de objetos do dispositivo com isolamento físico do Google Distributed Cloud (GDC) é fornecido pelo OTS (ONTAP Select). O OTS tem o próprio sistema de gerenciamento de usuários de armazenamento de objetos. Cada credencial de usuário de armazenamento de objetos OTS é armazenada como um secret nos clusters.

Este documento descreve as etapas para fazer a rotação das credenciais de usuário do armazenamento de objetos OTS. Alterne as credenciais de usuário do armazenamento de objetos nas seguintes situações:

  • rotação de chaves programada regularmente para girar todas as chaves de usuário.
  • mitigando a principal exposição. Faça a rotação da chave de usuário exposta assim que possível.

Antes de começar

Siga estas etapas:

  1. Verifique se você atende aos pré-requisitos de laptop.
  2. Verifique se é possível fazer login no cluster do OTS e executar comandos da CLI vserver object-store-server.
  3. Verifique se é possível fazer login como administrador no cluster de infraestrutura e no cluster de gerenciamento usando kubectl.

UID de tradução

Cada usuário de armazenamento de objetos tem uma chave de acesso e uma chave secreta armazenadas como um secret do Kubernetes e usadas por cargas de trabalho do Kubernetes para acessar o armazenamento de objetos de back-end. A rotação das chaves de usuário inclui a atualização de todos os secrets.

Para conferir uma lista de usuários do armazenamento de objetos, faça login em um dos três nós usando:

vserver object-store-server user show

A saída é uma lista de UIDs e deve ser semelhante a esta:

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

Há três tipos de usuários:

Usuários do armazenamento de objetos
UID Tipo de usuário Nome da chave secreta Namespace do secret
root Administrador do 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> Conta de serviço do Kubernetes object-storage-key-std-sa-&ltencoded-sa> &ltnamespace>
k8su_&ltusername> Usuário do Kubernetes object-storage-key-std-user-&ltencoded-username> object-storage-access-keys

O usuário root tem três segredos idênticos, espelhando a estrutura do Data Center, que abrange várias classes de armazenamento e categorias de locatário. Por outro lado, o Appliance tem apenas um nível de armazenamento de objetos. Todos os três secrets associados ao usuário raiz precisam ser alternados simultaneamente.

A identificação do usuário (UID), excluindo o usuário root, precisa seguir o formato k8ssa_<namespace>_<sa> ou k8su_<username>. Consiga 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 para receber <encoded-sa>.

Substitua UID_SUFFIX por <username> no UID para receber <encoded-username>.

Alternar chave de usuário

  1. Faça login no cluster do OTS.

  2. Receba uma lista de UIDs de usuários do armazenamento de objetos.

    vserver object-store-server user show

    O resultado é uma lista de UIDs. Confira exemplos em Traduzir UID. Repita as etapas a seguir para cada UID na lista.

  3. Receba a chave de acesso e a chave secreta antigas do usuário de destino.

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

    Substitua UID pelo UID do usuário de destino.

  4. Gere uma nova chave de acesso e uma chave secreta para o usuário de destino no armazenamento de objetos. As chaves antiga e nova coexistem após esta etapa, 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 a chave secreta. Basta atualizar o secret no cluster de infraestrutura raiz ou de gerenciamento, e ele será 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:

    • KUBECONFIG: o caminho para o kubeconfig. O servidor da API precisa ser o servidor da API do plano de controle para o usuário root. Caso contrário, ele precisa ser o servidor da API de gerenciamento.
    • SECRET_NAME: o nome secreto do usuário, que pode ser derivado da seção Traduzir UID. Se o usuário tiver vários secrets do Kubernetes (ou seja, root), substitua pelo nome de cada secret e execute o comando.
    • SECRET_NAMESPACE: o namespace secreto do usuário, que pode ser derivado da seção Traduzir UID.
    • ACCESS_KEY: a nova chave de acesso gerada na etapa anterior.
    • SECRET_KEY: a nova chave secreta gerada na etapa anterior.

  6. A carga de trabalho que consome o secret precisa ser implementada para ser atualizada automaticamente. Caso contrário, reinicie a carga de trabalho para refletir a mudança no secret.

    Por exemplo, para o usuário root, é necessário 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 as instruções de armazenamento de objetos criar bucket e fazer upload e download de objetos para criar um bucket e conceder acesso usando o RBAC. A rotação da chave de armazenamento de objetos será concluída se o bucket for criado com sucesso e o assunto tiver as permissões necessárias para acessá-lo.