Metodi di autenticazione dell'account di servizio in Apigee Hybrid

Scelta dei metodi di autenticazione del account di servizio in Apigee hybrid

Apigee Hybrid richiede service account per la comunicazione sicura con i servizi Google Cloud . Scegli un metodo di autenticazione per questi service account che sia in linea con i tuoi requisiti di sicurezza e operativi. Questa guida fornisce una breve panoramica delle opzioni disponibili.

Informazioni sull'autenticazione dell'account di servizio

Apigee hybrid utilizza i service account Google Cloud per autenticare e autorizzare i componenti in esecuzione nel cluster Kubernetes. Questi service account accedono Google Cloud a risorse, come bucket Cloud Storage e Cloud Logging. Ogni account di servizio richiede ruoli Identity and Access Management (IAM) specifici per svolgere le proprie funzioni.

Opzioni del metodo di autenticazione

Apigee Hybrid supporta diversi metodi per l'autenticazione degli account di servizio. Ogni metodo gestisce le chiavi dell'account di servizio in modo diverso, offrendo vari livelli di sicurezza e complessità operativa. Quando selezioni un metodo, tieni conto della piattaforma, del livello di sicurezza e dell'infrastruttura esistente.

La tabella seguente riassume i metodi di autenticazione disponibili:

Metodo Posizione di archiviazione delle chiavi Compatibilità della piattaforma Gestione delle chiavi
Secret Kubernetes Secret del cluster Kubernetes Qualsiasi piattaforma Kubernetes Kubernetes gestisce i secret, rotazione manuale
File delle chiavi JSON del service account File system locale Qualsiasi piattaforma Kubernetes Rotazione e distribuzione manuali
Vault HashiCorp Vault Qualsiasi piattaforma Kubernetes Vault gestisce i secret, rotazione manuale
Workload Identity Federation for GKE Google Cloud IAM Google Kubernetes Engine (GKE) Google Cloud gestisce, non sono necessari file di chiavi
Federazione delle identità per i workload su altre piattaforme Google Cloud IAM AKS, EKS, OpenShift o altre piattaforme Kubernetes Google Cloud gestisce, non sono necessari file di chiavi

Archivia le chiavi del account di servizio nei secret Kubernetes

Archivia le chiavi del account di servizio come secret Kubernetes all'interno del cluster. Questo metodo sfrutta le funzionalità di gestione dei secret integrate in Kubernetes. I secret Kubernetes possono fornire un modo più sicuro per gestire le chiavi rispetto all'archiviazione diretta dei file. Continui a gestire manualmente rotazione della chiave.

I componenti ibridi fanno riferimento a questi secret utilizzando le proprietà serviceAccountRef e envs[].serviceAccountRefs nel file overrides.yaml. Kubernetes gestisce la distribuzione di questi secret ai pod appropriati.

Ad esempio:

logger:
  serviceAccountRef: "my-project-apigee-logger-key"

Per utilizzare questo metodo, consulta la sezione Archiviare le chiavi degli account di servizio nei secret di Kubernetes.

File delle chiavi JSON del service account

Questo metodo prevede la creazione di un file della chiave JSON per ogni account di servizio e l'archiviazione di questi file direttamente in un file system. Questo approccio offre semplicità per la configurazione iniziale. Tuttavia, richiede di garantire la sicurezza del file system. La rotazione delle chiavi è manuale.

Inserisci il file JSON della chiave privata di ogni account di servizio in una directory accessibile dai componenti di Apigee Hybrid. Fai riferimento al percorso di questi file nella configurazione di overrides.yaml utilizzando le proprietà serviceAccountPath e envs[].serviceAccountPaths.

Ad esempio:

logger:
  serviceAccountPath: "my-project-apigee-logger.json"

Puoi generare e scaricare i file della chiave del account di servizio utilizzando lo strumento create-service-account fornito con Apigee Hybrid. Per ulteriori informazioni, vedi create-service-account.

Memorizzare le chiavi del account di servizio in Vault

Integra HashiCorp Vault per gestire le chiavi del account di servizio. Vault fornisce una soluzione solida per la gestione dei secret, offrendo funzionalità come la generazione dinamica dei secret, il controllo e la rotazione automatica delle chiavi. Richiede la configurazione e la manutenzione di un'istanza di Vault.

Dovrai creare segreti, criteri e ruoli Vault separati per i componenti a livello di organizzazione e ambiente. Fai riferimento a questi secret nella configurazione overrides.yaml utilizzando le proprietà serviceAccountSecretProviderClass e envs[].serviceAccountSecretProviderClass.

