Rode as chaves de autenticação de armazenamento e os certificados

O dispositivo isolado do Google Distributed Cloud (GDC) adota o ONTAP Select (OTS) como fornecedor de armazenamento definido por software. O OTS tem o seu próprio sistema de autenticação, em que cada identidade (serviço principal ou cliente) tem um nome e uma chave associados.

Este documento descreve os passos para rodar as chaves de autenticação e os certificados que têm de ser realizados para:

• Rotação de chaves agendada regularmente para garantir que o dispositivo está em conformidade e seguro.
• exposição da chave. Deve rodar a chave exposta assim que possível.

Antes de começar

Certifique-se de que tem o seguinte acesso:

• Acesso à consola do administrador do cluster ONTAP
• Kubeconfig para o servidor da API Management

Rote as credenciais IPsec (PSK)

O ONTAP suporta a autenticação com certificado para IPsec a partir da versão 9.10.1. Esta versão do GDC está na versão 9.14.1 e usa chaves pré-partilhadas.

Para o dispositivo, o IPsec é implementado para dois tipos de tráfego OTS:

• Tráfego externo entre anfitriões bare metal e SVMs.
• Tráfego interno entre nós de trabalho.

Vamos analisá-los separadamente.

Pré-requisitos

• Acesso à consola do administrador do cluster ONTAP
• Uma nova chave pré-partilhada
• Kubeconfig para o servidor da API Management
• Acesso a anfitriões para atualizar a configuração do StrongSwan

Impacto

Enquanto as políticas IPsec estão a ser rodadas, os anfitriões vão sofrer uma perda de conetividade IP com o sistema de armazenamento. As ligações vão ficar paradas ou podem falhar, dependendo do comportamento da aplicação. Se possível, pode pausar as cargas de trabalho do utilizador durante a rotação, mas não é obrigatório. As ligações devem ser recuperadas pouco depois da reposição dos segredos.

Rotação de chaves para tráfego externo da OTS

Para validar a rotação, use o seguinte comando e compare o resultado:

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get StorageEncryptionConnections -n gpc-system

Saída:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h

Verifique se o campo READY é verdadeiro para o anfitrião específico no qual executou o script anteriormente.

Rode manualmente a PSK se encontrar algum erro durante a validação.

1. Execute o seguinte comando:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   mgmt_ip="$(kubectl get storagecluster -A -o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"
   
   username="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.username}' | base64 -d)"
   
   password="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.password}' | base64 -d)"
   

2. Ver a palavra-passe e copiá-la para a área de transferência:

   echo $password
   

3. Inicie sessão na consola do ONTAP:

   ssh $username@$mgmt_ip
   

   Quando lhe for pedida a palavra-passe, cole a palavra-passe copiada no passo anterior.

4. Use o seguinte script para a rotação de credenciais:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get StorageEncryptionConnections -n gpc-system
   

   Saída:

   NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
   bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
   bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
   bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h
   

   Para cada anfitrião que quer rodar, pode executar o seguinte:

   export bm_host= //name of bm-host from above
   export secret="${bm_host}-pre-shared-key"
   export job_name="os-policy-config-host-ipsec-${bm_host}"
   export ns="gpc-system"
   export svm="$(kubectl get storageencryptionconnections "${bm_host}" -n "${ns}" -o jsonpath='{.spec.storageVirtualMachineRef.name}')"
   

   Agora, confirme que vê todos os componentes da ligação de encriptação de armazenamento. Para ligações de clusters de administrador, seja de administrador principal ou de administrador da organização, tem de usar o cluster de administrador principal.

   kubectl get secrets -n "${ns}" "${secret}"
   kubectl get jobs -n "${ns}" "${job_name}"
   

   Se ambos os itens estiverem presentes, pode avançar para o passo seguinte. Caso contrário, pare e não avance com a modificação do IPsec. Contacte o apoio técnico.

   kubectl delete secrets -n "${ns}" "${secret}"
   kubectl delete jobs "${job_name}" -n "${ns}"
   

   Agora, use o servidor da API Management para eliminar o storageencryptionconnection

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl delete storageencryptionconnections "${bm_host}"
   
   annotation_key="reconcile_annotation_key"
   annotation_value="reconcile_annotation_value"
   
   kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=merge -p "{\"metadata\":{\"annotations\":{\"$annotation_key\":\"$annotation_value\"}}}"
   kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=json -p="[{\"op\": \"remove\", \"path\": \"/metadata/annotations/$annotation_key\"}]"
   

   Rotação de chaves para tráfego interno do OTS

