Rotação de credenciais do Cassandra no Hashicorp Vault

Vista geral

Este procedimento descreve a rotação das credenciais do Cassandra no Hashicorp Vault. Para rodar credenciais em segredos do Kubernetes no seu cluster, consulte o artigo Rodar credenciais do Cassandra em segredos do Kubernetes.

Esta funcionalidade permite aos administradores da plataforma:

  • Rode as credenciais do Cassandra no Hashicorp Vault.
  • Reverta para as credenciais anteriores do Cassandra no Vault em caso de problemas durante a rotação da palavra-passe.
  • Rode a palavra-passe do Cassandra para uma região de cada vez, para poder garantir um impacto mínimo na disponibilidade do serviço e manter o controlo sobre o processo de rotação.
  • Acompanhar o início, o progresso e a conclusão da rotação para uma única região.

Esta funcionalidade está disponível no Apigee Hybrid 1.13.1 e posterior.

Antes de começar

Antes de configurar a rotação de credenciais:

  • Faça uma cópia de segurança da base de dados Cassandra. Esta cópia de segurança destina-se a garantir que é possível fazer a recuperação para credenciais pré-alternadas.
  • Certifique-se de que o cluster está num estado normal (ou seja, todos os recursos do Apigee estão em execução e não existem alterações de estado pendentes).

Configuração de uma única região

  1. Crie um novo recurso do SecretProviderClass Kubernetes no seu espaço de nomes do Apigee para as novas credenciais do Cassandra. Consulte o artigo Armazenar segredos do Cassandra no Hashicorp Vault para ver um modelo que pode usar. Isto permite que uma função do Vault aceda a segredos nos espaços de nomes do Kubernetes.
  2. Crie um novo recurso personalizado SecretRotation com o seguinte modelo:
    # rotation.yaml
    
    apiVersion: apigee.cloud.google.com/v1alpha1
    kind: SecretRotation
    metadata:
      name: ROTATION_PROCESS_NAME
      namespace: APIGEE_NAMESPACE
    spec:
      organizationId: ORG_NAME
      rotationId: ROTATION_ID
      timeoutMinutes: 480 # optional. overrides the default (480m == 8hr).
                          # less than or equal to 0 means infinite timeout.
      precheck: true
      cassandra:
        oldSecretProviderClass: OLD_SPC_NAME
        newSecretProviderClass: NEW_SPC_NAME
        jobType: ROTATE
    
    • ROTATION_PROCESS_NAME: um nome exclusivo para a tarefa de rotação. Tem de definir metadata.name para um valor único para a tarefa de pré-verificação da rotação e novamente para a tarefa de rotação. Por exemplo, sr-1-precheck seguido de sr-1.
    • ROTATION_ID: defina spec.rotationId como um identificador personalizado, por exemplo, rotation-1-precheck.
    • NEW_SPC_NAME: defina spec.cassandra.newSecretProviderClass para o novo nome da classe do fornecedor de segredos que criou no passo anterior.
    • OLD_SPC_NAME: defina spec.cassandra.oldSecretProviderClass para o nome do SPC que está a ser usado atualmente pelo ApigeeDatastore.
  3. Acione a tarefa de pré-verificação da rotação aplicando o ficheiro rotation.yaml.
    kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
  4. Verifique o estado da tarefa para confirmar quando a tarefa de pré-verificação estiver concluída.
    kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
  5. Quando a tarefa de pré-verificação da rotação estiver concluída, altere o valor de metadata.name e defina spec.precheck como false. Aplique novamente o ficheiro para fazer a rotação.
    kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
  6. Depois de a tarefa de rotação ser concluída e de ter validado que o tráfego continua a fluir corretamente, limpe o processo com os dois passos seguintes:
    1. Atualize o valor de metadata.name e defina spec.cassandra.jobType como CLEANUP.
    2. Aplique o ficheiro para acionar a tarefa de limpeza.
      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml

    Quando a tarefa de limpeza estiver concluída, o processo de rotação está concluído.

  7. Atualize o ficheiro de substituições e defina cassandra.auth.secretProviderClass para a nova classe de fornecedor de segredos (newSecretProviderClass).
    cassandra:
      auth:
        secretProviderClass: NEW_SPC_NAME
  8. Faça uma cópia de segurança da base de dados Cassandra. Esta cópia de segurança destina-se a garantir que a recuperação é possível para credenciais pós-rotação.
  9. Elimine as credenciais, a função e a política antigas do Cassandra do Vault.

Configuração de várias regiões

