Archiviazione dei secret di Cassandra in Hashicorp Vault

Archiviazione dei secret di Cassandra in Hashicorp Vault

Questa funzionalità consente di archiviare le credenziali Cassandra DB per Apigee Hybrid in Hashicorp Vault, un secret esterno responsabile. I gestori dei secret esterni consentono di gestire l'archiviazione dei secret in Kubernetes, tra cui la gestione della residenza dei dati e dei controlli granulari dell'accesso.

Prima della versione ibrida di Apigee 1.10, l'unico modo per fornire le password per gli utenti Cassandra era specificare la password in overrides.yaml. Queste password sono archiviate nei secret di Kubernetes. Ad esempio:

cassandra:
  auth:
    default:
      password: "********"
    admin:
      password: "********"
    ddl:
      password: "********"
    dml:
      password: "********"
    jmx:
      username: "jmxuser"
      password: "********"
    jolokia:
      username: "apigee"
      password: "********"

Con Hashicorp Vault, puoi fornire queste password tramite l'API del driver CSI Secrets Store di Kubernetes (SecretProviderClass). In questo modo, Kubernetes può montare più secret, chiavi e certificati archiviati in un Vault esterno.

Utenti e password Cassandra

Dovrai creare i secret per i seguenti utenti Cassandra. Modifica i valori predefiniti in siano conformi ai criteri di sicurezza della tua organizzazione.

Utente Cassandra Nome utente predefinito Password predefinita
Amministratore admin_user "********"
DDL ddl_user "********"
Predefinito cassandra Nota: il nome utente predefinito deve essere sempre "cassandra" "********"
DML dml_user "********"
JMX "jmxuser" "********"
Jolokia "apigee" "********"

Vedi Cassandra di configurazione per ulteriori informazioni.

Configura l'integrazione di secret esterni

La configurazione dell'integrazione di Vault per Apigee hybrid prevede le seguenti procedure.

  • Nelle prime due procedure, interagisci direttamente con Vault.
  • Nella terza e nella quarta procedura, applichi le configurazioni al cluster Kubernetes.

Utilizza le procedure riportate di seguito per creare i secret in Vault e consentire all'installazione ibrida di accedervi.