Da mesma forma, para validar a rotação, use o seguinte comando e compare o resultado:

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get secret ots-internal-pre-shared-key -n gpc-system

Saída:

NAME                          TYPE     DATA   AGE
ots-internal-pre-shared-key   Opaque   1      18m

kubectl get jobs -n gpc-system | grep os-policy-config-host-ipsec

Saída:

os-policy-config-host-ipsec-bm-3d33bb857t5bh                Complete   1/1           17s        10m
os-policy-config-host-ipsec-bm-774fa8e6frgr7                Complete   1/1           30s        11m
os-policy-config-host-ipsec-bm-8e452fb29q5wd                Complete   1/1           23s        11m

Verifique se todas as tarefas estão no estado Complete.

kubectl get StorageEncryptionConnections -n gpc-system

Saída:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-3d33bb85   bm-3d33bb85        root-admin              10.4.4.0/24   bm-3d33bb85-pre-shared-key   True    6h16m
bm-774fa8e6   bm-774fa8e6        root-admin              10.4.4.0/24   bm-774fa8e6-pre-shared-key   True    16h
bm-8e452fb2   bm-8e452fb2        root-admin              10.4.4.0/24   bm-8e452fb2-pre-shared-key   True    21h

Certifique-se de que o campo READY é verdadeiro para todos os anfitriões.

1. Elimine todos os registos de alterações no passo 2 com a ordem indicada

   • Elimine o segredo do tráfego interno sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system

   • Eliminar todas as três tarefas de políticas do SO sh kubectl delete jobs os-policy-config-host-ipsec-bm-3d33bb857t5bh -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-774fa8e6frgr7 -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-8e452fb29q5wd -n gpc-system

   • Elimine todas as três storageencryptionconnection sh kubectl delete StorageEncryptionConnections bm-3d33bb85-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-774fa8e6-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-8e452fb2-root-admin -n gpc-system

2. Aguarde alguns minutos (~3 a 5 minutos). Repita o passo 2 até que todos os CRs estejam no estado PRONTO ou Concluído.

Rode as teclas de volume

Esta secção descreve os passos manuais para rodar as credenciais de volume do OTS.

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 na consola do cluster OTS através do BM01 ou do BM02.

Inicie a rotação da chave do volume

Na consola do OTS, acione a alteração da chave única:

volume encryption rekey start -vserver SVM_name -volume volume_name

O seguinte comando altera a chave de encriptação para vol1 em SVMvs1:

cluster1::> volume encryption rekey start -vserver vs1 -volume vol1

Para ver os nomes dos servidores virtuais e dos volumes, pode usar o comando show:

vserver show
volume show

Valide a alteração da chave de volume

Após o início da rotação de chaves, verifique o estado da nova atribuição de chaves:

volume encryption rekey show

Apresentar o estado da operação de alteração da chave:

cluster1::> volume encryption rekey show

Vserver   Volume   Start Time           Status
-------   ------   ------------------   ---------------------------
vs1       vol1     9/18/2017 17:51:41   Phase 2 of 2 is in progress.

Quando a operação de nova introdução de chave estiver concluída, verifique se o volume está ativado para encriptação:

volume show -is-encrypted true

Apresente os volumes encriptados em cluster1:

cluster1::> volume show -is-encrypted true

Vserver  Volume  Aggregate  State  Type  Size  Available  Used
-------  ------  ---------  -----  ----  -----  --------- ----
vs1      vol1    aggr2     online    RW  200GB    160.0GB  20%

Rode certificados HSM externos

Esta secção descreve como rodar e atualizar os certificados HSM externos para o ONTAP.

Pré-requisitos

• Acesso de administrador ao cluster ONTAP ou às SVMs relevantes
• Palavra-passe atual
• Acesso do kubectl aos clusters adequados

Instruções

1. Faça uma cópia de segurança dos certificados HSM antigos:

   kubectl get secret aa-aa-external-hsm-creds -n gpc-system -o yaml > external-hsm-creds-old.yaml
   

2. Atualize o secret dos certificados do HSM no Kubernetes:

   1. Copie o ficheiro YAML do código antigo: sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

   2. Atualize o novo ficheiro external-hsm-creds-new.yaml com as novas credenciais do HSM, incluindo o certificado da CA do servidor, o certificado de cliente público e a chave privada do cliente.

   3. Aplique a alteração e atualize o objeto secreto do HSM.

      kubectl apply -f external-hsm-creds-new.yaml
      

