Scopra GKE Workload Identity Analyzer, lo strumento sviluppato da DoiT per analizzare i workloads in esecuzione su GKE e verificare la corretta configurazione di Workload Identity.
GKE Workload Identity Analyzer: la garanzia di una configurazione corretta di Workload Identity
Se utilizza Google Kubernetes Engine (GKE) e i suoi workloads comunicano con altri servizi all'interno di Google Cloud, con ogni probabilità si avvale già di Workload Identity. E, se così non fosse, dovrebbe iniziare a farlo. Google raccomanda Workload Identity per i workloads in esecuzione su Google Kubernetes Engine (GKE) come metodo sicuro e gestibile per accedere ai servizi Google Cloud.
Le alternative a Workload Identity
Tra le opzioni alternative (e in parte ormai legacy) per l'autenticazione tra GKE e Google Cloud troviamo:
- l'utilizzo del service account predefinito di Compute Engine, che di norma offre uno scope troppo ampio e non può essere personalizzato per singolo workload;
- la fornitura di secrets dei service account ai propri workloads, una scelta a rischio sul piano della sicurezza, dal momento che si tratta di credenziali a lunga durata che richiedono attenzione e una rotazione periodica per essere allineate alle best practice di sicurezza.
Come funziona Workload Identity
Workload Identity non presenta nessuna delle criticità appena descritte: la configurazione avviene per singolo workload e non richiede né la gestione né l'iniezione di secrets nel workload stesso.
In sostanza, il meccanismo si basa sulla creazione di una relazione tra un Kubernetes Service Account (KSA) e un Google Service Account (GSA). Il KSA serve a identificare il workload in esecuzione su GKE come utilizzatore del GSA, mentre il GSA viene a sua volta configurato con gli accessi necessari alle risorse di Google Cloud. L'accesso può essere ampio o ristretto in base alle esigenze del workload: si pensi, ad esempio, a un workload che deve accedere a tutti i topic PubSub di un progetto, contrapposto a uno che ne richiede solo uno (o pochi).
I vantaggi di Workload Identity sono evidenti, ma il suo utilizzo comporta una configurazione aggiuntiva che, in un primo momento, può risultare poco intuitiva.
Gli errori di configurazione possono annidarsi in molti anelli della catena di autenticazione tra un Pod in esecuzione su GKE e un servizio attivo in un progetto GCP, rendendo il troubleshooting decisamente laborioso.
Cosa fa GKE Workload Identity Analyzer
DoiT ha sviluppato GKE Workload Identity Analyzer proprio per rispondere a questa esigenza. Lo strumento da riga di comando Workload Identity (WI) Analyzer accetta come argomento il nome di un pod ed esegue una serie di controlli di configurazione per verificare che WI sia impostato correttamente per il workload. Nello specifico, controlla:
- che Workload Identity sia abilitato sul cluster GKE;
- che il Pod abbia configurato .spec.serviceAccountName;
- che il KSA (configurato al passaggio precedente) esista;
- che il KSA sia annotato correttamente con un GSA;
- che il GSA (configurato al passaggio precedente) esista nel progetto;
- che il KSA disponga del ruolo roles/iam.workloadIdentityUser sul GSA.
Lo strumento, infine, verifica ed elenca i ruoli IAM assegnati al GSA all'interno del progetto (si noti che non controlla i ruoli IAM concessi su uno scope più ristretto, come una specifica risorsa GCP — un PubSub Topic, un'istanza CloudSQL, ecc.).
L'esecuzione richiede meno di 10 secondi e consente di risparmiare molto tempo, evitando di ispezionare risorse nella console o di lanciare comandi nel terminale.
Lo strumento è scritto in Python ed è pubblicato su PyPI. Si installa facilmente con PIP:
$ pip install wi-analyzerCome eseguire GKE Workload Identity Analyzer
I prerequisiti per l'esecuzione sono:
- gcloudcli installato e configurato;
- Application Default Credentials generate tramite gcloud;
- kubectl installato e configurato con accesso al cluster.
Da tenere presente che lo strumento ricava alcune informazioni dal contesto kubeconfig corrente e si aspetta il nome predefinito generato per un cluster GKE quando si recuperano le credenziali (nel formato: gke_<GCP_PROJECT_ID>__<CLUSTER_NAME>).
In alternativa, è possibile passare argomenti per specificare l'id del progetto GCP, la location del cluster e il nome del cluster.
Una volta completata la configurazione, lo strumento può essere lanciato dal terminale:
$ wi-analyzer --helpusage: wi-analyzer [-h] [-n NAMESPACE] [-d] pod
GKE Workload Identity Analyzer
positional arguments: pod Kubernetes Pod name to check
options: -h, --help show this help message and exit -n NAMESPACE, --namespace NAMESPACE Kubernetes Namespace to run in -p PROJECT, --project PROJECT GCP Project holding the cluster -l LOCATION, --location LOCATION The GCP location of the cluster -c CLUSTER, --cluster CLUSTER The name of the cluster
-d, --debug Enable debug loggingIpotizziamo, ad esempio, di aver seguito la documentazione per configurare il workload con WI e di aver saltato per distrazione un passaggio banale. L'output dello strumento può aiutarci a individuare il problema:
$ wi-analyzer demo-podCheck results---------------------------V=Passed, X=Failed, -=Skipped
[V] GCP project and GKE info determined from current context[V] Namespace passed as argument,or determined from current context[V] Workload Identity enabled on GKE Cluster[V] Pod found in current context[V] GKE Node found in the cluster[V] Workload Identity enabled on Node Pool[V] KSA found in the cluster[X] KSA Workload Identity annotation set correctly[-] GSA found in GCP project[-] GSA is enabled[-] GSA has Workload Identity users configured[-] GSA does not have KSA as a Workload Identity user
GKE cluster info---------------------------Cluster: "projects/test-eyal/locations/europe-west1-b/clusters/playground"Workload: "demo/demo-pod" running on Node: "gke-playground-nodepool-1f1ace09-96kr"KSA name: "demo-ksa"
Google Service Account info---------------------------Google Service Account information could not be determined, fix previous issuesCome si evince dall'output, l'annotazione WI sul KSA era assente. Una volta corretta, eseguendo di nuovo lo strumento dovremmo ottenere solo controlli superati e la panoramica completa:
$ wi-analyzer demo-podCheck results---------------------------V=Passed, X=Failed, -=Skipped
[V] GCP project and GKE info determined from current context[V] Namespace passed as argument,or determined from current context[V] Workload Identity enabled on GKE Cluster[V] Pod found in current context[V] GKE Node found in the cluster[V] Workload Identity enabled on Node Pool[V] KSA found in the cluster[V] KSA Workload Identity annotation set correctly[V] GSA found in GCP project[V] GSA is enabled[V] GSA has Workload Identity users configured[V] GSA does not have KSA as a Workload Identity user
GKE cluster info---------------------------Cluster: "projects/test-eyal/locations/europe-west1-b/clusters/playground"Workload: "demo/demo-pod" running on Node: "gke-playground-nodepool-1f1ace09-96kr"KSA name: "demo-ksa"
Google Service Account info---------------------------Google Service Account: "projects/test-eyal/serviceAccounts/[email protected]"Has the following Workload Identity Users:serviceAccount:test-eyal.svc.id.goog[demo/demo-ksa]
GSA: "[email protected]" has the following roles in project "test-eyal":roles/cloudsql.clientWorkload Identity configured properly - check if any IAM roles are missing from the list aboveAl momento lo strumento supporta soltanto GKE Standard, ma il supporto per Fleet Workload Identity (GKE WI per Anthos) è già nella roadmap. I test sui cluster Anthos multicloud sono già in corso, ma richiederanno alcune modifiche sostanziali allo strumento. Restate sintonizzati!
Ha riscontrato un problema con lo strumento? Ha qualche idea per nuove funzionalità?
Non esiti a contattarci, qui nei commenti oppure aprendo una issue sul repository GitHub.