Rotazione delle credenziali Cassandra in Hashicorp Vault

Version 1.15 (latest)

   Supported versions:

• v1.15 (latest)                        
• v1.14                        
• v1.13                         
• List of supported versions

   Unsupported versions:

• v1.12                         
• v1.11                         
• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Panoramica

Questa procedura descrive la rotazione delle credenziali Cassandra in Hashicorp Vault. Per la rotazione delle credenziali nei secret Kubernetes nel cluster, consulta Rotazione delle credenziali Cassandra nei secret Kubernetes.

Questa funzionalità consente agli amministratori della piattaforma di:

• Ruota le credenziali di Cassandra in Hashicorp Vault.
• Esegui il rollback alle credenziali Cassandra precedenti in Vault in caso di problemi durante la rotazione della password.
• Ruota la password di Cassandra per una regione alla volta, in modo da garantire un impatto minimo sulla disponibilità del servizio e mantenere il controllo sul processo di rotazione.
• Monitora l'inizio, l'avanzamento e il completamento della rotazione per una singola regione.

Questa funzionalità è disponibile in Apigee Hybrid 1.13.1 e versioni successive.

Nota:prima di utilizzare questa funzionalità, devi configurare l'archiviazione delle credenziali Cassandra in Vault. Segui le istruzioni riportate in Memorizzare i secret di Cassandra in Hashicorp Vault

Prima di iniziare

Prima di configurare la rotazione delle credenziali:

• Esegui il backup del database Cassandra. Questo backup serve a garantire che il recupero sia possibile con le credenziali pre-rotazione.
• Assicurati che il cluster sia in uno stato integro (ovvero che tutte le risorse Apigee siano in esecuzione e che non siano in attesa modifiche dello stato).

Nota: per configurare la rotazione delle credenziali, devi disporre dell'autorizzazione per eseguire kubectl apply -f all'interno del cluster.

Configurazione di una singola regione

1. Crea una nuova risorsa Kubernetes SecretProviderClass nel tuo spazio dei nomi Apigee per le nuove credenziali Cassandra. Per un modello da utilizzare, consulta Memorizzare i secret di Cassandra in Hashicorp Vault. In questo modo, un ruolo Vault può accedere ai secret all'interno degli spazi dei nomi Kubernetes.
2. Crea una nuova risorsa personalizzata SecretRotation utilizzando il seguente modello:

   # 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: un nome univoco per il job di rotazione. Dovrai impostare metadata.name su un valore univoco per il job di controllo preliminare della rotazione e di nuovo per il job di rotazione. Ad esempio, sr-1-precheck seguito da sr-1.
   • ROTATION_ID: imposta spec.rotationId su un identificatore personalizzato, ad esempio rotation-1-precheck.
   • NEW_SPC_NAME: imposta spec.cassandra.newSecretProviderClass sul nuovo nome della classe del fornitore di secret creato nel passaggio precedente.
   • OLD_SPC_NAME: imposta spec.cassandra.oldSecretProviderClass sul nome del SPC attualmente utilizzato da ApigeeDatastore.
3. Attiva il job di controllo preliminare della rotazione applicando il file rotation.yaml.

   kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml

4. Controlla lo stato del job per verificare quando viene completato il job di pre-controllo.

   kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job

   Suggerimento:puoi visualizzare i log anche durante l'esecuzione del job.

   kubectl -n APIGEE_NAMESPACE logs sr-(rotationId)-(rotate|rollback|cleanup)-job-(hash)

5. Al termine del job di controllo preliminare della rotazione, modifica il valore di metadata.name e imposta spec.precheck su false. Applica di nuovo il file per eseguire la rotazione.

   kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml

6. Una volta completato il job di rotazione e dopo aver verificato che il traffico continui a fluire correttamente, pulisci la procedura con i due passaggi seguenti:
   1. Aggiorna il valore di metadata.name e imposta spec.cassandra.jobType su CLEANUP.
   2. Attiva il job di pulizia applicando il file.

      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml

      Nota:fino a questo passaggio, puoi attivare un job di rollback per ripristinare la procedura di rotazione e lasciare il cluster nel suo stato originale.

   Al termine del job di pulizia, il processo di rotazione è completato.

7. Aggiorna il file di override e imposta cassandra.auth.secretProviderClass sulla nuova classe del provider di secret (newSecretProviderClass).

   cassandra:
     auth:
       secretProviderClass: NEW_SPC_NAME