3. Atualize os certificados de HSM no ONTAP:

   1. Inicie sessão na CLI do ONTAP.

   2. Instale o novo certificado da AC do servidor:

      cluster::> security certificate install -type server-ca -vserver <>
      

   3. Instale o novo certificado de cliente:

      cluster::> security certificate install -type client -vserver <>
      

   4. Atualize a configuração do gestor de chaves para usar os certificados instalados recentemente:

      cluster::> security key-manager external modify -vserver <> -client-cert <> -server-ca-certs <>
      

Validação

1. Valide a alteração com o estado de gestor de chaves:

   cluster::> security key-manager external show-status
   

   Verifique se os servidores de chaves ainda estão no estado Available.

Rode a credencial de administrador do armazenamento

Esta secção descreve como rodar e definir o utilizador e a palavra-passe do administrador de armazenamento.

Pré-requisitos

• Acesso de administrador ao cluster ONTAP ou às SVMs relevantes
• Palavra-passe atual
• Acesso do kubectl aos clusters adequados

Instruções

1. Comece com o seguinte comando e, em seguida, siga as instruções resultantes:

   cluster::> security login password
   

2. Atualize a chave secreta para corresponder a:

   • Opção 1 (interativa):

     kubectl edit secret -n <netapp_namespace> netapp_credential
     

     Use o editor para alterar a palavra-passe para o novo valor codificado em base64.

   • Opção 2 (patch com dependência de jq):

     k get secret -n <netapp_namespace> netapp_credential -o json | jq '.data["password"]="<new-base64-encoded-password>"' | kubectl apply -f -
     

Rode as credenciais de acesso de emergência do ONTAP

Durante a configuração do armazenamento de ficheiros e blocos, são criadas quatro contas de utilizador de acesso de emergência que podem ser usadas para aceder diretamente ao ONTAP. Estas credenciais podem ser obtidas como segredos no servidor da API Management. Depois de serem usadas, as credenciais têm de ser alteradas.

São criados dois tipos de segredos durante a configuração: nível 1 e nível 2. O nível 1 é storage-root-level1 and storage-root-level1-backup. O nível 2 é storage-root-level2 and storage-root-level2-backup. Os segredos de nível 2 têm de ser armazenados no cofre, e cada nível tem dois segredos: normal e de cópia de segurança. Embora o software processe a eliminação dos segredos normais e de cópia de segurança em simultâneo, recomendamos que alterne apenas um destes segredos de parceiros de cada vez como uma camada adicional de segurança.

Embora os segredos de nível 1 sejam rodados automaticamente após um período de 90 dias, os segredos de nível 2 não o são. Qualquer tipo de segredo tem de ser rodado manualmente através do seguinte processo, se for usado.

Pré-requisitos

• Acesso necessário: servidor da API Management

Validação

1. A rotação de segredos pode ser validada verificando se o segredo continua marcado para eliminação. Se não for, o segredo foi alterado. Siga o passo 1 das instruções seguintes para verificar.

2. Se o segredo for um segredo de nível 2, copie-o num suporte físico e armazene-o no cofre. Em seguida, o segredo deve ser marcado como persistente através da anotação "disk.gdc.goog/persisted".

    kubectl annotate secrets
    <secret_name> -n gpc-system disk.gdc.goog/persisted=''
   

Use as instruções seguintes para rodar manualmente o segredo se encontrar algum erro durante a validação.

Instruções

1. Verifique se um segredo está marcado para eliminação:

   1. Execute o seguinte comando:

      kubectl get secret <secret_name> -n gpc-system -o yaml
      

   2. Se o campo deletionTimestamp estiver presente na resposta, conforme este exemplo, o segredo é marcado para eliminação. Caso contrário, não é.

      apiVersion: v1
      data:
        password: KFZbQTJdYjIwSUtVVV1aNytJJVM=
        username: cm9vdC1sdmwy
      immutable: true
      kind: Secret
      metadata:
        annotations:
          cluster-name: aa-aa-stge01
        creationTimestamp: "2022-12-21T05:03:02Z"
        deletionGracePeriodSeconds: 0
        deletionTimestamp: "2022-12-21T14:42:13Z"
        finalizers:
        - ontap.storage.private.gdc.goog/breakglass-finalizer
        labels:
          breakglass-secret: "true"
        name: storage-root-level2
        namespace: gpc-system
        resourceVersion: "591897"
        uid: 6f331f8a-bf48-4d59-9725-6c99c5e766f7
      type: Opaque
      
      