Creare secret, criteri e ruoli di Vault

  1. Verifica che il contesto Kubernetes corrente sia impostato sul tuo cluster:
    kubectl config current-context
  2. Utilizza l'API, l'interfaccia a riga di comando o la UI di Vault per creare i secret di Cassandra. I valori del secret che crei deve corrispondere ai nomi utente e alle password di Cassandra attualmente utilizzati nel cluster.
    • Chiave segreta: puoi utilizzare qualsiasi chiave segreta (o combinazione di più chiavi), ad esempio:
      secret/data/apigee/cassandra
    • Dati riservati: Apigee Hybrid si aspetta coppie di nome utente e password per i seguenti utenti Cassandra:
      Utenti Cassandra
      Amministratore
      DDL
      Predefinito
      DML
      JMX
      Jolokia
      I valori di nome utente e password possono essere distribuiti su un numero qualsiasi di chiavi private.
    • Interfaccia a riga di comando di Vault: il comando seguente mostra come creare un singolo secret contenente tutti i nomi utente e le password richiesti:
      vault kv put secret/apigee/cassandra \
          adminUsername="ADMIN_USERNAME" \
          adminPassword="ADMIN_PASSWORD" \
          ddlUsername="DDL_USERNAME" \
          ddlPassword="DDL_PASSWORD" \
          defaultUsername="cassandra" \
          defaultPassword="DEFAULT_PASSWORD" \
          dmlUsername="DML_USERNAME" \
          dmlPassword="DML_PASSWORD" \
          jmxUsername="JMX_USERNAME" \
          jmxPassword="JMX_PASSWORD" \
          jolokiaUsername="JOLOKIA_USERNAME" \
          jolokiaPassword="JOLOKIA_PASSWORD"
      I nomi utente predefiniti per ciascun utente sono i seguenti:
      Utente Cassandra Valore predefinito
      Amministratore admin_user
      DDL ddl_user
      Predefinito cassandra
      DML dml_user
      JMX jmxuser
      Jolokia apigee
  3. In Vault, crea un criterio per concedere l'accesso al secret che hai appena creato.
    1. Crea un file dei criteri (nome suggerito: apigee-cassandra-auth.txt) con seguenti contenuti:
      path "secret/data/apigee/cassandra" {
        capabilities = ["read"]
      }
      Se hai creato più secret, ogni secret deve essere aggiunto al file delle norme:
      path "secret/data/apigee/cassandra/admin" {
        capabilities = ["read"]
      }
      
      path "secret/data/apigee/cassandra/ddl" {
        capabilities = ["read"]
      }
    2. Applica il criterio a Vault:
      vault policy write apigee-cassandra-auth apigee-cassandra-auth.txt

      È possibile creare il criterio utilizzando l'input standard anziché leggere da un file:

      echo 'path "secret/data/apigee/cassandra" { capabilities = ["read"] }' | vault policy write apigee-cassandra-auth -
  4. Associa il criterio agli account di servizio Kubernetes di Apigee Cassandra.
    1. Definisci le seguenti variabili di ambiente:
      export ORG_NAME=APIGEE_ORG_NAME
      export ENVS_LIST=LIST_OF_APIGEE-ENVS
      export APIGEE_NAMESPACE=YOUR_APIGEE_NAMESPACE
      export NAMESPACES=apigee-system,${APIGEE_NAMESPACE}

      Dove:

      • ORG_NAME è il nome della tua organizzazione Apigee.
      • ENVS_LIST È un elenco separato da virgole dei tuoi ambienti Apigee, ad esempio dev,prod.
      • APIGEE_NAMESPACE è lo spazio dei nomi Apigee. Il valore predefinito è apigee.
      • NAMESPACES è un elenco di spazi dei nomi separati da virgole per Apigee, apigee-system e lo spazio dei nomi Apigee.
    2. Crea uno script con i seguenti contenuti. Lo script può avere qualsiasi nome. Nel seguente esempio, il nome dello script è create-vault-cassandra-role.sh:
      # create-vault-cassandra-role.sh
      
      ORG=ORG_NAME  # ORG name
      ENVS=ENVS_LIST # comma separated env names, for example: dev,prod
      
      org_short_name=$(echo $ORG | head -c 15)
      encode=$(echo -n $ORG | shasum -a 256 | head -c 7)
      org_encode=$(echo "$org_short_name-$encode")
      names=apigee-manager,apigee-cassandra-default,apigee-cassandra-backup-sa,apigee-cassandra-restore-sa,apigee-cassandra-schema-setup-${org_encode},apigee-cassandra-schema-val-${org_encode},apigee-cassandra-user-setup-${org_encode},apigee-mart-${org_encode},apigee-mint-task-scheduler-${org_encode}
      
      for env in ${ENVS//,/ }
      do
        env_short_name=$(echo $env | head -c 15)
        encode=$(echo -n $ORG:$env | shasum -a 256 | head -c 7)
        env_encode=$(echo "$org_short_name-$env_short_name-$encode")
        names+=,apigee-synchronizer-${env_encode},apigee-runtime-${env_encode}
      done
      
      echo $names
      
    3. Esegui lo script e assegna l'output alla variabile SERVICE_ACCOUNT_NAMES. Verrà creato un elenco separato da virgole di nomi degli account di servizio Kubernetes.
      export SERVICE_ACCOUNT_NAMES=$(./create-vault-cassandra-role)

      Verifica che la variabile sia stata compilata con l'elenco:

      echo $SERVICE_ACCOUNT_NAMES
    4. Utilizza l'interfaccia a riga di comando di Vault per creare un ruolo che vincoli il criterio agli account di servizio Kubernetes:
      vault write auth/kubernetes/role/cassandra \
          bound_service_account_names=${SERVICE_ACCOUNT_NAMES} \
          bound_service_account_namespaces=${NAMESPACES} \
          policies=apigee-cassandra-auth \
          ttl=1m

Installa il driver CSI e il provider Vault

Apigee hybrid versione 1.12.2 supporta le seguenti versioni dei grafici Helm:

Software Versione
Driver CSI dell'archivio dei secret v1.3.4
Vault v0.25.0
  1. Segui le istruzioni di installazione del driver CSI Secrets Store per installare il driver CSI nel cluster. Il driver CSI dispone di un grafico Helm per l'installazione.
  2. Segui le istruzioni riportate in Installare il provider CSI di Vault per installare il provider CSI di Vault, se non l'hai ancora fatto.

Creazione oggetto SecretProviderClass

La risorsa SecretProviderClass indica al driver CSI quale provider deve quando richiedono i secret. L'account utente Cassandra è necessario configurare le credenziali tramite questo oggetto. La tabella seguente mostra i nomi file (objectName) previsti da Apigee Cassandra:

Utente Cassandra Nomi previsti per i file secret
Amministratore adminUsername, adminPassword
DDL ddlUsername, ddlPassword
Predefinito cassandra, defaultPassword
DML dmlUsername, dmlPassword
JMX jmxUsername, jmxPassword
Jolokia jolokiaUsername, jolokiaPassword
  1. Crea un file YAML per SecretProviderClass. Il nome del file può essere qualsiasi, ad esempio spc.yaml. Utilizza il seguente modello di SecretProviderClass per configurare questa risorsa:
    apiVersion: secrets-store.csi.x-k8s.io/v1
    kind: SecretProviderClass
    metadata:
      name: apigee-cassandra-auth-spc
    spec:
      provider: vault
      parameters:
        roleName: apigee-cassandra-auth  # the roleName should match the vault role you created earlier in this procedure
    
        # vaultAddress is the endpoint your Vault server is running at.
        # If Vault is running in the same cluster as Apigee, the format will generally be:
        # http://vault.<namespace>.svc.cluster.local:<vaultServicePort>
        vaultAddress: VAULT_ADDRESS
    
        # "objectName" is an alias used within the SecretProviderClass to reference
        # that specific secret. This will also be the filename containing the secret.
        # Apigee Cassandra expects these exact values so they must not be changed.
        # "secretPath" is the path in Vault where the secret should be retrieved.
        # "secretKey" is the key within the Vault secret response to extract a value from.
        # For example, if the Vault secret is located at `secret/data/apigee/cassandra`
        # and you want to specify the admin password, you would use the following:
        # - objectName: "adminPassword"
        #   secretPath: "secret/data/apigee/cassandra"
        #   secretKey: "key within Vault secret specifying the admin password"
        objects: |
          - objectName: "adminUsername"
            secretPath: ""
            secretKey: ""
          - objectName: "adminPassword"
            secretPath: ""
            secretKey: ""
          - objectName: "defaultUsername"
            secretPath: ""
            secretKey: ""
          - objectName: "defaultPassword"
            secretPath: ""
            secretKey: ""
          - objectName: "ddlUsername"
            secretPath: ""
            secretKey: ""
          - objectName: "ddlPassword"
            secretPath: ""
            secretKey: ""
          - objectName: "dmlUsername"
            secretPath: ""
            secretKey: ""
          - objectName: "dmlPassword"
            secretPath: ""
            secretKey: ""
          - objectName: "jolokiaUsername"
            secretPath: ""
            secretKey: ""
          - objectName: "jolokiaPassword"
            secretPath: ""
            secretKey: ""
          - objectName: "jmxUsername"
            secretPath: ""
            secretKey: ""
          - objectName: "jmxPassword"
            secretPath: ""
            secretKey: ""
  2. Applica SecretProviderClass sia agli spazi dei nomi apigee sia apigee-system. Nei comandi seguenti, gli spazi dei nomi sono apigee e apigee-system. Sostituisci questi valori se utilizzi spazi dei nomi diversi:
    kubectl -n apigee apply -f spc.yaml
    kubectl -n apigee-system apply -f spc.yaml

Attivare il secret esterno per Cassandra

  1. In overrides.yaml, aggiungi la seguente configurazione per attivare l'utilizzo di secret esterni per Cassandra:
    cassandra:
      auth:
        secretProviderClass: apigee-cassandra-auth-spc  # The name of the SecretProviderClass created in spc.yaml.

    Vedi cassandra.auth.secretProviderClass.

  2. Utilizza helm upgrade per applicare la modifica a apigee-operator e apigee-datastore componenti:
    • Il controller datastore in apigee-operator partecipa a Disattivazione di Cassandra e replica dei dati durante l'espansione della regione. Queste attività richiedono le credenziali JMX e Jolokia.
      helm upgrade operator apigee-operator/ \
        --namespace apigee-system \
        --atomic \
        -f overrides.yaml
    • apigee-datastore fornisce le credenziali utilizzate dai componenti a valle come apigee-runtime, Synchronizer e MART per la connessione a Cassandra.
      helm upgrade datastore apigee-datastore/ \
        --namespace apigee \
        --atomic \
        -f overrides.yaml
  3. Verifica che vengano utilizzati secret esterni. Quando i secret esterni sono abilitati, vengono aggiunti nuovi Volume, Volume Mount e Environment Variable che fanno riferimento ai secret.
    • Verifica il deployment di apigee-controller-manager.

      Verifica che esista un Volume denominato apigee-external-secrets e che faccia riferimento al SecretProviderClass creato sopra:

      kubectl -n apigee-system get deployment apigee-controller-manager -o jsonpath='{.spec.template.spec.volumes[?(@.name=="apigee-external-secrets")]}'
      {
        "csi": {
          "driver": "secrets-store.csi.k8s.io",
          "readOnly": true,
          "volumeAttributes": {
            "secretProviderClass": "apigee-cassandra-auth-spc"
          }
        },
        "name": "apigee-external-secrets"
      }

      Verifica che un VolumeMount denominato apigee-external-secrets esiste:

      kubectl -n apigee-system get deployment apigee-controller-manager -o jsonpath='{.spec.template.spec.containers[?(@.name=="manager")].volumeMounts[?(@.name=="apigee-external-secrets")]}'
      {
        "mountPath": "/opt/apigee/externalsecrets",
        "name": "apigee-external-secrets",
        "readOnly": true
      }

      Verifica che esistano Environment Variable che fanno riferimento a secret esterni:

      kubectl -n apigee-system get deployment apigee-controller-manager -o jsonpath='{.spec.template.spec.containers[?(@.name=="manager")].env}'
      [
        ...
        {
          "name": "CASSANDRA_JOLOKIA_USERNAME_PATH",
          "value": "/opt/apigee/externalsecrets/jolokiaUsername"
        },
        {
          "name": "CASSANDRA_JOLOKIA_PASSWORD_PATH",
          "value": "/opt/apigee/externalsecrets/jolokiaPassword"
        }
      ]

Esegui il rollback al secret K8s

  1. Per ripristinare i secret non esterni, rimuovi la configurazione secretProviderClass in overrides.yaml e utilizza la configurazione precedente:
    cassandra:
          auth:
            secretProviderClass: apigee-cassandra-auth-spc # remove this line
  2. Utilizza helm upgrade per applicare la modifica a apigee-operator e apigee-datastore componenti:
    helm upgrade operator apigee-operator/ \
      --namespace apigee-system \
      --atomic \
      -f overrides.yaml
    helm upgrade datastore apigee-datastore/ \
      --namespace apigee \
      --atomic \
      -f overrides.yaml

Risoluzione dei problemi: creare un contenitore client per il debug

Se utilizzi Vault, questa sezione sostituisce le istruzioni riportate nella sezione relativa alla risoluzione dei problemi, Crea un contenitore client per il debug.

Questa sezione spiega come creare un contenitore client da cui puoi accedere alle utility di debug di Cassandra come cqlsh. Queste utilità ti consentono di eseguire query sulle tabelle Cassandra e possono essere utili per il debug.

Crea il contenitore del client

Per creare il contenitore client:

  1. Il contenitore utilizza il certificato TLS del pod apigee-cassandra-user-setup. Il primo passaggio consiste nell'estrarre il nome del certificato:
    kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'

    Questo comando restituisce il nome del certificato. Ad esempio: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls.

  2. Apri un nuovo file e incolla al suo interno la seguente specifica del pod:
    apiVersion: v1
      kind: Pod
      metadata:
        labels:
        name: CASSANDRA_CLIENT_NAME   # For example: my-cassandra-client
        namespace: apigee
      spec:
        containers:
        - name: CASSANDRA_CLIENT_NAME
          image: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra-client:1.12.2"
          imagePullPolicy: Always
          command:
          - sleep
          - "3600"
          env:
          - name: CASSANDRA_SEEDS
            value: apigee-cassandra-default.apigee.svc.cluster.local
          - name: APIGEE_DML_USERNAME_PATH
            value: /opt/apigee/externalsecrets/dmlUsername
          - name: APIGEE_DML_PASSWORD_PATH
            value: /opt/apigee/externalsecrets/dmlPassword
          volumeMounts:
          - mountPath: /opt/apigee/ssl
            name: tls-volume
            readOnly: true
          - name: apigee-external-secrets
            mountPath: /opt/apigee/externalsecrets
            readOnly: true
        volumes:
        - name: tls-volume
          secret:
            defaultMode: 420
            secretName: apigee-cassandra-user-setup-vaibhavhybridor-8b3e61d-tls
        - name: apigee-external-secrets
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: apigee-cass-password
        serviceAccount: apigee-cassandra-default
        serviceAccountName: apigee-cassandra-default
        restartPolicy: Never
  3. Salva il file con un'estensione .yaml. Ad esempio: my-spec.yaml.
  4. Applica la specifica al cluster:
    kubectl apply -f my-spec.yaml -n apigee
  5. Accedi al container:
    kubectl exec -n CASSANDRA_CLIENT_NAME -it -- bash
  6. Connettiti all'interfaccia cqlsh di Cassandra con i seguenti comandi. Inserisci il esattamente come mostrato:
    APIGEE_DML_USER=$(cat "$APIGEE_DML_USERNAME_PATH")
    export APIGEE_DML_USER
    APIGEE_DML_PASSWORD=$(cat "$APIGEE_DML_PASSNAME_PATH")
    export APIGEE_DML_PASSWORD
    cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl

Eliminazione del pod client

Utilizza questo comando per eliminare il pod del client Cassandra:

kubectl delete pods -n apigee cassandra-client