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 i servizi Google Cloud . Scegli un metodo di autenticazione per questi service account in linea con i 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 service account Google Cloud per autenticare e autorizzare i componenti in esecuzione nel tuo cluster Kubernetes. Questi service account accedono alle risorse Google Cloud , come i bucket Cloud Storage e Cloud Logging. Ogni account di servizio richiede ruoli Identity and Access Management (IAM) specifici per svolgere le sue funzioni.

Opzioni per il 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 conto della tua piattaforma, della tua security posture e della tua 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 della chiave 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 dei account di servizio nei secret di 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 di 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 Archivia le chiavi dei account di servizio nei secret di Kubernetes.

File della chiave JSON del service account

Questo metodo prevede la creazione di un file di chiave JSON per ogni account di servizio e l'archiviazione di questi file direttamente su 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 saperne di più, consulta create-service-account.

Archivia le chiavi dei account di servizio in Vault

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

Dovrai creare secret, policy e ruoli di Vault separati per i componenti a livello di organizzazione e di ambiente. Fai riferimento a questi secret nella configurazione di 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 Archivia le chiavi dei account di servizio in Vault.

Workload Identity Federation for GKE

Workload Identity Federation for GKE consente ai service account Kubernetes di agire come service account Google Cloud. Questo metodo elimina completamente la necessità di file di chiavi dei account di servizio. Invece, il cluster GKE autentica direttamente i workload 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 Google Cloud specifico. Il processo di installazione di Apigee hybrid crea i service account Kubernetes specifici per la tua 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 in quel grafico.

Puoi abilitare 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 Abilita 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 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 attendibilità tra il provider di identità del cluster e 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 della chiave del account di servizio)
  • Secret Kubernetes
  • Vault

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

Puoi abilitare 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 Abilita la federazione delle identità per i workload.

Scegli 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. In questo modo non è più necessario gestire direttamente i file delle chiavi dei account di servizio.
  • Per i deployment Kubernetes non GKE (AKS, EKS, OpenShift), la federazione delle identità per i workload 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 deployment più semplici o se non hai una configurazione di Vault, l'archiviazione delle chiavi nei secret di Kubernetes fornisce una soluzione Kubernetes nativa. Questo metodo offre una maggiore sicurezza 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 un'attenta gestione e rotazione manuale delle chiavi.

Passaggi successivi