2. Rode o segredo depois de o usar para aceder ao ONTAP:

   1. Verifique se a credencial de parceiro existe e não está marcada para eliminação. Não avance e volte a estes passos no futuro se estiver marcado para eliminação.

   2. Se o segredo de nível 2 estiver a ser alternado, o segredo do parceiro tem de ser marcado como persistente adicionando a anotação disk.gdc.goog/persisted:

      kubectl annotate secrets
      <secret_name> -n gpc-system disk.gdc.goog/persisted=''
      

   3. Elimine o segredo do cluster através do seguinte:

      kubectl delete
      secret <secret_name> -n gpc-system
      

   4. Neste momento, o processo de eliminação é iniciado (e pode ser confirmado ao verificar se o segredo está marcado para eliminação). A eliminação e a regeneração do segredo podem demorar quase uma hora.

Rode os certificados de administrador de armazenamento e SVM

Estes certificados são os certificados do servidor instalados no sistema ONTAP pela GDC.

Existe um certificado para o administrador de armazenamento, também conhecido como a conta de administrador do cluster. O nome tem o prefixo do nome do anfitrião do sistema ONTAP e tem um hash exclusivo no final. Está instalado no servidor virtual de administração do cluster. O GDC usa este certificado internamente para tarefas administrativas.

Também existem vários certificados do lado do servidor definidos para SVMs ONTAP. Estes estabelecem a autenticidade para os clientes que falam com as SVMs.

Todos os certificados podem ser rodados através do mesmo processo. Devido a uma incompatibilidade do certificado de CA raiz no cluster de administrador principal, para os certificados de cluster e SVM, que estão listados nas tabelas seguintes, a rotação requer a rotação de todos os certificados na respetiva lista. Isto significa que, se for necessário rodar um certificado de cluster, todos os outros certificados de cluster também têm de ser rodados. O mesmo se aplica aos certificados SVM. Esta limitação vai ser resolvida assim que a gestão de certificados automática for implementada.

Pré-requisitos

• Acesso de administrador ao cluster ONTAP ou às SVMs relevantes
• Acesso kubectl aos clusters do Kubernetes adequados
• Reinstale os certificados da AC do cliente descritos nos passos de instalação dos certificados da AC do cliente.

Mapeamento entre certificados e secrets do Kubernetes

Para cada certificado instalado no ONTAP, existe um segredo do Kubernetes correspondente no servidor da API Management que contém os detalhes do certificado. O GDC gera os certificados e o processo de substituição de um certificado é simples: elimine o segredo que corresponde a um determinado certificado e o certificado é regenerado imediatamente. Em seguida, esse novo certificado pode ser instalado manualmente no ONTAP, substituindo o antigo.

Use kubectl get secrets -n <namespace> -s <secret> -o yaml para inspecionar o certificado no Kubernetes e verificar se corresponde aos detalhes no ONTAP vistos a partir de security certificate show -vserver <svm_name>. O espaço de nomes é sempre "gpc-system" e pode consultar a tabela seguinte para ver o nome do segredo.

Também pode ver o mapeamento do certificado para o segredo verificando o seguinte:

kubectl get certificates -n <namespace>

Certificados de cluster relevantes

Nome comum do ONTAP	Vserver	Nome do certificado K8S	Nome do segredo do Kubernetes	Descrição
N/A	<hostname>	<hostname>-admin-cert	<hostname>-admin-cert-secret	Certificado de administrador do cluster
N/A	<hostname>	<hostname>-server-cert	<hostname>-server-cert-secret	Certificado do servidor assinado pelo emissor GDC usado como certificado do servidor ONTAP
N/A	<hostname>	<hostname>-read-only-cert	<hostname>-read-only-cert-secret	Acesso de monitorização só de leitura

Certificados SVM relevantes

Vserver	Nome do certificado K8S	Nome do segredo do Kubernetes	Descrição
root-admin	root-admin-server-cert	root-admin-server-cert-secret	Certificado do servidor assinado pelo emissor GDC usado como certificado do servidor SVM
root-admin	root-admin-s3-server-cert	root-admin-s3-server-cert-secret	Certificado do servidor assinado pelo emissor GDC usado como certificado do servidor ONTAP S3
root-admin	root-admin-client-cert	root-admin-client-cert-secret	Acesso de administrador do SVM
root-admin	root-admin-s3-identity-client-cert	root-admin-s3-identity-client-cert-secret	Acesso à identidade do S3

Validação

Certificado do servidor virtual