Ad esempio:

serviceAccountSecretProviderClass: apigee-orgsakeys-spc

envs:
- name: my-env
  serviceAccountSecretProviderClass: apigee-envsakeys-my-env-spc

Consulta Archiviare le chiavi dei account di servizio in Vault.

Workload Identity Federation for GKE

Workload Identity Federation for GKE consente ai service account Kubernetes di fungere da Google Cloud service account. Questo metodo elimina completamente la necessità di file di chiavi del account di servizio. Il cluster GKE autentica direttamente i carichi di lavoro utilizzando Google Cloud IAM. Workload Identity Federation for GKE fornisce un meccanismo di autenticazione altamente sicuro e automatizzato, semplificando la gestione delle chiavi. Questo metodo è specifico per i cluster GKE.

Questo metodo richiede il binding di ogni account di servizio Kubernetes a un service account Google Cloud specifico. Il processo di installazione di Apigee hybrid crea i service account Kubernetes specifici per l'installazione quando installi i grafici Helm di Apigee hybrid. Quando esegui il comando helm install o helm upgrade con il flag --dry-run per ogni grafico, l'output includerà i comandi per associare i service account Kubernetes ai service account Google Cloud per il componente Apigee Hybrid specifico nel grafico.

Abilita Workload Identity Federation for GKE nel file overrides.yaml con la proprietà gcp.workloadIdentity.enabled.

Ad esempio:

gcp:
  projectID: my-project
  region: us-west1
  workloadIdentity:
    enabled: true

Consulta Abilitare Workload Identity Federation for GKE.

Federazione delle identità per i workload su piattaforme diverse da GKE

Workload Identity Federation estende i vantaggi di Workload Identity Federation for GKE ai cluster Kubernetes in esecuzione al di fuori di Google Cloud, come Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) o OpenShift. Questo metodo consente al cluster non GKE di autenticarsi in Google Cloud utilizzando il provider OIDC del cluster per configurare una relazione di trust tra il provider di identità del cluster e Google Cloud. Dopo la configurazione iniziale, questo metodo elimina la necessità di file di chiavi del account di servizio.

Puoi utilizzare la federazione delle identità per i carichi di lavoro con:

  • File di configurazione delle credenziali (al posto dei file delle chiavi del account di servizio)
  • Secret Kubernetes
  • Vault

Per utilizzare la federazione delle identità per i carichi di lavoro, crea file di configurazione delle credenziali per ogni Google Cloud service account. Utilizza questi file al posto dei file delle chiavi dell'account di servizio o per configurare i secret Kubernetes o Vault se utilizzi questi metodi.

Abilita la federazione delle identità per i workload nel file overrides.yaml con le proprietà gcp.federatedWorkloadIdentity.enabled, gcp.federatedWorkloadIdentity.audience e gcp.federatedWorkloadIdentity.credentialSourceFile.

Ad esempio:

gcp:
  projectID: my-project
  region: us-west1
  federatedWorkloadIdentity:
    enabled: true
    audience: "//iam.googleapis.com/projects/123123123123/locations/global/workloadIdentityPools/my-wi-pool/providers/my-wi-provider"
    credentialSourceFile: "/var/run/service-account/token"

Consulta Abilitare la federazione delle identità per i workload.

Scegliere un metodo di autenticazione

Seleziona un metodo di autenticazione in base all'ambiente di deployment e ai requisiti di sicurezza.

  • Per i deployment GKE, la federazione delle identità per i carichi di lavoro per GKE offre un approccio sicuro e semplificato. In questo modo non è più necessario gestire direttamente i file delle chiavi dell'account di servizio.
  • Per i deployment Kubernetes non GKE (AKS, EKS, OpenShift), la federazione delle identità per i carichi di lavoro fornisce un'esperienza di autenticazione senza chiave simile. Questo metodo è la scelta consigliata per questi ambienti.
  • Se Workload Identity Federation for GKE o Workload Identity Federation non sono opzioni, valuta la possibilità di utilizzare Vault per la gestione e l'automazione centralizzate delle chiavi.
  • Per deployment più semplici o se non hai configurato Vault, l'archiviazione delle chiavi nei secret Kubernetes fornisce una soluzione Kubernetes nativa. Questo metodo offre una maggiore sicurezza rispetto all'archiviazione diretta dei file.
  • I file della chiave dell'account di servizio diretto sono adatti per i test iniziali o per gli ambienti in cui altri metodi non sono fattibili. Tuttavia, questo metodo richiede una gestione e una rotazione manuali e attente delle chiavi.

Passaggi successivi