Metodi di autenticazione dell'account di servizio in Apigee Hybrid

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

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

Informazioni sull'autenticazione dei account di servizio

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

Opzioni del metodo di autenticazione

Apigee hybrid supporta diversi metodi per l'autenticazione dei service account. Ogni metodo gestisce le chiavi dei account di servizio in modo diverso, offrendo vari livelli di sicurezza e complessità operativa. Quando selezioni un metodo, tieni presente la piattaforma, la postura di sicurezza e l'infrastruttura esistente.

La tabella seguente riassume i metodi di autenticazione disponibili:

Metodo Località 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 di chiavi JSON dei 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

Archiviazione delle chiavi dei account di servizio nei secret Kubernetes

Archivia le chiavi dei 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. Rotazione della chiave viene comunque gestita manualmente.

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 Archiviare le chiavi dei account di servizio nei secret Kubernetes.

File di chiavi JSON dei service account

Questo metodo prevede la creazione di un file di chiavi 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 tua overrides.yaml configurazione utilizzando le proprietà serviceAccountPath e envs[].serviceAccountPaths.

Ad esempio:

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

Puoi generare e scaricare i file delle chiavi dei account di servizio utilizzando lo strumento create-service-account fornito con Apigee hybrid. Per maggiori informazioni, consulta create-service-account.

Archiviazione delle chiavi dei account di servizio in Vault

Integra HashiCorp Vault per gestire le chiavi dei account di servizio. Vault fornisce una soluzione efficace per la gestione dei secret, offrendo funzionalità come la generazione dinamica dei secret, l'audit e rotazione della chiave. Richiede la configurazione e la manutenzione di un'istanza di Vault.

Dovrai creare secret, 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 dei 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 l'associazione di ogni account di servizio Kubernetes a un service account specifico Google Cloud . La procedura 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 Google Cloud service account per il componente ibrido di Apigee specifico in quel 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

La federazione delle identità per i workload estende i vantaggi di Workload Identity Federation for GKE a cluster Kubernetes in esecuzione all'esterno 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 Google Cloud il provider OIDC del cluster per configurare una relazione di attendibilità tra il provider di identità del cluster e Google Cloud Google Cloud. Dopo la configurazione iniziale, questo metodo elimina la necessità di file di chiavi dei account di servizio.

Puoi utilizzare la federazione delle identità per i workload con:

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

Per utilizzare Workload Identity Federation, crea file di configurazione delle credenziali per ogni Google Cloud service account. Utilizza questi file al posto dei file di chiavi dei 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, Workload Identity Federation for GKE offre un approccio sicuro e semplificato. Non è più necessario gestire direttamente i file di chiavi dei account di servizio.
  • Per i deployment Kubernetes non GKE (AKS, EKS, OpenShift), Workload Identity Federation offre un'esperienza di autenticazione senza chiavi simile. Questo metodo è la scelta consigliata per questi ambienti.
  • Se Workload Identity Federation for GKE o la federazione delle identità per i workload non sono opzioni, valuta la possibilità di utilizzare Vault per la gestione e l'automazione centralizzate delle chiavi.
  • Per i deployment più semplici o se non hai una configurazione Vault, l'archiviazione delle chiavi nei secret Kubernetes fornisce una soluzione Kubernetes nativa. Questo metodo offre una sicurezza migliore rispetto all'archiviazione diretta dei file.
  • I file di chiavi dei account di servizio diretti 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 delle chiavi.

Passaggi successivi