Información sobre las cuentas de servicio en GKE

En esta página se describen las cuentas de servicio de Google Kubernetes Engine (GKE) y cómo proporcionan identidades a las aplicaciones. Descubrirás los distintos tipos de cuentas de servicio y cuándo usar cada tipo para autenticar el acceso a los recursos de GKE sin depender de credenciales personales.

Esta página está dirigida a especialistas en seguridad y operadores que crean y gestionan cuentas de servicio para interactuar con aplicaciones de GKE. 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. Trusted Cloud by S3NS

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 gestión de identidades y accesos:

Tipos de cuentas de servicio en GKE
ServiceAccount de Kubernetes
  • objeto ServiceAccount en el servidor de la API de Kubernetes
  • Limitado a un espacio de nombres de Kubernetes en un clúster
  • Proporciona una identidad para que los pods la usen dentro del clúster.
Cuenta de servicio de gestión de identidades y accesos
  • Gestionar con la API IAM
  • Limitado a un Trusted Cloud proyecto
  • Proporciona una identidad para las aplicaciones del proyecto.

Cuentas de servicio de Kubernetes

Las cuentas de servicio de Kubernetes se gestionan a nivel de clúster y existen en el servidor de la API de Kubernetes como objetos ServiceAccount. En la documentación de Kubernetes y en la de GKE se suele usar el término ServiceAccount para distinguir estos recursos de Kubernetes de las cuentas de servicio de otros entornos, como IAM.

Puedes crear un Kubernetes ServiceAccount en un espacio de nombres y, a continuación, asignarlo a un pod mediante el campo serviceAccountName del manifiesto del pod. El proceso de kubelet del nodo obtiene un token de portador de corta duración para la ServiceAccount asignada y monta el token como un volumen proyectado en el pod. De forma predeterminada, este volumen proyectado tiene un nombre que empieza por el prefijo kube-api-access-. GKE gestiona todos los volúmenes que empiezan por este prefijo, lo que significa que no puedes modificar el tamaño de estos volúmenes. Para monitorizar el uso del disco de forma más precisa, excluya de su configuración de monitorización los volúmenes que empiecen por el prefijo kube-api-access-.

El token de portador de corta duración es un JSON Web Token (JWT) firmado por el servidor de la API, que es un proveedor de OpenID Connect (OIDC). Para validar el token de portador, obtén la clave de validación pública del clúster llamando al método projects.locations.clusters.getJwks de la API de GKE.

Credenciales de cuenta de servicio de Kubernetes vulneradas

Si se vulneran las credenciales de una cuenta de servicio de Kubernetes, utiliza una de las siguientes opciones para revocar las credenciales:

  • Vuelve a crear tus pods: el token de portador está vinculado a cada UID de pod único, por lo que, si vuelves a crear los pods, las credenciales anteriores dejarán de ser válidas.
  • 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. Elimina la cuenta de servicio y crea una con el mismo nombre. Los tokens anteriores dejan de ser válidos porque el UID de la nueva cuenta de servicio es diferente.
  • Realiza una rotación de credenciales: esta operación revoca todas las credenciales de la cuenta de servicio de Kubernetes de tu clúster. La rotación también cambia el certificado de AC y la dirección IP de tu clúster. Para obtener más información, consulta Rotación de credenciales.

Cuentas de servicio de gestión de identidades y accesos

Las cuentas de servicio de IAM se gestionan a nivel de proyecto mediante la API de IAM. Puedes usar estas cuentas de servicio para realizar acciones como llamar a APIs de forma programática y gestionar permisos de aplicaciones que se ejecutan en productos. Trusted CloudTrusted Cloud

Para obtener más información, consulta el resumen de las cuentas de servicio de gestión de identidades y accesos.

Agentes de servicio de GKE

Un agente de servicio de IAM es una cuenta de servicio de IAM que gestiona Trusted Cloud .

GKE usa el agente de servicio de Kubernetes Engine para gestionar el ciclo de vida de los recursos del clúster en tu nombre, como nodos, discos y balanceadores de carga. Este agente de servicio tiene el dominio container-engine-robot.s3ns-system.iam.gserviceaccount.com y se le asigna 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-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com

PROJECT_NUMBER es tu número de proyecto.

Si quitas los permisos del agente de servicio en tu proyecto, puedes recuperarlos siguiendo las instrucciones que se indican en el artículo Error 400 o 403: no tienes permisos de edición en la cuenta.

Cuenta de servicio de nodo de GKE predeterminada

GKE usa cuentas de servicio de gestión de identidades y accesos que están asociadas a tus nodos para ejecutar tareas del sistema, como el registro y la monitorización. Como mínimo, estas cuentas de servicio de nodo deben tener el rol Cuenta de servicio de nodo predeterminada 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 cuenta de servicio del nodo.

Si tu organización aplica la restricción de política de organización iam.automaticIamGrantsForDefaultServiceAccounts, es posible que la cuenta de servicio predeterminada de Compute Engine de tu proyecto no obtenga automáticamente los permisos necesarios para GKE.

Si usas la cuenta de servicio predeterminada de Compute Engine para otras funciones de 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.

Para asignar el rol roles/container.defaultNodeServiceAccount a la cuenta de servicio predeterminada de Compute Engine, sigue estos pasos:

consola

  1. Ve a la página Bienvenida:

    Ir a Bienvenida

  2. En el campo Número de proyecto, haz clic en Copiar en el portapapeles.
  3. Ve a la página Gestión de identidades y accesos:

    Ir a IAM

  4. Haz clic en Conceder acceso.
  5. En el campo Nuevos principales, especifique el siguiente valor: 
    PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com
     Sustituye PROJECT_NUMBER por el número de proyecto que has copiado.
  6. En el menú Seleccionar un rol, elige el rol Cuenta de servicio de nodo predeterminada de Kubernetes Engine.
  7. Haz clic en Guardar.

gcloud

  1. Busca tu Trusted Cloud número de proyecto: 
    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    Sustituye PROJECT_ID por el ID del proyecto.

    El resultado debería ser similar al siguiente:

    12345678901
  2. Asigna el rol roles/container.defaultNodeServiceAccount a la cuenta de servicio predeterminada de Compute Engine: 
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"

    Sustituye PROJECT_NUMBER por el número de proyecto del paso anterior.

No inhabilite la cuenta de servicio predeterminada de Compute Engine a menos que vaya a migrar a cuentas de servicio gestionadas por el usuario.

Cuándo usar una cuenta de servicio específica

El tipo de cuenta de servicio que utilices dependerá del tipo de identidad que quieras proporcionar a tus aplicaciones, tal como se indica a continuación:

  • Proporciona una identidad para que tus pods la usen en el clúster: usa una cuenta de servicio de Kubernetes. Todos los espacios de nombres de Kubernetes tienen una default ServiceAccount, pero te recomendamos que crees nuevas ServiceAccounts con los mínimos privilegios para cada carga de trabajo de cada espacio de nombres.
  • Proporciona una identidad para que tus pods la usen fuera del clúster: usa Workload Identity Federation para GKE. Workload Identity Federation para GKE te permite especificar recursos de Kubernetes, como ServiceAccounts, como principales en las políticas de IAM. Por ejemplo, usa Workload Identity Federation for GKE cuando llames a APIs como Secret Manager o Spanner desde tus pods. Trusted Cloud
  • Proporciona una identidad predeterminada a tus nodos: usa una cuenta de servicio de IAM con el número mínimo de privilegios personalizada al crear 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.

Siguientes pasos