GKE Workload Identity ahora es Workload Identity Federation: ¿qué más cambió?

WIF es una función diseñada para tender un puente entre los sistemas de identidad externos y Google Cloud IAM. Permite a las organizaciones extender sin fricción su infraestructura de identidad existente —Active Directory, AWS, Okta y más— a los recursos de Google Cloud.

Al establecer relaciones de confianza entre proveedores de identidad externos (IdP) y Google Cloud IAM, WIF permite que los usuarios y aplicaciones autenticados a través de sistemas distintos de GCP accedan a los recursos de GCP usando sus identidades existentes.

Para establecer esta relación de confianza, primero se crea un Workload Identity Pool que gestiona las identidades externas y, después, se agregan Workload Identity Providers al pool, cada uno describiendo la relación entre tu IdP y GCP.

Una vez establecido, un token de credencial de tu IdP puede verificarse mediante el Security Token Service de Google e intercambiarse por un token federado que se utiliza para autenticarse en GCP.

En Workload Identity Federation for GKE (antes llamado simplemente Workload Identity), Google se encarga del pool y del provider por ti.

Cada proyecto de GCP tiene un único pool fijo (PROJECT_ID.svc.id.goog) y, una vez habilitado en un clúster de GKE, este queda registrado como proveedor de identidad en ese pool.

El metadata server de GKE se despliega automáticamente como un DaemonSet en todos los nodos del clúster. Entre otras cosas, sirve para interceptar las solicitudes que llegan desde tus workloads y responder con el token correcto para la service account que tu workload está configurada para suplantar.

En esto consiste, en esencia, esta función: permitir que tus workloads de GKE accedan a recursos de GCP sin tener que pasar credenciales explícitas, ni siquiera apoyarse en la IAM Service Account del nodo subyacente.

Lo primero es habilitar WIF en tu clúster de GKE y en los node pools si todavía no lo has hecho, pero esto está bien documentado y queda fuera del alcance de este post.

Una vez hecho esto, tendrás que crear una Kubernetes Service Account ( KSA) para que la use tu workload (configurándola en la spec del Pod).

Después, con Workload Identity ( WI), puedes otorgar permisos de IAM de GCP a tus workloads de dos formas:

Mediante suplantación de Google IAM Service Accounts

Esta era la forma estándar y la única manera de configurar WI hasta hace poco; ahora está documentada como la forma alternativa de hacerlo.

En resumen, hay que crear una Google Service Account ( GSA) y otorgarle los permisos de IAM que tu workload necesite. Después se crea un binding entre la GSA y la KSA, asignando a la KSA el rol roles/iam.workloadIdentityUser sobre la GSA, y anotando la KSA en consecuencia.

Mediante identificadores de principal de IAM

Es una función importante y un cambio reciente, como se mencionó en la introducción. Los recursos de Kubernetes pueden referenciarse directamente en políticas de IAM como principals.

Puedes referirte a tu KSA por nombre (para identity sameness) o por UID (disponible en la spec de la KSA tras su creación).

Incluso puedes apuntar a todos los pods de un clúster si todos tus workloads necesitan un permiso de IAM común.

Fuente: https://twitter.com/_techcet_/status/1773865010651173293

Como se ve en la tabla anterior, la configuración se simplificó bastante al introducir la posibilidad de apuntar a recursos de Kubernetes como principals de IAM.

En lugar de tener que gestionar una GSA adicional y acordarte de darle permiso a tu KSA para suplantarla (un paso que muchas veces se olvida), ahora se pueden otorgar los roles de IAM necesarios directamente a la KSA. Tampoco hace falta seguir anotando la KSA con el nombre de la GSA, otro paso que era fácil de configurar mal o de olvidar.

Poder referirse a una KSA por UID en lugar de por nombre es una excelente incorporación y reduce el riesgo de otorgar acceso por accidente a workloads no deseados a través de identity sameness. Por otro lado, usar identity sameness puede ser una ventaja si se aplica correctamente, y hoy es viable en ambas versiones de la configuración.

Además, poder referirse a todos los pods de un clúster como un conjunto de principals de IAM es una función muy útil y aporta más flexibilidad. Estoy seguro de que en los próximos meses veremos soporte para más tipos de recursos de Kubernetes como principals de IAM (los namespaces serían un gran añadido).

Una limitación de usar principals de IAM es que todavía hay algunos servicios que no son compatibles o están en preview. Si actualmente usas WI para acceder a alguno de estos servicios, tendrás que esperar antes de actualizar tu configuración.

La buena noticia es que no tienes que hacerlo: la suplantación con GSA sigue siendo compatible y no creo que vaya a desaparecer pronto.

Sin embargo, usar principals de IAM simplifica la configuración y trae algunos beneficios adicionales, como se describió en la sección anterior, así que recomendaría adoptarlo si es posible.

¿Cuál es la forma con menos fricción de migrar tus workloads de su configuración actual a usar principals de IAM?

Suponiendo que actualmente uses Workload Identity para acceder a recursos de GCP, tendrás una GSA con los permisos de IAM necesarios y una KSA con el rol de IAM Workload Identity User sobre esa GSA.

Por último, tu KSA estaría anotada para apuntar a la GSA, por ejemplo:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: <GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com
  ...

Veamos si podemos hacer una actualización "sin downtime" de la configuración de WI.

Primero, levantemos un pod que use esa KSA para correr algunas pruebas

$ echo 'apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
spec:
  serviceAccountName: <KSA_NAME>
  containers:
  - image: google/cloud-sdk:slim
    command: ["sleep","infinity"]
    name: workload-identity-test' | kubectl apply -f -

Cuando el pod esté listo y en ejecución, podemos entrar con exec

$ kubectl exec -ti token-test -- bash

Desde dentro del pod, podemos hacer una solicitud al metadata server y ver qué identidad está usando

root@token-test:/# curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
{"aliases":["default"],"email":"<GSA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com","scopes":["https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/userinfo.email"]}

En el campo email de la respuesta vemos que nuestra identidad es la GSA que la KSA está configurada para usar (mediante la anotación en la KSA).

¿Qué pasaría si quitamos esa anotación de la KSA?

# esto se ejecuta fuera del pod
$ kubectl annotate serviceaccount <KSA_NAME> iam.gke.io/gcp-service-account-

Probemos esa solicitud de nuevo

root@token-test:/# curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/?recursive=true
{"aliases":["default"],"email":"<PROJECT_ID>.svc.id.goog","scopes":["https://www.googleapis.com/auth/cloud-platform","https://www.googleapis.com/auth/userinfo.email"]}

Como puedes ver, nuestra identidad cambia de inmediato al Workload Identity Pool del proyecto. Esto significa que pasar de la suplantación con GSA al binding con principal de IAM debería funcionar incluso sin reiniciar los pods (ten en cuenta que podría haber ciertos clientes que requieran un reinicio para empezar a usar la nueva identidad).

Suponiendo que tu KSA siga anotada con la GSA y el workload funcione correctamente:

1. Crea la política de IAM para otorgar los roles de IAM necesarios directamente a la KSA (los mismos roles que tenía la GSA)
2. Quita la anotación de WI de la KSA; en ese momento, el pod debería empezar a usar de inmediato los permisos otorgados al principal de la KSA (si ves errores, un reinicio del pod debería resolverlo)
3. Una vez confirmado que todo funciona, puedes eliminar la GSA, ahora redundante, y asegurarte de que tu IaC y tus manifiestos estén al día