En esta página se explica Workload Identity Federation para GKE, incluido su funcionamiento, cómo afecta a tus clústeres de GKE y cómo asignar roles a entidades de Kubernetes en políticas de gestión de identidades y accesos. En la mayoría de los casos, se recomienda usar Workload Identity Federation para que tus cargas de trabajo que se ejecutan en GKE accedan a los servicios de Google Cloud de forma segura y fácil de gestionar.
Esta página está dirigida a especialistas en seguridad y operadores que gestionan cargas de trabajo en GKE que requieren acceso a otros servicios de Google Cloud . Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud
Antes de leer esta página, asegúrate de que conoces los siguientes recursos:
- Para obtener información sobre la federación de identidades de cargas de trabajo en otros entornos, consulta Federación de identidades de cargas de trabajo.
- Para habilitar y usar Workload Identity Federation for GKE, consulta Acceder a APIs desde cargas de trabajo de GKE Google Cloud .
- Para ofrecer compatibilidad con la federación de identidades de cargas de trabajo en clústeres de flotas, usa la identidad de cargas de trabajo de flotas.
Terminología
En esta página se distinguen las cuentas de servicio de Kubernetes y las cuentas de servicio de Gestión de Identidades y Accesos (IAM).
- Cuentas de servicio de Kubernetes
- Recursos de Kubernetes que proporcionan una identidad a los procesos que se ejecutan en tus pods de GKE.
- Cuentas de servicio de gestión de identidades y accesos
- Google Cloud recursos que permiten a las aplicaciones hacer llamadas autorizadas a las Google Cloud APIs.
¿Qué es Workload Identity Federation para GKE?
Las aplicaciones que se ejecutan en GKE pueden necesitar acceso a Google Cloud APIs, como la API de Compute Engine, la API Storage de BigQuery o las APIs de aprendizaje automático.
La federación de identidades de carga de trabajo para GKE te permite usar políticas de IAM para conceder acceso a las cargas de trabajo de Kubernetes de tu clúster de GKE a APIs específicas deGoogle Cloud sin necesidad de configuración manual ni de métodos menos seguros, como los archivos de claves de cuentas de servicio. Si usas Workload Identity Federation for GKE, puedes asignar identidades y autorizaciones distintas y detalladas a cada aplicación de tu clúster.
Workload Identity Federation para GKE sustituye a la necesidad de usar el encubrimiento de metadatos. Los metadatos sensibles protegidos por el ocultamiento de metadatos también están protegidos por Workload Identity Federation para GKE.
Workload Identity Federation para GKE está disponible a través de Workload Identity Federation de IAM, que proporciona identidades para cargas de trabajo que se ejecutan en entornos internos y externos Google Cloud. Puedes usar la federación de identidades de carga de trabajo de IAM para autenticarte de forma segura en las APIs compatibles Google Cloud desde cargas de trabajo que se ejecutan en AWS, Azure y Kubernetes autogestionado, entre otros. En GKE,Google Cloud gestiona el grupo y el proveedor de identidades de carga de trabajo por ti y no requiere un proveedor de identidades externo.
Cómo funciona Workload Identity Federation para GKE
Cuando habilitas Workload Identity Federation para GKE en un clúster, GKE hace lo siguiente:
Crea un grupo de identidades de carga de trabajo fijo para el proyecto del clúster Google Cloud con el siguiente formato:
PROJECT_ID.svc.id.googEl grupo de identidades de carga de trabajo proporciona un formato de nomenclatura que permite a IAM comprender y confiar en las credenciales de Kubernetes. GKE no elimina este grupo de identidades de carga de trabajo aunque elimines todos los clústeres de tu proyecto.
Registra el clúster de GKE como proveedor de identidades en el grupo de identidades de carga de trabajo.
Implementa el servidor de metadatos de GKE, que intercepta las solicitudes de credenciales de las cargas de trabajo, en todos los nodos.
Crear políticas de gestión de identidades y accesos de permiso en Google Cloud recursos
Para proporcionar acceso con la federación de identidades de carga de trabajo para GKE, crea una política de permisos de IAM que conceda acceso a un Google Cloud recurso
específico a una entidad principal que corresponda a la identidad de tu aplicación. Por ejemplo, puedes dar permisos de lectura en un segmento de Cloud Storage a todos los pods que usen la database-reader cuenta de servicio de Kubernetes.
Para ver una lista de los recursos que admiten políticas de permiso, consulta Tipos de recursos que aceptan políticas de permiso.
Usar condiciones en políticas de gestión de identidades y accesos
También puedes limitar el alcance del acceso definiendo condiciones en tus políticas de permiso. Las condiciones son un método extensible para especificar cuándo se debe aplicar una política de permiso. Por ejemplo, puedes usar condiciones para conceder acceso temporal a una carga de trabajo en un recurso Google Cloud específico, lo que elimina la necesidad de gestionar ese acceso manualmente.
Las condiciones también pueden ser útiles si configuras tus políticas de permiso a nivel de proyecto, carpeta u organización en lugar de en recursos específicos, como secretos de Secret Manager o segmentos de Cloud Storage.
Para añadir una condición a tu política de permisos, consulta los siguientes recursos:
- Gestionar vinculaciones de roles condicionales: añadir, modificar o quitar vinculaciones de roles condicionales.
- Configurar el acceso temporal: usa condiciones para definir el acceso con fecha de vencimiento a los recursos de las políticas de permiso. Google Cloud
- Etiquetas y acceso condicional: usa condiciones para aplicar políticas de permiso solo cuando los recursos tengan etiquetas específicas.
Las siguientes expresiones de ejemplo corresponden a situaciones habituales en las que puede usar condiciones. Para ver una lista de los atributos disponibles en las expresiones, consulta la referencia de atributos de las condiciones de gestión de identidades y accesos.
| Ejemplos de expresiones de condición | ||
|---|---|---|
| Permitir el acceso antes de la hora especificada | request.time < timestamp('Sustituye |
|
| Permite el acceso si el recurso de la solicitud tiene la etiqueta especificada | resource.matchTag('Haz los cambios siguientes:
|
|
Hacer referencia a recursos de Kubernetes en políticas de gestión de identidades y accesos
En tu política de gestión de identidades y accesos, haces referencia a un recurso de Kubernetes mediante un identificador de principal de gestión de identidades y accesos 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, tenemos los siguientes campos:
PREFIX: debe serprincipaloprincipalSeten función del recurso que selecciones.principales para un recurso específico, como una sola ServiceAccount.principalSetse usa para varios recursos que pertenecen al recurso especificado, como todos los pods de un clúster concreto.SELECTOR: cadena que selecciona un tipo de principal. Por ejemplo,kubernetes.serviceaccount.uid/SERVICEACCOUNT_UIDselecciona un ServiceAccount por su UID.
En la siguiente tabla se muestran los tipos de principales admitidos en GKE:
| Tipo de identificador principal | Sintaxis |
|---|---|
| Todos los pods que usan una cuenta de servicio de Kubernetes específica | Selecciona la cuenta de servicio por nombre:
principal://iam.googleapis.com/projects/Haz los cambios siguientes:
Selecciona la cuenta de servicio por UID: principal://iam.googleapis.com/projects/Haz los cambios siguientes:
|
| Todos los pods de un espacio de nombres, independientemente de la cuenta de servicio o del clúster | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE Haz los cambios siguientes:
|
| Todos los pods de 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 Haz los cambios siguientes:
|
Flujo de credenciales
Cuando una carga de trabajo envía una solicitud para acceder a una API (por ejemplo, al usar una biblioteca de cliente), se siguen estos pasos de autenticación: Google Cloud Google Cloud
- Las credenciales predeterminadas de la aplicación (ADC) solicitan un Google Cloud token de acceso al servidor de metadatos de Compute Engine que se ejecuta en la VM.
- El servidor de metadatos de GKE intercepta la solicitud de token y pide al servidor de la API de Kubernetes un token de cuenta de servicio de Kubernetes que identifique la carga de trabajo que realiza la solicitud. 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 que hace referencia a la identidad de la carga de trabajo de Kubernetes.
El token de acceso federado que devuelve el servicio de tokens de seguridad puede tener limitaciones al intentar acceder a algunos Google Cloud servicios, tal como se describe en Productos admitidos y limitaciones. Si el servicio que has seleccionado tiene limitaciones, puedes configurar opcionalmente la suplantación de identidad de la cuenta de servicio. Google Cloud Este método genera un token de acceso para una cuenta de servicio de gestión de identidades y accesos que tu carga de trabajo puede usar para acceder al servicio de destino. Para obtener más información, consulta el artículo sobre cómo vincular cuentas de servicio de Kubernetes a IAM.
La carga de trabajo puede acceder a cualquier API a la que pueda acceder el identificador principal de IAM de la carga de trabajo. Google Cloud
Cuota de la API Exchange Token en Security Token Service
La API Exchange Token del servicio de tokens de seguridad tiene un límite de cuota de 6000 solicitudes por minuto. Si se producen errores QUOTA_EXCEEDED, puedes solicitar un aumento de la cuota Token exchange requests per minute a través de la página Cuotas y límites del sistema.
Identidad idéntica
Si los metadatos del identificador principal son los mismos para las cargas de trabajo de varios clústeres que comparten un grupo de identidades de carga de trabajo porque pertenecen al mismo proyecto, IAM identifica esas cargas de trabajo como la misma. Google Cloud Por ejemplo, si tienes el mismo espacio de nombres en dos clústeres y concedes acceso a ese espacio de nombres en IAM, las cargas de trabajo de ese espacio de nombres en ambos clústeres obtendrán ese acceso. Puedes limitar este acceso a clústeres específicos mediante políticas de gestión de identidades y accesos condicionales.
Por ejemplo, consulta el siguiente diagrama. Los clústeres A y B pertenecen al mismo grupo de identidades de carga de trabajo. Google Cloud identifica las aplicaciones que usan la back-ksa ServiceAccount en el espacio de nombres backend de los clústeres A y B como la misma identidad. IAM no distingue entre los clústeres que realizan las llamadas.
Esta igualdad de identidad también significa que debes poder confiar en todos los clústeres de un grupo de identidades de carga de trabajo específico. Por ejemplo, si un equipo no fiable fuera el propietario de un nuevo clúster, el clúster C del ejemplo anterior, podría crear un espacio de nombres backend y acceder Google Cloud a las APIs mediante la back-ksa
ServiceAccount, al igual que el clúster A y el clúster B.
Para evitar el acceso no fiable, coloque sus clústeres en proyectos independientes para asegurarse de que obtengan grupos de identidades de carga de trabajo diferentes o de que los nombres de los espacios de nombres sean distintos entre sí para evitar un identificador principal común.
Servidor de metadatos de GKE
Cada nodo de un clúster de GKE con Workload Identity Federation for GKE habilitado almacena sus metadatos en el servidor de metadatos de GKE. El servidor de metadatos de GKE es un subconjunto de los endpoints 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 obtiene un token para la cuenta de servicio de gestión de identidades y accesos que se ha configurado para que el pod suplante.
El tráfico al servidor de metadatos de GKE nunca sale de la instancia de VM que aloja el pod.
Tiempo de vida del token
De forma predeterminada, el token de acceso devuelto tiene una duración de 1 hora (3600 segundos). Para reducir la latencia del cliente, el servidor de metadatos de GKE almacena en caché los tokens de acceso. En algunos casos, el token almacenado en caché que devuelve el servidor de metadatos puede estar cerca de su hora de vencimiento.
Las bibliotecas de cliente de Cloud tienen una lógica integrada que, de forma predeterminada, comprueba si el token de acceso caduca en los próximos 3 minutos y 45 segundos. Si el token está dentro del periodo de validez, GKE lo actualiza. Las llamadas a la API consecutivas pueden usar el token actualizado.
Si usas tu propio código para acceder directamente a las APIs de Google Cloud , implementa una lógica similar para gestionar la caducidad de los tokens. Tu código debe hacer lo siguiente:
- Comprueba si el token de acceso caduca al cabo de 3 minutos y 45 segundos. El parámetro
expde la carga útil del token indica la marca de tiempo de caducidad del token. - Si el token va a caducar en los próximos 3 minutos y 45 segundos, haz una solicitud de token.
En las siguientes tablas se describe el subconjunto de endpoints del servidor de metadatos de Compute Engine que están disponibles con el servidor de metadatos de GKE. Para ver una lista completa de los endpoints disponibles en el servidor de metadatos de Compute Engine, consulta Valores de metadatos de VM predeterminados.
Metadatos de instancias
Los metadatos de 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 al nodo. Para cada cuenta de servicio, se muestra la siguiente información:
|
zone |
La zona de Compute Engine de tu nodo de GKE. |
Atributos de instancia
Los atributos de instancia se almacenan en el siguiente directorio.
http://metadata.google.internal/computeMetadata/v1/instance/attributes/
| Entrada | Descripción |
|---|---|
cluster-location |
La zona o la región de Compute Engine de tu clúster. |
cluster-name |
El nombre de tu clúster de GKE. |
cluster-uid |
El UID de tu clúster de GKE. |
Los atributos que se indican en la tabla son los únicos que se admiten. Si intentas acceder a algún atributo no admitido, el gke-metadata-server pod del espacio de nombres kube-system genera y registra un error 404.
El error es similar al siguiente:
HTTP/404: generic::not_found: no child "", Reason: "NOT_FOUND", UserMessage: "Not Found"
Si usas istio-proxy, verás un mensaje de error como el siguiente:
Error fetching GCP Metadata property gcp_gce_instance_template: metadata: GCE metadata "instance/attributes/UNSUPPORTED_ATTRIBUTE" not defined
Metadatos del proyecto
Los metadatos del proyecto de clúster se almacenan en el siguiente directorio.
http://metadata.google.internal/computeMetadata/v1/project/
| Entrada | Descripción |
|---|---|
project-id |
El ID de tu proyecto Google Cloud . |
numeric-project-id |
Tu número de proyecto de Google Cloud . |
Restricciones de Workload Identity Federation para GKE
No puedes cambiar el nombre del grupo de identidades de carga de trabajo que crea GKE para tu Google Cloud proyecto.
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 su lugar, el servidor de metadatos de GKE intercepta las solicitudes que se hacen desde estos pods a los endpoints de metadatos, excepto los pods que se ejecutan en la red del host.
Cuando se usa el controlador CSI de Cloud Storage FUSE con clústeres de GKE estándar con la versión
1.33.3-gke.1226000o posterior, los pods que se ejecutan en la red del host (hostNetwork: true) pueden autenticarse con su propia cuenta de servicio de Kubernetes. Para obtener más información, consulta Configurar el acceso para pods con la red del host.El servidor de metadatos de GKE tarda unos segundos en empezar a aceptar solicitudes en un pod recién creado. Por lo tanto, los intentos de autenticación mediante Workload Identity Federation for GKE durante los primeros segundos de la vida de un pod pueden fallar. Si vuelves a intentarlo, se solucionará el problema. Consulta Solución de problemas para obtener más información.
Los agentes de registro y monitorización integrados de GKE siguen usando la cuenta de servicio del nodo.
Workload Identity Federation para GKE requiere una configuración manual para que Knative Serving siga publicando métricas de solicitudes.
Workload Identity Federation para GKE establece un límite de 500 conexiones simultáneas al servidor de metadatos de GKE por cada nodo. Las llamadas simultáneas adicionales que superen este límite se colocan en una cola de espera para procesarse más adelante. Este mecanismo de colas puede provocar errores de
HTTP/499si se alcanza el tiempo de espera del cliente antes de que el servidor de metadatos de GKE pueda procesar la solicitud.Workload Identity Federation para GKE para nodos de Windows Server está disponible en las versiones 1.18.16-gke.1200, 1.19.8-gke.1300 y 1.20.4-gke.1500 de GKE, así como en versiones posteriores.
El servidor de metadatos de GKE usa recursos de memoria proporcionales al número total de cuentas de servicio de Kubernetes de tu clúster. Si tu clúster tiene más de 3000 cuentas de servicio de Kubernetes, es posible que kubelet finalice los pods del servidor de metadatos. Para obtener información sobre las medidas de mitigación, consulta la sección Solución de problemas.
Workload Identity Federation para GKE funciona dentro de un perímetro de Controles de Servicio de VPC, lo que permite acceder a los recursos que contiene. Sin embargo, Controles de Servicio de VPC no aplica el control de acceso a las solicitudes entre perímetros en función de estas identidades federadas. Puedes usar la suplantación de identidad de cuenta de servicio para acceder a recursos de otro perímetro.
Alternativas a Workload Identity Federation para GKE
Puedes usar una de las siguientes alternativas a Workload Identity Federation para GKE para acceder a las APIs desde GKE.Google Cloud Te recomendamos que uses la federación de Workload Identity para GKE, ya que las alternativas requieren que hagas ciertos sacrificios en materia de seguridad.
Usa la cuenta de servicio predeterminada de Compute Engine de tus nodos. Puedes ejecutar grupos de nodos como cualquier cuenta de servicio de IAM de tu proyecto. Si no especificas una cuenta de servicio durante la creación del grupo de nodos, GKE usará la cuenta de servicio predeterminada de Compute Engine del proyecto. La cuenta de servicio de Compute Engine se comparte entre todas las cargas de trabajo implementadas en ese nodo. Esto puede provocar un aprovisionamiento excesivo de permisos, lo que infringe el principio de mínimos accesos y no es adecuado para clústeres multiinquilino.
Exporta las claves de cuenta de servicio y guárdalas como secretos de Kubernetes que montarás en tus pods como volúmenes.
Siguientes pasos
- Consulta cómo habilitar y configurar Workload Identity Federation para GKE.
- Consulta información sobre el servidor de metadatos de Compute Engine.