Os procedimentos de configuração multirregional estão divididos em duas secções: configuração para a primeira região e configuração para as restantes regiões.

  1. Conclua os seguintes passos na primeira região antes de iniciar as regiões subsequentes.
    1. Crie um novo recurso do SecretProviderClass Kubernetes no espaço de nomes APIGEE_NAMESPACE para as novas credenciais do Cassandra. Consulte o artigo Armazenar segredos do Cassandra no Hashicorp Vault para ver um modelo que pode usar. Isto permite que uma função do Vault aceda a segredos nos espaços de nomes do Kubernetes.
    2. Crie um novo recurso personalizado SecretRotation com o seguinte modelo:
      # rotation.yaml
      
      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: SecretRotation
      metadata:
        name: ROTATION_PROCESS_NAME
        namespace: APIGEE_NAMESPACE
      spec:
        organizationId: ORG_NAME
        rotationId: ROTATION_ID
        timeoutMinutes: -1 # this value is required and should not be changed.
        precheck: true
        cassandra:
          oldSecretProviderClass: OLD_SPC_NAME
          newSecretProviderClass: NEW_SPC_NAME
          jobType: ROTATE
      
      • ROTATION_PROCESS_NAME: um nome exclusivo para a tarefa de rotação. Tem de definir metadata.name para um valor único para a tarefa de pré-verificação da rotação e novamente para a tarefa de rotação. Por exemplo, sr-1-precheck seguido de sr-1.
      • ROTATION_ID: defina spec.rotationId como um identificador personalizado, por exemplo, rotation-1-precheck.
      • NEW_SPC_NAME: defina spec.cassandra.newSecretProviderClass para o novo nome da classe do fornecedor de segredos que criou no passo anterior.
      • OLD_SPC_NAME: defina spec.cassandra.oldSecretProviderClass para o nome do SPC que está a ser usado atualmente pelo ApigeeDatastore.
    3. Acione a tarefa de pré-verificação da rotação aplicando o ficheiro rotation.yaml.
      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
    4. Verifique o estado da tarefa para confirmar quando a tarefa de pré-verificação estiver concluída.
      kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
    5. Quando a tarefa de pré-verificação da rotação estiver concluída:
      • Altere o valor de metadata.name, por exemplo, de sr-1-precheck para sr-1.
      • Defina spec.precheck como false para desativar a pré-verificação e fazer a rotação.
      • Defina spec.rotationId como um novo identificador, por exemplo, rotation-1.
    6. Aplique novamente o ficheiro para fazer a rotação.
      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
    7. Verifique o estado do SecretRotation e aguarde até que esteja complete.
      kubectl -n APIGEE_NAMESPACE get sr SR_NAME
  2. Em cada região subsequente, conclua os seguintes passos:
    1. Crie um novo recurso do SecretProviderClass Kubernetes no seu espaço de nomes do Apigee para as novas credenciais do Cassandra. Consulte o artigo Armazenar segredos do Cassandra no Hashicorp Vault para ver um modelo que pode usar. Esta deve ser a mesma definição que no passo 1a.
    2. Atualize o elemento overrides.yaml e defina o elemento cassandra.auth.secretProviderClass para corresponder ao valor de spec.cassandra.newSecretProviderClass no ficheiro rotation.yaml.
      cassandra:
        auth:
          secretProviderClass: NEW_SPC_NAME
    3. Aplique o gráfico de operadores:
      helm upgrade operator apigee-operator/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f OVERRIDES_FILE
    4. É criado um novo ReplicaSet. Verifique se os novos pods controller-manager estão a usar o novo SPC:
      export POD=NEW_CONTROLLER_MANAGER_POD_NAME
      kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      

      O resultado deve corresponder ao valor que definiu para spec.cassandra.newSecretProviderClass em rotation.yaml, por exemplo:

      kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      
      my-new-spc
    5. Aplique o gráfico do repositório de dados:
      helm upgrade datastore apigee-datastore/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f OVERRIDES_FILE
    6. O arquivo de dados entra num estado de lançamento. Aguarde até que o arquivo de dados tenha terminado a libertação e esteja no estado de execução.
      kubectl -n APIGEE_NAMESPACE get apigeedatastore DATASTORE_NAME

      DATASTORE_NAME é default na maioria das instalações.

    7. Verifique se os novos pods de armazenamento de dados estão a usar o novo SPC:
      export POD=NEW_DATASTORE_POD_NAME
      kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      

      O resultado deve corresponder ao valor que definiu para spec.cassandra.newSecretProviderClass em rotation.yaml, por exemplo:

      kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      
      my-new-spc
    8. Aguarde até que a organização e os ambientes terminem a libertação e voltem ao estado de execução.
      kubectl -n APIGEE_NAMESPACE get apigeeorg ORG_NAME
      kubectl -n APIGEE_NAMESPACE get apigeeenv ENV_NAME
    9. Verifique se os novos pods MART, de tempo de execução e de sincronização estão a usar o novo SPC:
      export POD=NEW_MART_POD_NAME
      kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      export POD=NEW_RUNTIME_POD_NAME
      kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      export POD=NEW_SYNCHRONIZER_POD_NAME
      kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      

      O resultado deve corresponder ao valor que definiu para spec.cassandra.newSecretProviderClass em rotation.yaml, por exemplo:

      kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      
      my-new-spc
  3. Depois de concluir os passos em todas as regiões e validar que o tráfego continua a fluir corretamente, limpe o processo na primeira região com os dois passos seguintes:
    1. Na primeira região, atualize o valor de metadata.name e defina spec.cassandra.jobType como CLEANUP.
    2. Aplique o ficheiro para acionar a tarefa de limpeza.
      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
    3. Verifique o estado da tarefa e consulte os registos da tarefa para confirmar quando a tarefa de limpeza estiver concluída.

    Quando a tarefa de limpeza estiver concluída, o processo de rotação está concluído.

  4. Atualize o ficheiro de substituições e defina cassandra.auth.secretProviderClass para a nova classe de fornecedor de segredos (newSecretProviderClass).
    cassandra:
      auth:
        secretProviderClass: NEW_SPC_NAME
  5. Faça uma cópia de segurança da base de dados Cassandra. Esta cópia de segurança destina-se a garantir que a recuperação é possível para credenciais pós-rotação.
  6. Elimine as credenciais, a função e a política antigas do Cassandra do Vault.

