La Federación de identidades para cargas de trabajo es la manera recomendada para que las cargas de trabajo que se ejecutan en Google Kubernetes Engine (GKE) accedan a los servicios de Google Cloud de manera segura y administrable.
La federación de identidades para cargas de trabajo para GKE está disponible a través de la federación de identidades para cargas de trabajo de IAM, que proporciona identidades para las cargas de trabajo que se ejecutan en entornos dentro y fuera de Google Cloud. Puedes usar la federación de identidades para cargas de trabajo de IAM para autenticarte de forma segura en las APIs de Google Cloud compatibles desde cargas de trabajo que se ejecutan en, por ejemplo, AWS, Azure y Kubernetes autoadministrado. En GKE, Google Cloud administra el grupo y el proveedor de Workload Identity por ti y no requiere un proveedor de identidad externo.
- Para obtener información sobre la federación de identidades para cargas de trabajo en otros entornos, consulta Federación de identidades para cargas de trabajo.
- Si deseas habilitar y usar la federación de identidades para cargas de trabajo para GKE, consulta Accede a las APIs de Google Cloud desde cargas de trabajo de GKE.
- Para proporcionar asistencia para la federación de identidades para cargas de trabajo para clústeres en flotas, usa la identidad de carga de trabajo de flota.
Terminología
En este documento, se distingue entre cuentas de servicio de Kubernetes y cuentas de servicio de Identity and Access Management (IAM).
- Cuentas de servicio de Kubernetes
- Recursos de Kubernetes que proporcionan una identidad para los procesos que se ejecutan en tus Pods de GKE.
- Cuentas de servicio de IAM
- Recursos de Google Cloud que permiten a las aplicaciones realizar llamadas autorizadas a las APIs de Google Cloud.
¿Qué es la federación de identidades para cargas de trabajo para GKE?
Es posible que las aplicaciones que se ejecutan en GKE necesiten acceso a las APIs de Google Cloud, como la API de Compute Engine, la API de BigQuery Storage o las APIs de aprendizaje automático.
La federación de identidades para cargas de trabajo para GKE te permite usar políticas de IAM para otorgar a las cargas de trabajo de Kubernetes en tu clúster de GKE acceso a APIs específicas de Google Cloud sin necesidad de una configuración manual ni métodos menos seguros, como los archivos de claves de la cuenta de servicio. El uso de la federación de identidades para cargas de trabajo para GKE te permite asignar identidades y autorizaciones distintas y detalladas para cada aplicación en el clúster.
La federación de identidades para cargas de trabajo para GKE reemplaza la necesidad de usar ocultamiento de metadatos. Los metadatos sensibles protegidos con la ocultación de metadatos también están protegidos por la federación de identidades para cargas de trabajo para GKE.
Cómo funciona la federación de identidades para cargas de trabajo para GKE
Cuando habilitas la federación de identidades para cargas de trabajo para GKE en un clúster, GKE hace lo siguiente:
Crea un grupo de identidades para cargas de trabajo fijo para el proyecto de Google Cloud del clúster con el siguiente formato:
PROJECT_ID.svc.id.googEl grupo de identidades para cargas de trabajo proporciona un formato de nombre que permite a IAM comprender y confiar en las credenciales de la cuenta de servicio de Kubernetes.
Registra el clúster de GKE como un proveedor de identidad en el grupo de Workload Identity.
Implementa el servidor de metadatos de GKE, que intercepta las solicitudes de credenciales de las cargas de trabajo en cada nodo.
Crea políticas de permisos de IAM en los recursos de Google Cloud
Para proporcionar acceso con la federación de identidades para cargas de trabajo para GKE, crea una política de permisos de IAM que otorgue acceso en un recurso específico de Google Cloud a una principal que corresponda a la identidad de tu aplicación. Por ejemplo, puedes otorgar permisos de lectura en un bucket de Cloud Storage a todos los Pods que usan la ServiceAccount de Kubernetes database-reader.
Para obtener una lista de los recursos que admiten políticas de permisos, consulta Tipos de recursos que aceptan políticas de permisos.
También puedes limitar el permiso del acceso si configuras condiciones en las políticas de permisos. Por ejemplo, si solo deseas otorgar acceso de lectura en un bucket a los Pods que usan la ServiceAccount database-reader en el clúster mysql, puedes establecer esa condición en tu política de permisos. Para obtener información sobre el uso de condiciones en las políticas de permisos, consulta Administra vinculaciones de roles condicionales.
Recursos de referencia de Kubernetes en las políticas de IAM
En tu política de IAM, haces referencia a un recurso de Kubernetes mediante un identificador principal de IAM para seleccionar el recurso. Este identificador tiene la siguiente sintaxis:
PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR
En este ejemplo, considera los siguientes campos:
PREFIX: Debe serprincipaloprincipalSet, según el recurso que selecciones.principales para un recurso específico, como una sola ServiceAccount.principalSetes para varios recursos que pertenecen al recurso especificado, como todos los Pods en un clúster específico.SELECTOR: una string que selecciona un tipo de principal. Por ejemplo,kubernetes.serviceaccount.uid/SERVICEACCOUNT_UIDselecciona una ServiceAccount por su UID.
En la siguiente tabla, se muestran los tipos de principales compatibles en GKE:
| Tipo de identificador principal | Sintaxis |
|---|---|
| Todos los pods que usan una ServiceAccount de Kubernetes específica | Selecciona la ServiceAccount por nombre:
principal://iam.googleapis.com/projects/
Reemplaza lo siguiente:
Selecciona la ServiceAccount por UID: principal://iam.googleapis.com/projects/
Reemplaza lo siguiente:
|
| Todos los Pods en un clúster específico | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME Reemplaza lo siguiente:
|
Flujo de credenciales
Cuando una carga de trabajo envía una solicitud para acceder a una API de Google Cloud, por ejemplo, cuando se usa una biblioteca cliente de Google Cloud, se producen los siguientes pasos de autenticación:
- Las credenciales predeterminadas de la aplicación (ADC) solicitan un token de acceso de Google Cloud desde el servidor de metadatos de Compute Engine que se ejecuta en la VM.
- El servidor de metadatos de GKE intercepta la solicitud del token y solicita al servidor de la API de Kubernetes un token de cuenta de servicio de Kubernetes que identifique la carga de trabajo solicitante. Esta credencial es un token web JSON (JWT) firmado por el servidor de la API.
- El servidor de metadatos de GKE usa el servicio de tokens de seguridad para intercambiar el JWT por un token de acceso federado de corta duración de Google Cloud que hace referencia a la identidad de la carga de trabajo de Kubernetes.
- El servidor de metadatos de GKE proporciona el token de acceso federado a la carga de trabajo.
Luego, la carga de trabajo puede acceder a cualquier API de Google Cloud a la que pueda acceder el identificador principal de IAM de la carga de trabajo.
Similitud de identidad
Si los metadatos en tu identificador principal son los mismos para las cargas de trabajo en varios clústeres que comparten un grupo de grupo de identidades para cargas de trabajo porque pertenecen al mismo proyecto de Google Cloud, IAM identifica esas cargas de trabajo como iguales. Por ejemplo, si tienes el mismo espacio de nombres en dos clústeres y otorgas acceso a ese espacio de nombres en IAM, las cargas de trabajo en ese espacio de nombres en ambos clústeres obtienen ese acceso. Puedes limitar este acceso a clústeres específicos mediante las políticas de IAM condicionales.
Por ejemplo, considera el siguiente diagrama. Los clústeres A, B y C pertenecen al mismo grupo de identidades para cargas de trabajo. Google Cloud identifica las aplicaciones que usan la ServiceAccount back-ksa en el espacio de nombres backend del Clúster A y el Clúster B como la misma identidad. IAM no distingue entre los clústeres que realizan las llamadas.
Esta similitud de identidad también significa que debes poder confiar en cada clúster de un grupo de identidades para cargas de trabajo específico. Por ejemplo, si el clúster C del ejemplo anterior fuera propiedad de un equipo no confiable, este podría crear un espacio de nombres backend y acceder a las API de Google Cloud mediante la ServiceAccount back-ksa de IAM, al igual que el clúster A y el clúster B.
Para evitar el acceso no confiable, coloca tus clústeres en proyectos separados a fin de asegurarte de que tengan grupos de Workload Identity diferentes o asegúrate de que los nombres de los espacios de nombres sean distintos para evitar un identificador principal común.
Comprende el servidor de metadatos de GKE
Cada nodo en un GKE con la federación de identidades para cargas de trabajo para GKE habilitada almacena sus metadatos en el servidor de metadatos de GKE. El servidor de metadatos de GKE es un subconjunto de los extremos del servidor de metadatos de Compute Engine necesarios para las cargas de trabajo de Kubernetes.
El servidor de metadatos de GKE se ejecuta como un DaemonSet, con un Pod en cada nodo de Linux o un servicio nativo de Windows en cada nodo de Windows del clúster. El servidor de metadatos intercepta las solicitudes HTTP a http://metadata.google.internal (169.254.169.254:80). Por ejemplo, la solicitud GET
/computeMetadata/v1/instance/service-accounts/default/token recupera un token para la cuenta de servicio de IAM a la que el Pod está configurado en nombre de una cuenta.
El tráfico del servidor de metadatos de GKE nunca sale de la instancia de VM que aloja al Pod.
En las siguientes tablas, se describe el subconjunto de extremos del servidor de metadatos de Compute Engine disponibles con el servidor de metadatos de GKE. Para obtener una lista completa de los extremos disponibles en el servidor de metadatos de Compute Engine, consulta los valores de metadatos de VM predeterminados.
Metadatos de la instancia
Los metadatos de la instancia se almacenan en el siguiente directorio.
http://metadata.google.internal/computeMetadata/v1/instance/
| Entrada | Descripción |
|---|---|
hostname |
El nombre de host de tu nodo. |
id |
El ID único de tu nodo. |
service-accounts/ |
Un directorio de cuentas de servicio asociadas a la instancia. Para cada cuenta de servicio, está disponible la siguiente información:
|
zone |
La zona de Compute Engine de tu nodo de GKE. |
Atributos de la instancia
Los atributos de instancias se almacenan en el siguiente directorio:
http://metadata.google.internal/computeMetadata/v1/instance/attributes/
| Entrada | Descripción |
|---|---|
cluster-location |
La zona o región de Compute Engine de tu clúster. |
cluster-name |
El nombre del clúster de GKE. |
cluster-uid |
El UID del clúster de GKE. |
Metadatos del proyecto
Los metadatos del proyecto del clúster se almacenan en el siguiente directorio.
http://metadata.google.internal/computeMetadata/v1/project/
| Entrada | Descripción |
|---|---|
project-id |
Tu ID del proyecto de Google Cloud. |
numeric-project-id |
Es el número de tu proyecto de Google Cloud. |
Restricciones de la federación de identidades para cargas de trabajo para GKE
No puedes cambiar el nombre del grupo de Workload Identity que GKE crea para tu proyecto de Google Cloud.
Cuando GKE habilita el servidor de metadatos de GKE en un grupo de nodos, los Pods ya no pueden acceder al servidor de metadatos de Compute Engine. En cambio, el servidor de metadatos de GKE intercepta las solicitudes realizadas de estos Pods a los extremos de metadatos, excepto los Pods que se ejecutan en la red del host.
El servidor de metadatos de GKE toma unos segundos en comenzar a aceptar solicitudes en un Pod recién creado. Por lo tanto, los intentos de autenticación mediante la federación de identidades para cargas de trabajo para GKE en los primeros segundos de la vida del Pod podrían fallar. Intentar la llamada resolverá el problema. Consulta Solución de problemas para obtener más detalles.
Los agentes integrados de supervisión y registro de GKE seguirán usando la cuenta de servicio del nodo.
La federación de identidades para cargas de trabajo para GKE requiere una configuración manual para Knative serving a fin de continuar lanzando métricas de solicitudes.
La federación de identidades para cargas de trabajo para GKE establece un límite de 200 conexiones al servidor de metadatos de GKE para cada nodo a fin de evitar problemas de memoria. Es posible que experimentes tiempos de espera si los nodos exceden este límite.
La federación de identidades para cargas de trabajo para GKE paras nodos de Windows Server está disponible en las versiones de GKE 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 y posteriores.
El servidor de metadatos de GKE usa recursos de memoria de forma proporcional a la cantidad total de cuentas de servicio de Kubernetes en tu clúster. Si tu clúster tiene más de 3,000 cuentas de servicio de Kubernetes, kubelet podría finalizar los Pods del servidor de metadatos. Para conocer las mitigaciones, consulta Solución de problemas.
Alternativas a la federación de identidades para cargas de trabajo para GKE
Puedes usar una de las siguientes alternativas a la federación de identidades para cargas de trabajo para que GKE acceda a las APIs de Google Cloud desde GKE. Te recomendamos que uses la federación de identidades para cargas de trabajo para GKE, ya que estas alternativas requieren que realices compromisos de seguridad determinados.
Usa la cuenta de servicio predeterminada de Compute Engine de tus nodos. Puedes ejecutar grupos de nodos como cualquier cuenta de servicio de IAM en tu proyecto. Si no especificas una cuenta de servicio durante la creación del grupo de nodos, GKE usa la cuenta de servicio predeterminada de Compute Engine para el proyecto. Todas las cargas de trabajo implementadas en ese nodo comparten la cuenta de servicio de Compute Engine. Esto puede generar un aprovisionamiento excesivo de permisos, lo que infringe el principio de privilegio mínimo y es inapropiado para los clústeres de multiusuario.
Exporta claves de cuenta de servicio y almacénalas como secretos de Kubernetes que actives en los Pods como volúmenes.
¿Qué sigue?
- Obtén más información sobre cómo habilitar y configurar la federación de identidades para cargas de trabajo para GKE.
- Obtén más información sobre el servidor de metadatos de Compute Engine.