Conoce GKE Workload Identity Analyzer, la herramienta que desarrolló DoiT para analizar los workloads que se ejecutan en GKE y validar que Workload Identity esté bien configurado.
GKE Workload Identity Analyzer valida que Workload Identity esté bien configurado
Si usas Google Kubernetes Engine (GKE) y tus workloads se comunican con otros servicios dentro de Google Cloud, lo más probable es que ya estés usando Workload Identity. Y si todavía no lo haces, deberías. Google recomienda Workload Identity para los workloads que se ejecutan en Google Kubernetes Engine (GKE) y necesitan acceder a servicios de Google Cloud de forma segura y administrable.
Alternativas a Workload Identity
Otras opciones (algo más legacy) para autenticar entre GKE y Google Cloud son:
- usar la cuenta de servicio predeterminada de Compute Engine, que normalmente otorga un alcance demasiado amplio y no se puede personalizar por workload;
- entregar secretos de cuenta de servicio a tus workloads, lo que implica un riesgo de seguridad, ya que esas claves son credenciales de larga duración que requieren cuidado y rotación periódica para cumplir con las buenas prácticas.
Cómo funciona Workload Identity
Workload Identity no presenta ninguno de los inconvenientes anteriores: se configura por workload y no requiere administrar ni inyectar secretos en él.
En esencia, funciona estableciendo una relación entre una Kubernetes Service Account (KSA) y una Google Service Account (GSA). La KSA se usa para identificar a tu workload corriendo en GKE como el usuario de la GSA, y la GSA, a su vez, se configura con los permisos necesarios sobre los recursos de Google Cloud. El acceso puede ser tan amplio o tan acotado como tu workload lo requiera; por ejemplo, un workload que necesita acceder a todos los topics de PubSub de un proyecto, frente a otro que solo necesita acceder a uno (o varios) en particular.
Las ventajas de Workload Identity son evidentes, aunque su uso requiere algo de configuración adicional que al principio puede resultar confusa.
Las configuraciones incorrectas pueden aparecer en muchos eslabones distintos de la cadena de autenticación entre un Pod que corre en GKE y un servicio que corre en un proyecto de GCP. Eso vuelve el troubleshooting bastante tedioso.
Qué hace GKE Workload Identity Analyzer
DoiT desarrolló GKE Workload Identity Analyzer precisamente con ese fin. La herramienta de línea de comandos Workload Identity (WI) Analyzer recibe el nombre de un pod como argumento y ejecuta verificaciones de configuración para confirmar que WI esté bien configurado para tu workload. Estos son los chequeos que hace:
- Workload Identity está habilitado en el cluster de GKE
- El pod tiene .spec.serviceAccountName configurado
- La KSA (definida en el paso anterior) existe
- La KSA tiene la anotación correcta hacia una GSA
- La GSA (definida en el paso anterior) existe en el proyecto
- La KSA tiene roles/iam.workloadIdentityUser sobre la GSA
Por último, la herramienta revisa y lista los roles de IAM que tiene la GSA en el proyecto (ten en cuenta que no verifica los roles otorgados sobre un alcance más acotado, como un recurso específico de GCP: PubSub Topic, instancia de CloudSQL, etc.).
Tarda menos de 10 segundos en ejecutarse y te ahorra mucho tiempo de inspección de recursos en la consola o de comandos en la terminal.
La herramienta está escrita en Python y publicada en PyPI. Se instala fácilmente con PIP:
$ pip install wi-analyzerCómo ejecutar GKE Workload Identity Analyzer
Los prerrequisitos para ejecutarla son:
- gcloudcli instalado y configurado
- Application Default Credentials generadas con gcloud
- kubectl instalado y configurado con acceso al cluster
Ten en cuenta que la herramienta toma parte de la información de tu contexto actual de kubeconfig. También espera el nombre generado por defecto para un cluster de GKE al obtener credenciales (con el formato gke_<GCP_PROJECT_ID>__<CLUSTER_NAME>).
Como alternativa, puedes pasar argumentos para indicar el id del proyecto de GCP, la ubicación del cluster y su nombre.
Una vez que todo esté listo, puedes ejecutar la herramienta desde la terminal:
$ 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 loggingPor ejemplo, supongamos que estaba siguiendo la documentación para configurar mi workload con WI y, sin querer, me salté un paso trivial. La salida de la herramienta podría ayudarnos a detectarlo:
$ 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 issuesComo muestra la salida, faltaba la anotación de WI en la KSA. Tras corregirla, al volver a ejecutar la herramienta deberíamos ver solo verificaciones exitosas y el resumen completo:
$ 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 abovePor ahora, la herramienta solo es compatible con GKE Standard, pero el soporte para Fleet Workload Identity (GKE WI para Anthos) ya está en el roadmap. Las pruebas en clusters de Anthos multicloud ya están en marcha, pero requerirán algunos cambios de fondo en la herramienta. ¡No te lo pierdas!
¿Encontraste algún problema con la herramienta? ¿Se te ocurren nuevas funcionalidades?
No dudes en escribirnos, ya sea aquí en los comentarios o abriendo un issue en el repositorio de GitHub.