Reverter uma rotação

Para a configuração multirregional, reverta a implementação em cada região.

  1. Crie um novo recurso personalizado SecretRotation com o seguinte modelo:
    # rollback-rotation.yaml
    
    apiVersion: apigee.cloud.google.com/v1alpha1
    kind: SecretRotation
    metadata:
      name: ROLLBACK_NAME
      namespace: APIGEE_NAMESPACE
    spec:
      organizationId: APIGEE_ORG
      rotationId: ROTATION_ID # match the current rotation.
      timeoutMinutes: TIMEOUT_MINUTES # optional.
      precheck: false
      cassandra:
        oldSecretProviderClass: OLD_SPC_NAME # Must match the previous oldSecretProviderClass.
        newSecretProviderClass: NEW_SPC_NAME # Must match the previous newSecretProviderClass.
        jobType: ROLLBACK
    

    Onde:

    • ROLLBACK_NAME: um nome para a tarefa de reversão, por exemplo: sr-1-rollback.
    • APIGEE_NAMESPACE: o seu espaço de nomes do Apigee.
    • APIGEE_ORG: o ID da sua organização do Apigee.
    • ROTATION_ID: o ID da rotação atual para a qual está a reverter, por exemplo: rot-1.
    • TIMEOUT_MINUTES: opcional. Substitui a predefinição (480 m == 8 horas). <=0 significa limite de tempo infinito.
    • OLD_SPC_NAME: tem de corresponder ao nome secreto de oldSecretProviderClass: no ficheiro YAML de rotação que usou no procedimento de configuração de região única ou configuração de várias regiões.
    • NEW_SPC_NAME: tem de corresponder ao nome secreto de newSecretProviderClass: no ficheiro YAML de rotação que usou no procedimento de configuração de região única ou configuração de várias regiões.
  2. Aplique a reversão:
    kubectl -n APIGEE_NAMESPACE apply -f ROLLBACK_YAML_FILE
    
  3. Verifique o estado da tarefa e aguarde pela conclusão.
    kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
    
  4. Quando as reversões estiverem concluídas, verifique se o tráfego continua a fluir corretamente.
  5. Para instalações multirregionais, quando o tráfego estiver a fluir corretamente, repita o processo de reversão em cada região.
  6. Depois de concluir a reversão e verificar se o tráfego continua a fluir corretamente em todas as regiões, inicie o processo de limpeza.

    Faça as seguintes alterações no ficheiro YAML de rotação:

    • Altere metadata.name para um nome que indique que se trata de uma tarefa de limpeza, por exemplo: sr-1-cleanup-rollback.
    • Alterar spec.cassandra.jobType para CLEANUP_ROLLBACK.
  7. Aplique o ficheiro para acionar a tarefa de limpeza:
    kubectl -n APIGEE_NAMESPACE apply -f ROTATION_YAML_FILE
    
  8. Verifique o estado da tarefa e aguarde pela conclusão.
    kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
    

    Quando a tarefa de limpeza estiver concluída, o processo de reversão está concluído.

  9. Atualize o ficheiro de substituições e defina cassandra.auth.secretProviderClass para a classe do fornecedor de segredos antiga (oldSecretProviderClass).
    cassandra:
      auth:
        secretProviderClass: OLD_SPC_NAME