Descripción general de Workload Identity

Workload Identity te permite asignar identidades y autorizaciones distintas y detalladas para cada aplicación en el clúster. Workload Identity es la forma recomendada para que las aplicaciones que se ejecutan dentro de los clústeres de GKE alojados en Azure accedan a los servicios de Azure y Google Cloud.

Todos los clústeres de GKE tienen habilitada la identidad de carga de trabajo.

Cuentas de servicio de Kubernetes

Workload Identity implementa la federación de identidad o delega la confianza o las funciones a un proveedor externo. Cada clúster tiene un proveedor integrado de OpenID Connect (OIDC) integrado. Cuando un Pod se ejecuta en el clúster, se ejecuta con una cuenta de servicio de Kubernetes. El Pod se puede configurar a fin de obtener un token con credenciales de corta duración para su cuenta de servicio de Kubernetes mediante un volumen de token de cuenta de servicio vinculado.

Proveedores de OpenID Connect

Cada clúster puede actuar como un proveedor de OpenID Connect (OIDC). Con este proveedor, puedes proporcionar credenciales de cuenta de servicio de Kubernetes a servicios que admiten la federación de identidades mediante OIDC.

El URI de la entidad emisora de este proveedor también funciona como un extremo de detección de OIDC. Los servicios pueden usar este extremo de descubrimiento para obtener el conjunto de claves web JSON (JWKS), que proporciona información de clave pública que les permite verificar las credenciales de la cuenta de servicio de Kubernetes.

Grupos de identidades y proveedores de Google Cloud IAM

Google Cloud IAM admite la federación de identidad con OIDC. Todos los clústeres de GKE se configuran como proveedores de identidad en el grupo de identidades para cargas de trabajo PROJECT_ID.svc.id.goog.

Para obtener el nombre de tu proveedor y el grupo de identidades para cargas de trabajo, consulta Usa Workload Identity con Google Cloud.

Alternativas a Workload Identity

Existen métodos alternativos para acceder a los servicios desde GKE en Azure. No recomendamos los siguientes métodos debido a las complicaciones.

  1. Exporta credenciales y almacénalas como secretos de Kubernetes. En este caso, debes rotar las credenciales almacenadas de forma manual en Azure IAM y en el clúster. Además, si un atacante roba credenciales, puede aprovecharlas.

  2. Adjunta credenciales a las instancias subyacentes de los grupos de nodos. En este caso, todas las cargas de trabajo que se ejecutan en el mismo nodo comparten las credenciales, lo que puede generar un conjunto mayor de permisos de los que podrían necesitar las cargas de trabajo. Para bloquear el acceso a los permisos de una instancia, los clústeres de GKE bloquean el acceso de un Pod al servicio de metadatos de la instancia.

¿Qué sigue?