Alternar chaves e certificados de autenticação de armazenamento

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

Este documento descreve as etapas para girar as chaves e os certificados de autenticação que precisam ser executados para:

• rotação de chaves programada regularmente para garantir que o dispositivo esteja em conformidade e seguro.
• exposição de chaves. Gire a chave exposta assim que possível.

Antes de começar

Verifique se você tem o seguinte acesso:

• Acesso ao Admin Console do cluster ONTAP
• Kubeconfig para o servidor da API Management

Alternar credenciais IPsec (PSK)

O ONTAP oferece suporte à autenticação com base em certificado para IPsec a partir da versão 9.10.1. Esta versão do GDC é a 9.14.1 e usa chaves pré-compartilhadas.

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

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

Vamos falar sobre cada uma delas separadamente.

Pré-requisitos

• Acesso ao Admin Console do cluster ONTAP
• Uma nova chave pré-compartilhada
• Kubeconfig para o servidor da API Management
• Acesso aos hosts para atualizar a configuração do StrongSwan

Impacto

Enquanto as políticas de IPsec são alternadas, os hosts sofrem uma perda de conectividade IP com o sistema de armazenamento. As conexões vão parar ou talvez falhem dependendo do comportamento do aplicativo. Se possível, pause as cargas de trabalho do usuário durante a rotação, mas isso não é obrigatório. As conexões devem ser recuperadas logo após a redefinição dos secrets.

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

Para validar a rotação, use o comando a seguir e compare a saída:

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 host específico em que você executou o script anteriormente.

Gire 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. Confira e copie a senha para a área de transferência:

   echo $password
   

3. Faça login no console do ONTAP:

   ssh $username@$mgmt_ip
   

   Quando solicitado, cole a senha copiada da etapa anterior.

4. Use o seguinte script para 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 host que você quer girar, execute 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 se todos os componentes da conexão de criptografia de armazenamento aparecem. Para conexões de cluster de administrador, seja root-admin ou organization-admin, use o cluster root-admin.

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

   Se os dois itens estiverem presentes, siga para a próxima etapa. Caso contrário, pare e não continue modificando o ipsec. Entre em contato com o suporte técnico.

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

   Agora use o servidor da API Management para excluir 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 comando a seguir e compare a saída:

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 todos os jobs estão no status 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

Verifique se o campo READY é verdadeiro para todos os hosts.

1. Exclua todas as CRs na etapa 2 na ordem listada

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

   • Exclua todos os três jobs de política de 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

   • Exclua todos os 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 a etapa 2 até que todos os CRs estejam no status "PRONTO" ou "Concluído".

Girar as teclas de volume

Nesta seção, descrevemos as etapas manuais para fazer a rotação das credenciais de volume do OTS.

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 console do cluster do OTS usando BM01 ou BM02.

Iniciar a rotação de chaves de volume

No console do OTS, acione a rotação única de chaves:

volume encryption rekey start -vserver SVM_name -volume volume_name

O comando a seguir muda a chave de criptografia de vol1 em SVMvs1:

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

Para conferir os nomes dos vservers e dos volumes, use o comando show:

vserver show
volume show

Verificar a rotação de chaves de volume

Depois que a rotação de chaves for iniciada, verifique o status da nova chave:

volume encryption rekey show

Mostre o status da operação de nova 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 recriptografia for concluída, verifique se o volume está ativado para criptografia:

volume show -is-encrypted true

Mostre os volumes criptografados 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%

Alternar certificados de HSM externo

Nesta seção, descrevemos como alternar e atualizar os certificados do HSM externo para o ONTAP.

Pré-requisitos

• Acesso de administrador ao cluster do ONTAP ou às SVMs relevantes
• Senha atual
• acesso do kubectl aos clusters adequados

Instruções

1. Faça backup dos certificados antigos do HSM:

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

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

   1. Copie o arquivo YAML secreto antigo: sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

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

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

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

3. Atualize os certificados do HSM no ONTAP:

   1. Faça login na CLI do ONTAP.

   2. Instale o novo certificado de CA do servidor:

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

   3. Instale o novo certificado do cliente:

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

   4. Atualize a configuração do gerenciador de chaves para usar os certificados recém-instalados:

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