Após a rotação de todos os certificados, verifique se o back-end do Trident continua a estar ligado com êxito para todos os clusters associados ao certificado do servidor que foi rodado.

1. Execute o seguinte:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get tridentbackendconfigs -n netapp-trident
   

   O resultado deve ter o seguinte aspeto:

   NAME                                   BACKEND NAME   BACKEND UUID                           PHASE   STATUS
   netapp-trident-backend-tbc-ontap-san   iscsi-san      a46ce1c7-26da-42c9-b475-e5e37a0911f8   Bound   Success
   

2. Verifique se o PHASE está Associado e o Status está Êxito.

Certificado de administrador de raiz

Para testar o certificado de administrador, podemos criar uma nova StorageVirtualMachine de teste e ver que o GDC consegue reconciliá-la adequadamente. Os passos para tal são os seguintes:

1. Liste as StorageVirtualMachines existentes e escolha uma para clonar como teste.
2. Extraia a especificação do Kubernetes para o mesmo.
3. Edite a definição para alterar o nome e eliminar campos desnecessários.
4. Aplicar a definição do teste.
5. Aguarde que o estado da StorageVirtualMachine se torne Ready.
6. Elimine o StorageVirtualMachine de teste.
7. Elimine o SVM real do ONTAP.

Exemplo

Este exemplo usa um espaço de nomes do GDC NetApp gpc-system e clona-o organization-root-user temporariamente para um novo SVM denominado test-svm.

1. List SVMs:

   kubectl get storagevirtualmachines -n ngpc-system
   

   Saída:

   NAME                      AGE
   organization-root-admin   13d
   

2. Extraia a especificação:

   kubectl get storagevirtualmachines -n gpc-system -o yaml > svm.yaml
   

3. Edite a especificação para que se assemelhe ao seguinte:

   apiVersion: system.gpc.gke.io/v1alpha1
   kind: StorageVirtualMachine
   metadata:
     labels:
       ontap.storage.gpc.gke.io/role: user
     name: test-svm
     namespace: netapp-alatl12-gpcstge02
   spec:
     aggregates:
     - alatl12-gpcstge02-c1-aggr1
     - alatl12-gpcstge02-c2-aggr1
     clusterName: alatl12-gpcstge02
     iscsiTarget:
       port: a0a-4
       subnetName: root-svm-data
     nasServer:
       port: a0a-4
       subnetName: root-svm-data
     svmNetwork:
       port: e0M
       subnetName: Default
   

4. Aplique-o ao cluster:

   kubectl create -f svm.yaml
   

5. Aguarde até que a nova SVM fique pronta. Observe periodicamente o resultado de:

   kubectl get storagevirtualmachines -n gpc-system test-svm
   

   O sucesso é indicado por:

     Conditions:
       Last Transition Time:  2022-03-30T21:30:27Z
       Message:
       Observed Generation:   1
       Reason:                SVMCreated
       Status:                True
       Type:                  Ready
   

   ou AnsibleJobSucceed.

6. Elimine o recurso SVM:

   kubectl delete storagevirtualmachines -n gpc-system test-svm
   

7. Elimine-o completamente do ONTAP. A eliminação do recurso não o remove do ONTAP.

   Inicie sessão na consola NetApp e elimine o SVM:

   alatl12-gpcstge02::> vserver delete test-svm
   

   Saída:

   Warning: When Vserver "test-svm" is deleted,
           the following objects are automatically removed as well:
           LIFs: 7
           Routes: 2
           Admin-created login accounts: 2
           Do you want to continue? {y|n}: y
   [Job 3633] Success
   

Use as instruções seguintes para rodar manualmente o certificado ONTAP se encontrar algum erro durante a validação.

Instruções

Se o nome do certificado ONTAP anterior não for aplicável, não é necessário rodar nada no ONTAP. Inspeccione o certificado e o secret no Kubernetes e elimine o secret.

1. Gere um novo certificado, fazendo referência à tabela anterior para o nome do segredo:

   kubectl get certificates -n <namespace>
   

   $ kubectl patch Certificates <cert_name> -n gpc-system \
    --type=merge -p "{\"spec\":{\"privateKey\": {\"rotationPolicy\": \"Always\"}}}"
   $ kubectl delete secret -n <namespace> <secret_name>
   

2. Veja os certificados instalados para um determinado vserver, para certificados instalados no ONTAP (não marcados como não aplicáveis):

   cluster::> security certificate show -vserver <svm_name> -type server
   

3. Inspecione o segredo correspondente no Kubernetes (consulte a tabela anterior):

   kubectl get certificates -n <namespace>
   