8. Esegui il backup del database Cassandra. Questo backup serve a garantire che il recupero sia possibile con le credenziali post-rotazione.
9. Elimina le vecchie credenziali, il ruolo e la policy di Cassandra da Vault.

Configurazione multiregionale

Le procedure di configurazione multiregionale sono suddivise in due sezioni: configurazione per la prima regione e configurazione per le regioni rimanenti.

1. Completa i seguenti passaggi nella prima regione prima di iniziare con le regioni successive.
   1. Crea una nuova risorsa Kubernetes SecretProviderClass nello spazio dei nomi APIGEE_NAMESPACE per le nuove credenziali Cassandra. Per un modello da utilizzare, consulta Memorizzare i secret di Cassandra in Hashicorp Vault. In questo modo, un ruolo Vault può accedere ai secret all'interno degli spazi dei nomi Kubernetes.
   2. Crea una nuova risorsa personalizzata SecretRotation utilizzando il seguente modello:

      # 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: un nome univoco per il job di rotazione. Dovrai impostare metadata.name su un valore univoco per il job di controllo preliminare della rotazione e di nuovo per il job di rotazione. Ad esempio, sr-1-precheck seguito da sr-1.
      • ROTATION_ID: imposta spec.rotationId su un identificatore personalizzato, ad esempio rotation-1-precheck.
      • NEW_SPC_NAME: imposta spec.cassandra.newSecretProviderClass sul nuovo nome della classe del fornitore di secret creato nel passaggio precedente.
      • OLD_SPC_NAME: imposta spec.cassandra.oldSecretProviderClass sul nome del SPC attualmente utilizzato da ApigeeDatastore.
   3. Attiva il job di controllo preliminare della rotazione applicando il file rotation.yaml.

      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml

   4. Controlla lo stato del job per verificare quando viene completato il job di pre-controllo.

      kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job

      Suggerimento:puoi visualizzare i log anche durante l'esecuzione del job.

      kubectl -n APIGEE_NAMESPACE logs sr-(rotationId)-(rotate|rollback|cleanup)-job-(hash)

   5. Al termine del job di controllo preliminare della rotazione:
      • Modifica il valore di metadata.name, ad esempio da sr-1-precheck a sr-1.
      • Imposta spec.precheck su false per disattivare il controllo preliminare ed eseguire la rotazione.
      • Imposta spec.rotationId su un nuovo identificatore, ad esempio rotation-1.
   6. Applica di nuovo il file per eseguire la rotazione.

      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml

   7. Controlla lo stato di SecretRotation e attendi che diventi complete.

      kubectl -n APIGEE_NAMESPACE get sr SR_NAME

2. In ogni regione successiva, completa i seguenti passaggi:
   1. Crea una nuova risorsa Kubernetes SecretProviderClass nel tuo spazio dei nomi Apigee per le nuove credenziali Cassandra. Per un modello da utilizzare, consulta Memorizzare i secret di Cassandra in Hashicorp Vault. Deve essere la stessa definizione del passaggio 1a.
   2. Aggiorna overrides.yaml e imposta cassandra.auth.secretProviderClass in modo che corrisponda al valore di spec.cassandra.newSecretProviderClass nel file rotation.yaml.

      cassandra:
        auth:
          secretProviderClass: NEW_SPC_NAME

   3. Applica il grafico degli operatori:

      helm upgrade operator apigee-operator/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f OVERRIDES_FILE

   4. Verrà creato un nuovo ReplicaSet. Verifica che i nuovi pod controller-manager utilizzino il nuovo 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}'
      

      Il risultato deve corrispondere al valore impostato per spec.cassandra.newSecretProviderClass in rotation.yaml, ad esempio:

      kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      
      my-new-spc

   5. Applica il grafico del datastore:

      helm upgrade datastore apigee-datastore/ \
        --namespace APIGEE_NAMESPACE \
        --atomic \
        -f OVERRIDES_FILE

      Nota:l'applicazione del grafico del datastore attiverà anche i rilasci per l'organizzazione e gli ambienti.
   6. Il datastore passerà allo stato di rilascio. Attendi che il datastore abbia terminato il rilascio e sia in stato di esecuzione.

      kubectl -n APIGEE_NAMESPACE get apigeedatastore DATASTORE_NAME

      DATASTORE_NAME è default nella maggior parte delle installazioni.

   7. Verifica che i nuovi pod del datastore utilizzino il nuovo 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}'
      

      Il risultato deve corrispondere al valore impostato per spec.cassandra.newSecretProviderClass in rotation.yaml, ad esempio:

      kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      
      my-new-spc

   8. Attendi che l'organizzazione e gli ambienti vengano rilasciati e tornino allo stato di esecuzione.

      kubectl -n APIGEE_NAMESPACE get apigeeorg ORG_NAME
      kubectl -n APIGEE_NAMESPACE get apigeeenv ENV_NAME

   9. Verifica che i nuovi pod MART, runtime e sincronizzatore utilizzino il nuovo 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}'
      

      Il risultato deve corrispondere al valore impostato per spec.cassandra.newSecretProviderClass in rotation.yaml, ad esempio:

      kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
      
      my-new-spc