Validação

1. Verifique a mudança com o status do gerenciador de chaves:

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

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

Alternar credenciais de administrador de armazenamento

Esta seção descreve como alternar e definir o usuário e a senha de administrador de armazenamento.

Pré-requisitos

• Acesso de administrador ao cluster do ONTAP ou às SVMs relevantes
• Senha atual
• acesso do kubectl aos clusters adequados

Instruções

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

   cluster::> security login password
   

2. Atualize o secret para corresponder a:

   • Opção 1 (interativa):

     kubectl edit secret -n <netapp_namespace> netapp_credential
     

     Use o editor para mudar a senha para o novo valor codificado em base64.

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

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

Alternar as credenciais de acesso de emergência do ONTAP

Durante a configuração do armazenamento de arquivos e blocos, quatro contas de usuário para acesso de emergência são criadas e podem ser usadas para acessar o ONTAP diretamente. Essas credenciais podem ser obtidas como secrets no servidor da API Management. Depois que essas credenciais forem usadas, elas precisarão ser rotacionadas.

Dois tipos de secrets são criados 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 precisam ser armazenados no cofre, e cada nível tem dois segredos, um normal e um de backup. Embora o software processe a exclusão de secrets normais e de backup simultaneamente, recomendamos girar apenas um desses secrets de parceiro por vez como uma camada extra de segurança.

Enquanto os secrets de nível 1 são alternados automaticamente após um período de 90 dias, os de nível 2 não são. Qualquer tipo de segredo precisa ser substituído manualmente usando o processo a seguir, se ele for usado.

Pré-requisitos

• Acesso necessário: servidor da API Management

Validação

1. Para validar a rotação de secrets, verifique se o secret ainda está marcado para exclusão. Caso contrário, a rotação já foi feita. Siga a etapa 1 das instruções abaixo para verificar.

2. Se o secret for de nível 2, copie-o em uma mídia física e armazene no cofre. Em seguida, o secret precisa ser marcado como persistente usando a anotação "disk.gdc.goog/persisted".

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

Siga estas instruções para fazer a rotação manual do secret se encontrar algum erro durante a validação.

Instruções

1. Verifique se um secret está marcado para exclusão:

   1. Execute este comando:

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

   2. Se o campo deletionTimestamp estiver presente na resposta, conforme este exemplo, o secret será marcado para exclusão. Caso contrário, não será.

      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. Gire o secret depois de usá-lo para acessar o ONTAP:

   1. Verifique se a credencial do parceiro existe e não está marcada para exclusão. Não prossiga e volte a estas etapas no futuro se ele estiver marcado para exclusão.

   2. Se o secret de nível 2 estiver sendo rotacionado, o secret do parceiro precisará ser marcado e persistido adicionando a anotação disk.gdc.goog/persisted:

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

   3. Exclua o secret do cluster usando o seguinte:

      kubectl delete
      secret <secret_name> -n gpc-system
      

   4. Nesse ponto, o processo de exclusão vai começar (e pode ser confirmado verificando se o segredo está marcado para exclusão). Pode levar quase uma hora para o secret ser excluído e regenerado.

Alternar certificados de administrador de armazenamento e SVM

Esses certificados são os certificados do servidor instalados no sistema ONTAP pelo GDC.

Há um certificado para o administrador de armazenamento, também conhecido como conta de administrador do cluster. O nome é prefixado com o nome do host do sistema ONTAP e tem um hash exclusivo final. Ele é instalado no vserver de administrador do cluster. O GDC usa esse certificado internamente para tarefas administrativas.

Há também vários certificados do lado do servidor definidos para SVMs do ONTAP. Elas estabelecem a autenticidade dos clientes que conversam com as SVMs.