4. Quando estiver satisfeito com a correspondência, gere um novo certificado eliminando o segredo:

   kubectl delete secret -n <namespace> <secret_name>
   

5. Volte a inspecionar o segredo para ver que foi regenerado um novo certificado. Depois de confirmar, crie um novo certificado de servidor no ONTAP. Só execute os passos seguintes para os certificados precedentes com o sufixo "server-cert".

6. Extraia o novo corpo do certificado TLS através do kubectl e de outras ferramentas diretamente e instale-o no ONTAP:

   $ gdch_cert_details -n <namespace> -s <secret_name>
   
   cluster::> security certificate install -vserver <svm_name> -type server
   

   O primeiro comando é:

   Please enter Certificate: Press <Enter> when done

   No qual deve introduzir tls.crt. Caso existam vários blocos de certificados em tls.crt, introduza o primeiro bloco e mantenha os restantes blocos de certificados como certificados intermédios para referência no passo seguinte.

7. O sistema apresenta a mensagem: Please enter Private Key: Press <Enter> when done. Cole o conteúdo do ficheiro tls.key e prima Enter.

   Em seguida, é apresentado o seguinte pedido: Do you want to continue entering root and/or intermediate certificates {y|n}: Se o ficheiro tls.crt contiver apenas um certificado, escreva N e prima Enter. Caso contrário, escreva Y e prima Enter.

   Se tiver escrito Y: é-lhe pedido que introduza certificados intermédios. Cole-os um de cada vez a partir do ficheiro tls.crt, premindo Enter após cada um. Por fim, cole o certificado de raiz do ficheiro ca.crt e prima Enter.

   Se escreveu N: (não é necessária nenhuma ação adicional relativamente aos certificados neste comando)

   Em seguida, o ONTAP devolve um número de série. Registe este número, uma vez que representa o número de série do novo certificado e CA. Este número de série vai ser referido como <new\_server\_serial> e <new\_ca> nos passos seguintes. Não siga estes passos de certificado se estiver a configurar um certificado do servidor S3.

8. Veja o estado atual das configurações SSL para o servidor virtual e o cluster. Tenha à mão a CA de emissão do certificado do servidor, o nome comum do certificado do servidor e o número de série do certificado do servidor, uma vez que estes serão referidos como <old\_server\_common\_name>, <old\_ca> e <old\_server\_serial>, respetivamente:

   cluster::> security ssl show -vserver <vserver>
   

   Isto devolve as informações SSL com as informações do certificado do servidor antigo. Pode consultar estas informações mais tarde para se certificar de que foram atualizadas depois de modificar a configuração SSL.

9. Modifique a configuração SSL:

   cluster::> security ssl modify -server-enabled -client-enabled true -vserver <svm_name> -serial <new_server_serial> -ca <new_ca>
   

10. Veja o novo estado das configurações SSL para o servidor virtual e o cluster. Este deve ter o número de série atualizado do certificado do servidor agora instalado:

    cluster::> security ssl show -vserver <vserver>
    

11. Elimine o certificado do servidor antigo após validar o passo anterior:

    cluster::> security certificate delete -vserver <svm_name> -common-name <old_server_common_name> -ca <old_ca> -type server -serial <old_server_serial>
    

Certificados de AC de cliente

1. Obtenha todos os certificados da AC do trust-store-internal-only ConfigMap no espaço de nomes gpc-system através do seguinte comando:

   kubectl get cm -n gpc-system trust-store-internal-only -o jsonpath='{.data.ca\.crt}'
   

2. Para cada certificado de AC obtido no passo anterior, execute o seguinte comando no cluster ONTAP:

   cluster::> security certificate install -vserver <svm_name> -type client-ca
   

   É-lhe pedido: Please enter Certificate: Press <Enter> when done. Cole cada bloco de certificado obtido no passo 1 e prima Enter. Repita este comando de instalação para cada certificado da AC.

Rode os certificados de recolha

A geração de certificados de colheita depende de <hostname>-read-only-cert-secret. Certifique-se de que o <hostname>-read-only-cert-secret está rodado antes de continuar.

1. Veja os certificados instalados para o pod Harvest:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   cluster_name="$(kubectl get storagecluster -A -o jsonpath='{.items[0].metadata.name}')"
   secret_name="$cluster_name"-read-only-cert-secret
   

   export TLS_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.crt}')"
   

   export TLS_KEY="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.key}')"
   

   export CA_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.ca\.crt}')"
   