3. Dopo aver completato i passaggi in ogni regione e verificato che il traffico continui a fluire correttamente, pulisci la procedura nella prima regione con i seguenti due passaggi:
   1. Nella prima regione, aggiorna il valore di metadata.name e imposta spec.cassandra.jobType su CLEANUP.
   2. Attiva il job di pulizia applicando il file.

      kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml

   3. Controlla lo stato del job e i relativi log per verificare quando il job di pulizia è stato completato.

   Al termine del job di pulizia, il processo di rotazione è completato.

4. Aggiorna il file di override e imposta cassandra.auth.secretProviderClass sulla nuova classe del provider di secret (newSecretProviderClass).

   cassandra:
     auth:
       secretProviderClass: NEW_SPC_NAME

5. Esegui il backup del database Cassandra. Questo backup serve a garantire che il recupero sia possibile con le credenziali post-rotazione.
6. Elimina le vecchie credenziali, il ruolo e la policy di Cassandra da Vault.

Rollback di una rotazione

Nota:puoi eseguire il rollback di una rotazione solo prima che venga attivato il job di pulizia.

Per la configurazione multiregionale, esegui il rollback in ogni regione.

1. Crea una nuova risorsa personalizzata SecretRotation utilizzando il seguente modello:

   # 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
   

   Dove:

   • ROLLBACK_NAME: un nome per il job di rollback, ad esempio sr-1-rollback.
   • APIGEE_NAMESPACE: il tuo spazio dei nomi Apigee.
   • APIGEE_ORG: l'ID organizzazione Apigee.
   • ROTATION_ID: l'ID della rotazione corrente di cui stai eseguendo il rollback, ad esempio rot-1.
   • TIMEOUT_MINUTES: (Facoltativo) Esegue l'override del valore predefinito (480 m = 8 ore). <=0 significa timeout infinito.
   • OLD_SPC_NAME: deve corrispondere al nome del secret per oldSecretProviderClass: nel file YAML di rotazione utilizzato nella procedura di configurazione a singola regione o configurazione multiregionale.
   • NEW_SPC_NAME: deve corrispondere al nome del secret per newSecretProviderClass: nel file YAML di rotazione utilizzato nella procedura di configurazione a singola regione o configurazione multiregionale.
2. Applica il rollback:

   kubectl -n APIGEE_NAMESPACE apply -f ROLLBACK_YAML_FILE
   

3. Controlla lo stato del job e attendi il completamento.

   kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
   

4. Al termine del rollback, verifica che il traffico continui a fluire correttamente.
5. Per le installazioni multiregionali, quando il traffico scorre correttamente, ripeti la procedura di rollback in ogni regione.
6. Una volta completato il rollback e verificato che il traffico continui a fluire correttamente in tutte le regioni, inizia la procedura di pulizia.

   Apporta le seguenti modifiche al file YAML di rotazione:

   • Modifica metadata.name con un nome che indichi che si tratta di un job di pulizia, ad esempio sr-1-cleanup-rollback.
   • Modifica spec.cassandra.jobType in CLEANUP_ROLLBACK.
7. Applica il file per attivare il job di pulizia:

   kubectl -n APIGEE_NAMESPACE apply -f ROTATION_YAML_FILE
   

8. Controlla lo stato del job e attendi il completamento.

   kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
   

   Al termine del job di pulizia, il processo di rollback è completato.

9. Aggiorna il file di override e imposta cassandra.auth.secretProviderClass sulla vecchia classe del provider di secret (oldSecretProviderClass).

   cassandra:
     auth:
       secretProviderClass: OLD_SPC_NAME