Todos os certificados podem ser rotacionados usando o mesmo processo. Devido a uma incompatibilidade de certificado de CA raiz no cluster root-admin, para certificados de cluster e SVM, listados nas tabelas a seguir, a rotação exige a rotação de todos os certificados na respectiva lista. Isso significa que, se um certificado do cluster precisar ser alternado, todos os outros também precisarão ser. O mesmo se aplica aos certificados SVM. Essa limitação será resolvida quando o gerenciamento automatizado de certificados for implementado.

Pré-requisitos

• Acesso de administrador ao cluster do ONTAP ou às SVMs relevantes
• Acesso do kubectl aos clusters do Kubernetes adequados
• reinstale os certificados client-ca descritos nas etapas de instalação de certificados client-ca.

Mapeamento entre certificados e secrets do Kubernetes

Para cada certificado instalado no ONTAP, há um secret correspondente do Kubernetes no servidor da API Management que contém os detalhes do certificado. O GDC gera os certificados, e o processo para substituir um certificado é simples: exclua o secret que corresponde a um determinado certificado, e o certificado será regenerado imediatamente. 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 ele corresponde aos detalhes no ONTAP vistos em security certificate show -vserver <svm_name>. O namespace será sempre "gpc-system", e você pode consultar a tabela a seguir para conferir o nome do secret.

Você também pode conferir o mapeamento de certificado para chave secreta verificando:

kubectl get certificates -n <namespace>

Certificados de cluster relevantes

Nome comum do ONTAP	Vserver	Nome do certificado K8S	Nome do secret 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 da GDC usado como o certificado do servidor ONTAP
N/A	<hostname>	<hostname>-read-only-cert	<hostname>-read-only-cert-secret	Acesso de monitoramento somente leitura

Certificados relevantes do SVM

Vserver	Nome do certificado K8S	Nome do secret do Kubernetes	Descrição
root-admin	root-admin-server-cert	root-admin-server-cert-secret	Certificado do servidor assinado pelo emissor do GDC usado como o certificado do servidor SVM
root-admin	root-admin-s3-server-cert	root-admin-s3-server-cert-secret	Certificado do servidor assinado pelo emissor do GDC usado como o certificado do servidor S3 do ONTAP
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 Vserver

Depois que todos os certificados forem substituídos, verifique se o back-end do Trident ainda está conectado corretamente para cada cluster associado ao certificado do servidor substituído.

1. Execute o seguinte:

   export KUBECONFIG= #path to root-admin kubeconfig
   

   kubectl get tridentbackendconfigs -n netapp-trident
   

   A saída será semelhante a esta:

   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 é Bound e se o Status é Success.

Certificado de administrador raiz

Para testar o certificado de administrador, podemos criar uma nova StorageVirtualMachine de teste e verificar se o GDC consegue reconciliá-la adequadamente. As etapas para isso são as seguintes:

1. Liste as StorageVirtualMachines atuais e escolha uma para clonar como teste.
2. Extraia a especificação do Kubernetes para ele.
3. Edite a definição para mudar o nome e excluir campos desnecessários.
4. Aplique a definição do teste.
5. Aguarde até que o status do StorageVirtualMachine seja Ready.
6. Exclua a StorageVirtualMachine de teste.
7. Exclua a SVM real do ONTAP.

Exemplo

Este exemplo usa um namespace do GDC NetApp gpc-system e clona o organization-root-user temporariamente para uma nova SVM chamada test-svm.

1. Listar 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 fique semelhante a isto:

   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 ao cluster:

   kubectl create -f svm.yaml
   

5. Aguarde até que a nova SVM esteja pronta. Observe periodicamente a saída 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. Exclua o recurso de SVM:

   kubectl delete storagevirtualmachines -n gpc-system test-svm
   

7. Exclua completamente do ONTAP. A exclusão do recurso não o remove do ONTAP.

   Faça login no console da NetApp e exclua a 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
   

Siga as instruções abaixo para fazer a rotação manual do 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 será necessário fazer a rotação de nada no ONTAP. Inspecione o certificado e o secret no Kubernetes e exclua o secret.

1. Gere um novo certificado, referenciando a tabela anterior para o nome do secret:

   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. Confira os certificados instalados em 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 secret correspondente no Kubernetes (consulte a tabela anterior):

   kubectl get certificates -n <namespace>
   

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

   kubectl delete secret -n <namespace> <secret_name>
   