2. Aplique uma correção ao secret das credenciais de recolha para fornecer os certificados atualizados:

   $ kubectl patch secret \
   -n gpc-system netapp-harvest-configuration-credential \
   -p "{\"data\":{\"tls.crt\":\"${TLS_CRT:?}\",\"tls.key\":\"${TLS_KEY:?}\",\"ca.crt\":\"${CA_CRT:?}\"}}"
   

3. Reinicie o serviço de recolha para carregar a configuração atualizada:

   kubectl delete pod -n gpc-system -l 'app=harvest.netapp.io'
   

Rode certificados do sistema de ficheiros

Execute o seguinte comando para regenerar o certificado file-storage-webhooks-serving-cert e o certificado file-observability-backend-target-cert

kubectl delete secret file-storage-webhooks-serving-cert -n file-system
kubectl delete secret file-observability-backend-target-cert -n file-system

Reinicie os pods para carregar a configuração atualizada:

kubectl delete pod -n file-system -l 'app=file-observability-backend-controller'
kubectl delete pod file-storage-backend-controller -n file-system

Rode os certificados do Trident e do ONTAP

O Trident tem de comunicar com o ONTAP. Esta opção é configurada com o back-end do Trident, que usa o certificado de cliente <svm\_name>-client-cert-secret> definido anteriormente. A rotação de certificados de cliente não faz parte do Trident, mas o Trident depende de partes deste certificado, que têm de ser atualizadas.

Instruções

Para a atualização do certificado de AC:

1. Exporte KUBECONFIG para apontar para o kubeconfig do cluster específico dos componentes do Trident em questão. Cada cluster tem o Trident configurado.

2. Obtenha o certificado de AC, codificado em base64, a partir do segredo do certificado do cliente e armazene-o como uma variável:

   ca_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.ca\.crt}')
   

3. Aplique uma patch ao objeto tridentBackendConfig:

   kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"trustedCACertificate\":\"$ca_cert\"}}"
   

Para o certificado e a chave do cliente reais:

1. Obtenha o certificado TLS, codificado em base64 a partir do segredo do certificado do cliente, e armazene-o como uma variável:

   tls_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.crt}')
   

2. Obtenha a chave TLS, codificada duas vezes em base64 a partir do segredo client-cert e armazene-a como uma variável:

   tls_key=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.key}' | base64 -w 0)
   

3. Atualize o segredo do back-end com a chave privada:

   kubectl patch secrets netapp-trident-backend-tbc-ontap -n netapp-trident --type=merge -p "{\"data\":{\"clientPrivateKey\": \"$tls_key\"}}"
   

4. Aplique a configuração de back-end com o certificado TLS:

   kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"clientCertificate\":\"$tls_cert\"}}"
   

Rode os certificados do controlador Trident

Os contentores do Trident têm de comunicar com o operador do Trident. Esta comunicação é feita através de HTTPS, e os certificados do servidor e do cliente têm de ser geridos como parte deste processo.

Validação

Confirme se o daemonset e a implementação (quando aplicável) são apresentados num estado normal.

Use as instruções seguintes para rodar manualmente os certificados do servidor e do cliente se encontrar algum erro durante a validação.

Instruções

Nenhum dos certificados do servidor e do cliente tem um certificado correspondente no lado do ONTAP. Estes estão estritamente contidos nos clusters.

1. Elimine o segredo correspondente ao certificado que está a expirar.

   kubectl delete secret -n netapp-trident <secret_name>
   

2. Reinicie o conjunto de daemon netapp-trident-csi:

   kubectl rollout restart daemonset netapp-trident-csi -n netapp-trident
   

3. Para rotações de certificados de servidor, também tem de reiniciar a implementação de netapp-trident-csi:

   kubectl rollout restart deployments netapp-trident-csi -n netapp-trident
   

Certificado da AC Trident

O certificado da AC é usado para fornecer a autoridade de certificação para assinar os certificados do servidor e do cliente do Trident.

Nome do certificado	Espaço de nomes	Secreto	Descrição
netapp-trident-csi-cert	netapp-trident	netapp-trident-csi-cert	Certificado da AC Trident

Validação

Verifica que o segredo é regenerado. Para que os certificados do cliente e do servidor entrem em vigor, também pode seguir a rotação dos certificados do controlador Trident nas instruções anteriores após a rotação deste certificado.

Use as instruções seguintes para rodar manualmente o certificado da AC se encontrar algum erro durante a validação.

Instruções

Para rodar esta chave, só tem de eliminar o segredo do Kubernetes:

kubectl delete secret -n netapp-trident <secret_name>

Nós CSI e SVMs do Trident (dados)

Este é um conjunto de credenciais CHAP iSCSI ao nível do SVM para permitir o acesso ao plano de dados para acesso a blocos. Isto não se aplica a protocolos de ficheiros.

Servidor da API Management

Espaço de nomes	Secreto	Descrição
gpc-system	<organization>-<type>-svm-credential	Configuração de SVM necessária para a configuração do Trident

Administrador da organização e servidor da API Management

Espaço de nomes	Secreto	Descrição
gpc-system	<organization>-<type>-svm-credential	Configuração de SVM necessária para a configuração do Trident
netapp-trident	netapp-trident-backend-tbc-ontap	É necessário um segredo para gerir o back-end do Trident

Validação

1. Verifique se o back-end ainda está configurado com êxito:

   #export kubeconfig of org cluster
   export KUBECONFIG= #path to root-admin kubeconfig
   
   kubectl get tridentBackendConfigs -n netapp-trident
   

2. Verifique se o estado do back-end é Success.

Use as instruções seguintes para rodar manualmente os segredos se encontrar algum erro durante a validação.

Instruções

Gere uma nova string aleatória de 16 carateres sem carateres especiais para o segredo do iniciador e o segredo do iniciador de destino:

#export kubeconfig of Management API server
export KUBECONFIG= #path to root-admin kubeconfig

initiator_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

target_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

kubectl patch secrets -n gpc-system "$org-$type-svm-credential" --type=merge -p "{\"data\":{\"initiatorSecret\": \"$initiator_secret\", \"targetSecret\": \"$target_secret\"}}"

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl patch secrets -n netapp-trident netapp-trident-backend-tbc-ontap --type=merge -p "{\"data\":{\"chapInitiatorSecret\": \"$initiator_secret\", \"chapTargetInitiatorSecret\": \"$target_secret\"}}"

Chave AES do Trident

A chave AES é usada internamente pelo Trident para encriptar as credenciais CHAP iSCSI para utilização interna do Trident. É uma sequência aleatória de carateres que tem de ter 32 bytes de comprimento.

Cluster que executa o Trident (pode ser um cluster root/org-admin/user/system)

Espaço de nomes	Secreto	Descrição
netapp-trident	netapp-trident-aes-key	Chave AES necessária pelo Trident para encriptar as credenciais CHAP iSCSI

Validação

1. Verifique se o back-end ainda está configurado com êxito:

   #export kubeconfig of org cluster
   export KUBECONFIG= #path to root-admin kubeconfig
   
   kubectl get tridentBackendConfigs -n netapp-trident
   

2. Verifique se o estado do back-end é Success.

3. Tente criar um volume de teste:

   1. Crie um ficheiro YAML com as informações de PVC:

      echo "
      kind: PersistentVolumeClaim
      apiVersion: v1
      metadata:
        name: block-pvc
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 5Gi
        storageClassName: standard-rwo" > pvc.yaml
      

   2. Aplique-o ao cluster Kubernetes:

      kubectl apply -f pvc.yaml
      

4. Verifique se não existem erros nos registos de CSI devido à encriptação iSCSI:

   kubectl logs deploy/netapp-trident-csi -n netapp-trident -c trident-main | grep "Error encrypting"
   

   Se não existirem erros, não são devolvidos registos.

5. Limpe o ficheiro e o PVC:

   kubectl delete -f pvc.yaml
   rm -f pvc.yaml
   

Use as instruções seguintes para alternar manualmente a chave se encontrar algum erro durante a validação.

Instruções

Antes de rodar esta chave, certifique-se de que não existem pods pendentes com volumes persistentes no cluster. Se existirem, aguarde que sejam totalmente aprovisionados antes de rodar a chave.

Gere uma nova string aleatória de 32 carateres sem carateres especiais para a aesKey:

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

aes_key=$(head /dev/random | tr -dc A-Za-z0-9 | head -c32 | base64)

#save old key just in case of errors
old_key=$(kubectl get secrets -n netapp-trident "netapp-trident-aes-key" -o jsonpath='{.data.aesKey}')

kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$aes_key\"}}"

kubectl rollout restart deployment netapp-trident-csi -n netapp-trident

Reversão

1. Reverter para as credenciais usadas mais recentemente se existirem erros:

   kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$old_key\"}}"
   
   kubectl rollout restart deployment netapp-trident-csi -n netapp-trident
   

2. Refaça os passos de validação.