Como fazer a rotação de credenciais do Cassandra no Hashicorp Vault

Visão geral

Com esse recurso, os administradores da plataforma podem fazer o seguinte:

  • Alternar as credenciais do Cassandra no Hashicorp Vault.
  • Reverter para as credenciais anteriores do Cassandra no Vault em caso de problemas durante a rotação de senha.
  • Alternar a senha do Cassandra para uma região por vez, garantindo o impacto mínimo na disponibilidade do serviço e mantendo o controle sobre o processo de rotação.
  • Acompanhar o início, o andamento e a conclusão da rotação de uma única região.

Esse recurso está disponível na Apigee híbrida 1.13.1 e em versões mais recentes.

Antes de começar

Antes de configurar a rotação de credenciais, siga estas etapas:

  • Faça o backup do banco de dados do Cassandra. Esse backup é para garantir que a recuperação seja possível para credenciais pré-rotação.
  • Verifique se o cluster está em um estado íntegro (ou seja, se todos os recursos da Apigee estão em execução e se não há mudanças de estado pendentes).

Configuração de região única

  1. Crie um novo recurso SecretProviderClass do Kubernetes no namespace da Apigee para as novas credenciais do Cassandra. Consulte Como armazenar secrets do Cassandra no Hashicorp Vault para conferir um modelo. Isso permite que uma função do Vault acesse segredos nos namespaces do Kubernetes.
  2. Crie um novo recurso personalizado SecretRotation usando 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 o job de rotação. É necessário definir metadata.name como um valor exclusivo para o job de pré-verificação de rotação e novamente para o job 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 como o novo nome da classe do provedor de secrets que você criou na etapa anterior.
    • OLD_SPC_NAME: defina spec.cassandra.oldSecretProviderClass como o nome do SPC que o ApigeeDatastore está usando.
  3. Ative o job de pré-verificação de rotação aplicando o arquivo rotation.yaml. 
    kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
  4. Verifique o status do job para saber quando a pré-verificação for concluída. 
    kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
  5. Quando o job de pré-verificação de rotação for concluído, mude o valor de metadata.name e defina spec.precheck como false. Aplique o arquivo novamente para realizar a rotação. 
    kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
  6. Depois que o job de rotação for concluído e você tiver validado que o tráfego ainda está fluindo corretamente, limpe o processo com estas duas etapas:
    1. Atualize o valor de metadata.name e defina spec.cassandra.jobType como CLEANUP.
    2. Ative o job de limpeza aplicando o arquivo. 
      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml

    Quando o job de limpeza for concluído, o processo de rotação será finalizado.

  7. Faça o backup do banco de dados do Cassandra. Esse backup garante a recuperação das credenciais após a rotação.
  8. Exclua as credenciais, a função e a política do Cassandra antigo do Vault.

Configuração multirregional

Os procedimentos de configuração multirregional são divididos em duas seções: configuração da primeira região e configuração das demais regiões.

  1. Conclua as etapas a seguir na primeira região antes de iniciar as regiões seguintes.
    1. Crie um novo recurso SecretProviderClass do Kubernetes no namespace APIGEE_NAMESPACE para as novas credenciais do Cassandra. Consulte Como armazenar secrets do Cassandra no Hashicorp Vault para conferir um modelo. Isso permite que uma função do Vault acesse segredos nos namespaces do Kubernetes.
    2. Crie um novo recurso personalizado SecretRotation usando 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 o job de rotação. É necessário definir metadata.name como um valor exclusivo para o job de pré-verificação de rotação e novamente para o job 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 como o novo nome da classe do provedor de secrets que você criou na etapa anterior.
      • OLD_SPC_NAME: defina spec.cassandra.oldSecretProviderClass como o nome do SPC que o ApigeeDatastore está usando.
    3. Ative o job de pré-verificação de rotação aplicando o arquivo rotation.yaml. 
      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
    4. Verifique o status do job para saber quando a pré-verificação for concluída. 
      kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
    5. Quando o job de pré-verificação de rotação for concluído, faça o seguinte:
      • Mude 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 realizar a rotação.
      • Defina spec.rotationId como um novo identificador, por exemplo, rotation-1.
    6. Aplique o arquivo novamente para realizar a rotação. 
      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
    7. Verifique o estado do SecretRotation e aguarde até que ele seja complete. 
      kubectl -n APIGEE_NAMESPACE get sr SR_NAME
  2. Em cada região subsequente, siga estas etapas:
    1. Crie um novo recurso SecretProviderClass do Kubernetes no namespace da Apigee para as novas credenciais do Cassandra. Consulte Como armazenar secrets do Cassandra no Hashicorp Vault para conferir um modelo. Essa definição precisa ser igual à da etapa 1a.
    2. Atualize o overrides.yaml e defina cassandra.auth.secretProviderClass para corresponder ao valor de spec.cassandra.newSecretProviderClass no arquivo rotation.yaml. 
      cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
    3. Aplique o gráfico do operador: 
      helm upgrade operator apigee-operator/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE
    4. Um novo ReplicaSet será criado. Verifique se os novos pods de controller-manager estão usando 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 precisa corresponder ao valor definido 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 repositório de dados vai entrar em um estado de lançamento. Aguarde até que o repositório de dados termine o lançamento e esteja em 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 repositório de dados estão usando 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 precisa corresponder ao valor definido 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 de ser lançados 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 de MART, ambiente de execução e sincronizador estão usando 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 precisa corresponder ao valor definido 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 as etapas em todas as regiões e validar se o tráfego ainda está fluindo corretamente, limpe o processo na primeira região com estas duas etapas:
    1. Na primeira região, atualize o valor de metadata.name e defina spec.cassandra.jobType como CLEANUP.
    2. Ative o job de limpeza aplicando o arquivo. 
      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
    3. Verifique o status do job e acompanhe os registros para verificar quando o job de limpeza for concluído.

    Quando o job de limpeza for concluído, o processo de rotação será finalizado.

  4. Faça o backup do banco de dados do Cassandra. Esse backup garante a recuperação das credenciais após a rotação.
  5. Exclua as credenciais, a função e a política do Cassandra antigo do Vault.