5. Inspecione novamente o secret para ver se um novo certificado foi regenerado. Depois disso, crie um novo certificado de servidor no ONTAP. Só siga as etapas abaixo para os certificados anteriores com o sufixo "server-cert".

6. Extraia o corpo do novo certificado TLS usando kubectl e 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 será:

   Please enter Certificate: Press <Enter> when done

   Insira tls.crt. Se houver vários blocos de certificado em tls.crt, insira o primeiro bloco e mantenha os blocos restantes como certificados intermediários para referência na próxima etapa.

7. O sistema vai pedir: Please enter Private Key: Press <Enter> when done. Cole o conteúdo do arquivo tls.key e pressione Enter.

   Em seguida, vai aparecer a seguinte mensagem: Do you want to continue entering root and/or intermediate certificates {y|n}: Se o arquivo tls.crt contiver apenas um certificado, digite N e pressione Enter. Caso contrário, digite Y e pressione Enter.

   Se você digitou Y:será solicitado que você insira certificados intermediários. Cole uma de cada vez do arquivo tls.crt, pressionando Enter após cada uma. Por fim, cole o certificado raiz do arquivo ca.crt e pressione "Enter".

   Se você digitou N:nenhuma outra ação é necessária em relação aos certificados neste prompt.

   O ONTAP vai retornar um número de série. Anote esse número, porque ele representa o número de série do novo certificado e da CA. Esse número de série será chamado de <new\_server\_serial> e <new\_ca> nas etapas seguintes. Não siga estas etapas de certificado se você estiver configurando um certificado do servidor S3.

8. Confira o estado atual das configurações de SSL para o vserver e o cluster. Tenha em mãos a CA emissora do certificado do servidor, o nome comum do certificado do servidor e o número de série do certificado do servidor, já que eles serão chamados de <old\_server\_common\_name>, <old\_ca> e <old\_server\_serial>, respectivamente:

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

   Isso retorna as informações de SSL com as informações do certificado do servidor antigo. Você pode consultar isso mais tarde para garantir que ele foi atualizado depois de modificar a configuração de SSL.

9. Modifique a configuração de SSL:

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

10. Confira o novo estado das configurações de SSL para o vserver e o cluster. Ele precisa ter o número de série atualizado do certificado do servidor agora instalado:

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

11. Exclua o certificado do servidor antigo depois de verificar a etapa 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 CA do cliente

1. Extraia todos os certificados da CA do ConfigMap trust-store-internal-only no namespace gpc-system usando o seguinte comando:

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

2. Para cada certificado de CA recuperado na etapa anterior, execute o seguinte comando no cluster ONTAP:

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

   Você vai receber a seguinte solicitação: Please enter Certificate: Press <Enter> when done. Cole cada bloco de certificado recuperado na etapa 1 e pressione "Enter". Repita esse comando de instalação para cada certificado da CA.

Alternar certificados do Harvest

A geração de certificados de coleta depende de <hostname>-read-only-cert-secret. Verifique se <hostname>-read-only-cert-secret foi girado antes de continuar.

1. Confira os certificados instalados no pod do 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. Adicione um patch ao secret das credenciais do Harvest 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 coleta para carregar a configuração atualizada:

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

Alternar certificados do sistema de arquivos

Execute o comando a seguir para regenerar o certificado file-storage-webhooks-serving-cert e 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

Girar certificados do Trident e do ONTAP

O Trident precisa se comunicar com o ONTAP. Isso é configurado com o back-end do Trident, que usa o certificado do cliente <svm\_name>-client-cert-secret> definido anteriormente. A rotação de certificados do cliente não faz parte do Trident, mas ele depende de partes desse certificado, que precisam ser atualizadas.

Instruções

Para atualização do certificado da CA:

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

2. Extraia o certificado da CA, codificado em base64 do secret client-cert, e armazene-o como uma variável:

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

3. Aplique um 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 real:

1. Extraia o certificado TLS, codificado em base64 do secret client-cert, e armazene-o como uma variável:

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

2. Extraia a chave TLS, codificada duas vezes em base64 do secret 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 secret de 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. Adicione um patch à 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\"}}"
   

Alternar certificados do controlador do Trident

Os contêineres do Trident precisam se comunicar com o operador do Trident. Essa comunicação é feita por HTTPs, e os certificados do servidor e do cliente precisam ser gerenciados como parte disso.

Validação

Confirme se o daemonset e a implantação (quando aplicável) estão em um estado íntegro.

Siga estas instruções para fazer a rotação manual dos certificados do servidor e do cliente se encontrar algum erro durante a validação.

Instruções

Os certificados do servidor e do cliente não têm um certificado correspondente no lado do ONTAP. Elas ficam estritamente contidas nos clusters.

1. Exclua o secret correspondente ao certificado que está expirando.

   kubectl delete secret -n netapp-trident <secret_name>
   

2. Reinicie o DaemonSet netapp-trident-csi:

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

3. Para rotações de certificados do servidor, também é necessário reiniciar a implantação netapp-trident-csi:

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

Certificado de CA do Trident

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

Nome do certificado	Namespace	Secret	Descrição
netapp-trident-csi-cert	netapp-trident	netapp-trident-csi-cert	Certificado da CA do Trident

Validação

O secret será regenerado. Para que os certificados do cliente e do servidor entrem em vigor, siga as instruções anteriores para girar os certificados do controlador Trident depois de girar este certificado.

Siga as instruções abaixo para fazer a rotação manual do certificado da CA se você encontrar algum erro durante a validação.

Instruções

Para fazer a rotação dessa chave, basta excluir o secret do Kubernetes:

kubectl delete secret -n netapp-trident <secret_name>

Nós e SVMs (dados) do Trident CSI

Esse é um conjunto de credenciais CHAP iSCSI em toda a SVM para permitir o acesso ao plano de dados para acesso por blocos. Isso não se aplica a protocolos de arquivo.

Servidor da API Management

Namespace	Secret	Descrição
gpc-system	<organization>-<type>-svm-credential	Configuração da SVM necessária para a configuração do Trident

Administrador da organização e servidor da API Management

Namespace	Secret	Descrição
gpc-system	<organization>-<type>-svm-credential	Configuração da SVM necessária para a configuração do Trident
netapp-trident	netapp-trident-backend-tbc-ontap	Secret necessário para gerenciar o back-end do Trident.

Validação

1. Verifique se o back-end ainda está configurado corretamente:

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

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

Siga as instruções abaixo para fazer a rotação manual das chaves secretas se encontrar algum erro durante a validação.

Instruções

Gere uma nova string aleatória de 16 caracteres sem caracteres 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 criptografar credenciais CHAP iSCSI para uso interno do Trident. É uma sequência aleatória de caracteres que precisa ter 32 bytes de comprimento.

Cluster que executa o Trident (pode ser clusters raiz/administrador da organização/usuário/sistema)

Namespace	Secret	Descrição
netapp-trident	netapp-trident-aes-key	Chave AES necessária pelo Trident para criptografar credenciais CHAP iSCSI.

Validação

1. Verifique se o back-end ainda está configurado corretamente:

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

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

3. Tente criar um volume de teste:

   1. Crie um arquivo YAML com as informações do PVC:

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

   2. Aplique ao cluster do Kubernetes:

      kubectl apply -f pvc.yaml
      

4. Verifique se não há erros nos registros do CSI devido à criptografia iSCSI:

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

   Se não houver erros, nenhum registro será retornado.

5. Limpe o arquivo e o PVC:

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

Siga as instruções abaixo para girar a chave manualmente se encontrar algum erro durante a validação.

Instruções

Antes de alternar essa chave, verifique se não há pods pendentes com PVs no cluster. Se houver, aguarde o provisionamento completo antes de girar a chave.

Gere uma nova string aleatória de 32 caracteres sem caracteres especiais para 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. Reverta para as últimas credenciais usadas se houver 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 as etapas de verificação.