En este documento, se describen las cuentas de servicio en Google Kubernetes Engine (GKE) y cómo proporcionan identidades para las aplicaciones. Aprenderás sobre los diferentes tipos de cuentas de servicio y cuándo usar cada tipo para autenticar el acceso a los recursos dentro de GKE sin depender de credenciales personales.
Este documento está dirigido a operadores y especialistas en seguridad que crean y administran cuentas de servicio para interactuar con aplicaciones de GKE. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.
Cuentas de servicio de Kubernetes y cuentas de servicio de IAM
En la siguiente tabla, se describen las principales diferencias entre las cuentas de servicio de Kubernetes y las cuentas de servicio de IAM:
| Tipos de cuentas de servicio en GKE | |
|---|---|
| Cuenta de servicio de Kubernetes |
|
| Cuenta de servicio de IAM |
|
Cuentas de servicio de Kubernetes
Las cuentas de servicio de Kubernetes se administran a nivel del clúster y existen en el servidor de la API de Kubernetes como objetos ServiceAccount. En la documentación de Kubernetes y la documentación de GKE, a menudo se usa el término ServiceAccount para distinguir estos recursos de Kubernetes de las cuentas de servicio en otros entornos, como IAM.
Crea una ServiceAccount de Kubernetes en un espacio de nombres y, luego, asígnale esa ServiceAccount a un Pod con el campo serviceAccountName en el manifiesto del Pod. El proceso de kubelet en el nodo obtiene un token de portador de corta duración para la cuenta de servicio asignada y activa el token como un volumen proyectado en el Pod. De forma predeterminada, este volumen proyectado tiene un nombre que comienza con el prefijo kube-api-access-. GKE administra todos los volúmenes que comienzan con este prefijo, lo que significa que no puedes modificar el tamaño de estos volúmenes. Para supervisar el uso del disco con mayor precisión, excluye de la configuración de supervisión los volúmenes que comiencen con el prefijo kube-api-access-.
El token del portador de corta duración es un token web JSON (JWT) firmado por el servidor de la API, que es un proveedor de OpenID Connect (OIDC). Para validar el token del portador, obtén la clave de validación pública para el clúster mediante una llamada al método projects.locations.clusters.getJwks en la API de GKE.
- Para conocer los conceptos básicos de las cuentas de servicio de Kubernetes, consulta Cuentas de servicio en la documentación de Kubernetes.
- Para obtener información sobre cómo crear cuentas de servicio nuevas, otorgar permisos mediante el control de acceso basado en roles (RBAC) y asignar cuentas de servicio a los Pods, consulta Configura cuentas de servicio para Pods.
- Si deseas conocer las prácticas recomendadas sobre la administración de las cuentas de servicio de Kubernetes, consulta Prácticas recomendadas para el RBAC.
- Para leer la configuración de OIDC del servidor de la API de Kubernetes de un clúster, llama al método
projects.locations.clusters.well-known.getOpenid-configurationen la API de GKE.
Credenciales de la cuenta de servicio de Kubernetes comprometidas
Si se vulnera una credencial de cuenta de servicio de Kubernetes, usa una de las siguientes opciones para revocarla:
- Vuelve a crear tus Pods: El token del portador está vinculado a cada UID de Pod único, por lo que volver a crear los Pods invalida las credenciales anteriores.
- Vuelve a crear la cuenta de servicio de Kubernetes: El token de portador está vinculado al UID del objeto ServiceAccount en la API de Kubernetes. Borra la ServiceAccount y crea una nueva con el mismo nombre. Los tokens anteriores dejan de ser válidos porque el UID de la nueva ServiceAccount es diferente.
- Realiza una rotación de credenciales: Esta operación revoca todas las credenciales de la cuenta de servicio de Kubernetes en tu clúster. La rotación también cambia el certificado de CA y la dirección IP de tu clúster. Para obtener más detalles, consulta rotación de credenciales.
Cuentas de servicio de IAM
Las cuentas de servicio de IAM se administran a nivel del proyecto con la API de IAM. Puedes usar estas cuentas de servicio para realizar acciones como llamar a las APIs de Google Cloudde manera programática y administrar permisos para las aplicaciones que se ejecutan en productos de Google Cloud.
Para obtener más información, consulta la descripción general de las cuentas de servicio de IAM.
Agentes de servicio de GKE
Un agente de servicio de IAM es una cuenta de servicio de IAM que Google Cloud administra. GKE usa los siguientes dos agentes de servicio:
- Agente de servicio de Kubernetes Engine
- Agente de servicio de nodos predeterminado de Kubernetes Engine
Agente de servicios de Kubernetes Engine
GKE usa el agente de servicio de Kubernetes Engine para administrar el ciclo de vida de los recursos del clúster en tu nombre, como los nodos, los discos y los balanceadores de cargas. Este agente de servicio tiene el dominio container-engine-robot.iam.gserviceaccount.com y se le otorga el rol Agente de servicio de Kubernetes Engine (roles/container.serviceAgent) en tu proyecto cuando habilitas: la API de GKE.
El identificador de este agente de servicio es el siguiente:
service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
CLUSTER_PROJECT_NUMBER es el número de proyecto numérico del proyecto que contiene tu clúster de GKE.
Agente de servicio de nodos predeterminado de Kubernetes Engine
GKE usa el agente de servicio de nodos predeterminado de Kubernetes Engine para admitir el registro y la supervisión de nodos de Kubernetes para clústeres que usan la versión 1.33 y versiones posteriores de Kubernetes. Este agente de servicio tiene el dominio gcp-sa-gkenode.iam.gserviceaccount.com y se le otorga el rol Agente de servicio de nodo predeterminado de Kubernetes Engine (roles/container.defaultNodeServiceAgent) en tu proyecto cuando habilitas la API de GKE.
El identificador de este agente de servicio es el siguiente:
service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com
CLUSTER_PROJECT_NUMBER es el número de proyecto numérico del proyecto que contiene tu clúster de GKE.
Si quitas los permisos del agente de servicio en tu proyecto, puedes recuperarlos si sigues las instrucciones de Error 400/403: Faltan permisos de edición en la cuenta.
Cuentas de servicio de nodos
GKE usa cuentas de servicio de IAM adjuntas a tus nodos para ejecutar tareas del sistema, como el registro y la supervisión. Como mínimo, estas cuentas de servicio de nodo deben tener el rol de cuenta de servicio de nodo predeterminado de Kubernetes Engine (roles/container.defaultNodeServiceAccount) en tu proyecto. De forma predeterminada, GKE usa la cuenta de servicio predeterminada de Compute Engine, que se crea automáticamente en tu proyecto, como la cuenta de servicio del nodo.
Si tu organización aplica la restricción de la política de la organización iam.automaticIamGrantsForDefaultServiceAccounts, es posible que la cuenta de servicio predeterminada de Compute Engine en tu proyecto no obtenga automáticamente los permisos requeridos para GKE.
Si usas la cuenta de servicio predeterminada de Compute Engine para otras funciones en tu proyecto u organización, es posible que la cuenta de servicio tenga más permisos de los que necesita GKE, lo que podría exponerte a riesgos de seguridad.
No inhabilites la cuenta de servicio predeterminada de Compute Engine, a menos que migres a cuentas de servicio administradas por el usuario.
Direcciones de correo electrónico de las cuentas de servicio de nodos
La dirección de correo electrónico de tu cuenta de servicio de nodo depende del tipo de cuenta de servicio, como se indica a continuación:
Cuenta de servicio predeterminada de Compute Engine:
CLUSTER_PROJECT_NUMBER-compute@developer.gserviceaccount.comReemplaza
CLUSTER_PROJECT_NUMBERpor el número de proyecto que contiene tu clúster, como1234567890.Cuenta de servicio personalizada:
SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.comReemplaza lo siguiente:
SERVICE_ACCOUNT_NAME: el nombre de la cuenta de servicioSERVICE_ACCOUNT_PROJECT_ID: Es el ID del proyecto Google Cloud que contiene la cuenta de servicio.
Cuentas de servicio de nodos y agentes de servicio de proyectos
Cuando creas un clúster o un grupo de nodos, los agentes de servicio en el proyecto del clúster usan la cuenta de servicio conectada a los nodos para realizar tareas como la extracción de imágenes. De forma predeterminada, los agentes de servicio del proyecto del clúster tienen el siguiente acceso a las cuentas de servicio de nodos en ese proyecto:
- El agente de servicio de Compute Engine en un proyecto puede crear tokens de acceso para las cuentas de servicio de nodos en el mismo proyecto.
- El agente de servicio de GKE en un proyecto puede suplantar cuentas de servicio de nodos en el mismo proyecto.
Algunas organizaciones usan un proyecto dedicado para administrar todas las cuentas de servicio. Si la cuenta de servicio del nodo no está en el proyecto del clúster, los agentes de servicio en el proyecto del clúster no pueden crear tokens ni suplantar la identidad de esa cuenta de servicio. Debes otorgar a los agentes de servicio en tu proyecto de clúster los siguientes roles en la cuenta de servicio:
- Creador de tokens de cuenta de servicio (
roles/iam.serviceAccountTokenCreator) en la cuenta de servicio para el agente de servicio de Compute Engine en tu proyecto de clúster - Usuario de la cuenta de servicio (
roles/iam.serviceAccountUser) en la cuenta de servicio del agente de servicio de GKE en el proyecto del clúster
Para obtener más información, consulta Configura el uso de cuentas de servicio en varios proyectos.
Cuándo usar una cuenta de servicio específica
El tipo de cuenta de servicio que uses dependerá del tipo de identidad que desees proporcionar para tus aplicaciones, de la siguiente manera:
- Proporciona una identidad para que tus Pods la usen en el clúster: Usa una ServiceAccount de Kubernetes. Cada espacio de nombres de Kubernetes tiene una ServiceAccount
default, pero te recomendamos que crees ServiceAccounts nuevas con privilegios mínimos para cada carga de trabajo en cada espacio de nombres. - Proporciona una identidad para que tus Pods se usen fuera del clúster: Usa la federación de identidades para cargas de trabajo para GKE. La federación de identidades para cargas de trabajo para GKE te permite especificar recursos de Kubernetes, como ServiceAccounts, como principales en las políticas de IAM. Por ejemplo, usa la federación de identidades para cargas de trabajo para GKE cuando llames a las APIs de Google Cloud , como Secret Manager o Spanner, desde tus Pods.
- Proporciona una identidad predeterminada para tus nodos: Usa una cuenta de servicio de IAM personalizada con privilegios mínimos cuando crees tus clústeres o nodos de GKE. Si no usas una cuenta de servicio de IAM personalizada, GKE usa la cuenta de servicio predeterminada de Compute Engine.
¿Qué sigue?
- Obtén más información sobre cómo usar cuentas de servicio de Google con privilegios mínimos.
- Obtén más información para otorgar una función a una principal.