En este documento, se muestra cómo habilitar y configurar Workload Identity en los clústeres de Google Kubernetes Engine (GKE). Workload Identity permite que las cargas de trabajo de los clústeres de GKE actúen en nombre de las cuentas de servicio de la administración de identidades y accesos (IAM) para acceder a los servicios de Google Cloud. Workload Identity está habilitada de forma predeterminada en los clústeres de Autopilot.
Para obtener más información sobre cómo funciona Workload Identity, consulta Workload Identity.
Limitaciones
GKE crea un grupo de identidades de carga de trabajo fijo para cada proyecto de Google Cloud, con el formato
PROJECT_ID.svc.id.goog
.Workload Identity reemplaza la necesidad de usar ocultamiento de metadatos. Workload Identity también protege los metadatos sensibles protegidos con la ocultación de metadatos.
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.
No se puede usar Workload Identity en los Pods que se ejecutan en la red del host. Las solicitudes realizadas desde estos pods a los extremos de metadatos se enrutan al servidor de metadatos de Compute Engine.
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 Workload Identity en los primeros segundos de la vida del Pod podrían fallar. Volver a intentar la llamada resolverá el problema. Si quieres obtener más información, revisa la sección de solución de problemas que se encuentra más abajo.
Los agentes integrados de supervisión y registro de GKE seguirán usando la cuenta de servicio del nodo.
Workload Identity requiere una configuración manual para Cloud Run for Anthos a fin de continuar lanzando métricas de solicitudes.
Workload Identity instala
ip-masq-agent
si el clúster se crea sin la marca--disable-default-snat
.Workload Identity 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.
Workload Identity para los 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.
Antes de comenzar
Antes de comenzar, asegúrate de haber realizado las siguientes tareas:
- Asegúrate de que habilitaste la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Asegúrate de que instalaste Google Cloud CLI.
- Establece la configuración predeterminada de Google Cloud CLI para tu proyecto mediante uno de los siguientes métodos:
- Usa
gcloud init
si deseas ver una explicación sobre cómo configurar los valores predeterminados del proyecto. - Usa
gcloud config
para configurar el ID, la zona y la región del proyecto de manera individual. -
Ejecuta
gcloud init
y sigue las instrucciones:gcloud init
Si usas SSH en un servidor remoto, usa la marca
--console-only
para evitar que el comando abra un navegador:gcloud init --console-only
- Sigue las instrucciones para autorizar a la CLI de gcloud a usar tu cuenta de Google Cloud.
- Crea una configuración nueva o selecciona una existente.
- Elige un proyecto de Google Cloud.
- Elige una zona de Compute Engine predeterminada.
- Elige una región de Compute Engine predeterminada.
- Establece tu ID del proyecto predeterminado:
gcloud config set project PROJECT_ID
- Configura la región de Compute Engine predeterminada (por ejemplo,
us-central1
):gcloud config set compute/region COMPUTE_REGION
- Configura la zona de Compute Engine predeterminada (por ejemplo,
us-central1-c
):gcloud config set compute/zone COMPUTE_ZONE
- Actualiza
gcloud
a la versión más reciente:gcloud components update
gcloud init
gcloud config
Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la CLI de gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location
.
Asegúrate de que habilitaste la API de credenciales de la cuenta de servicio de IAM.
Asegúrate de tener las siguientes funciones de IAM:
roles/container.admin
roles/iam.serviceAccountAdmin
Habilitar Workload Identity
Puedes habilitar Workload Identity en clústeres y grupos de nodos mediante la CLI de Google Cloud o Google Cloud Console.
Workload Identity debe habilitarse a nivel de clúster antes de poder habilitar Workload Identity en grupos de nodos.
Crea un clúster nuevo
Puedes habilitar Workload Identity en un clúster estándar nuevo con la CLI de gcloud o Cloud Console.
gcloud
Para habilitar Workload Identity en un clúster nuevo, ejecuta el siguiente comando:
gcloud container clusters create CLUSTER_NAME \
--region=COMPUTE_REGION \
--workload-pool=PROJECT_ID.svc.id.goog
Reemplaza lo siguiente:
CLUSTER_NAME
: Es el nombre del clúster nuevo.COMPUTE_REGION
: La región de Compute Engine del clúster. Para los clústeres zonales, usa--zone=COMPUTE_ZONE
.PROJECT_ID
: Es el ID de tu proyecto de Google Cloud.
Console
Para habilitar Workload Identity en un clúster nuevo, haz lo siguiente:
Ve a la página Google Kubernetes Engine en Cloud Console.
Haz clic en add_box Crear.
En el diálogo Crear clúster, para GKE Standard, haz clic en Configurar.
En el menú de navegación, en la sección Clúster, haz clic en Seguridad.
Selecciona la casilla de verificación Habilitar Workload Identity.
Continúa con la configuración del clúster y, luego, haz clic en Crear.
Actualiza un clúster existente
Puedes habilitar Workload Identity en un clúster estándar existente con la CLI de gcloud o Cloud Console. Los grupos de nodos existentes no se verán afectados, pero todos los grupos de nodos nuevos en el clúster usarán Workload Identity.
gcloud
Para habilitar Workload Identity en un clúster existente, ejecuta el siguiente comando:
gcloud container clusters update CLUSTER_NAME \
--region=COMPUTE_REGION \
--workload-pool=PROJECT_ID.svc.id.goog
Reemplaza lo siguiente:
CLUSTER_NAME
: Es el nombre del clúster existente.COMPUTE_REGION
: La región de Compute Engine del clúster. Para los clústeres zonales, usa--zone=COMPUTE_ZONE
.PROJECT_ID
: Es el ID de tu proyecto de Google Cloud.
Console
Para habilitar Workload Identity en un clúster existente, haz lo siguiente:
Ve a la página de Google Kubernetes Engine en Cloud Console:
En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.
En la página de detalles del clúster, en la sección Seguridad, haz clic en
Editar Workload Identity.En el cuadro de diálogo Editar Workload Identity, selecciona la casilla de verificación Habilitar Workload Identity.
Haz clic en Guardar cambios.
Migra las cargas de trabajo existentes a Workload Identity
Después de habilitar Workload Identity en un clúster existente, es posible que desees migrar las cargas de trabajo en ejecución para usar Workload Identity. Selecciona la estrategia de migración ideal para tu entorno. Puedes crear grupos de nodos nuevos con Workload Identity habilitado o actualizar los grupos de nodos existentes para habilitar Workload Identity.
Te recomendamos crear grupos de nodos nuevos si también necesitas modificar tus aplicaciones para que sean compatibles con Workload Identity.
Crea un grupo de nodos nuevo
Todos los grupos de nodos nuevos que crees de forma predeterminada usarán Workload Identity si el clúster lo tiene habilitado. Para crear un grupo de nodos nuevo con Workload Identity habilitado, ejecuta el siguiente comando:
gcloud container node-pools create NODEPOOL_NAME \
--cluster=CLUSTER_NAME \
--workload-metadata=GKE_METADATA
Reemplaza lo siguiente:
NODEPOOL_NAME
: el nombre del grupo de nodos nuevoCLUSTER_NAME
: El nombre del clúster existente que tiene habilitado Workload Identity.
La marca --workload-metadata=GKE_METADATA
configura el grupo de nodos para usar el servidor de metadatos de GKE. Te recomendamos que incluyas la marca para que la creación del grupo de nodos falle si Workload Identity no está habilitada en el clúster.
Actualiza un grupo de nodos existente
Puedes habilitar Workload Identity de forma manual en los grupos de nodos existentes después de habilitarlo en el clúster.
gcloud
A fin de modificar un grupo de nodos existente para usar Workload Identity, ejecuta el siguiente comando:
gcloud container node-pools update NODEPOOL_NAME \
--cluster=CLUSTER_NAME \
--workload-metadata=GKE_METADATA
Si un clúster tiene Workload Identity habilitada, puedes inhabilitarla de forma selectiva en un grupo de nodos en particular si especificas --workload-metadata=GCE_METADATA
explícitamente. Para obtener más información, consulta Protege metadatos del clúster.
Console
A fin de modificar un grupo de nodos existente para usar Workload Identity, sigue estos pasos:
Ve a la página de Google Kubernetes Engine en Cloud Console:
En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.
Haz clic en la pestaña Nodos.
En la sección Grupos de nodos, haz clic en el nombre del grupo de nodos al que quieres modificar.
En la página Detalles del grupo de nodos, haz clic en
Editar.En la página Editar grupo de nodos, en la sección Seguridad, selecciona la casilla de verificación Habilitar servidor de metadatos de GKE.
Haz clic en Guardar.
Configura aplicaciones para usar Workload Identity
Después de habilitar Workload Identity, debes configurar las aplicaciones para que se autentiquen en Google Cloud mediante Workload Identity antes de migrarlas a los grupos de nodos nuevos.
Debes asignar una cuenta de servicio de Kubernetes a la aplicación y configurarla para que actúe como una cuenta de servicio de IAM.
En los siguientes pasos, se muestra cómo configurar las aplicaciones para que usen Workload Identity si está habilitado en el clúster.
Obtén credenciales para el clúster:
gcloud container clusters get-credentials CLUSTER_NAME
Reemplaza
CLUSTER_NAME
por el nombre del clúster que tiene habilitada Workload Identity.Crea un espacio de nombres para usar en la cuenta de servicio de Kubernetes. También puedes usar el espacio de nombres predeterminado o cualquier espacio de nombres existente.
kubectl create namespace NAMESPACE
Crea una cuenta de servicio de Kubernetes para que tu aplicación use: También puedes usar la cuenta de servicio de Kubernetes predeterminada en el espacio de nombres predeterminado o cualquiera existente.
kubectl create serviceaccount KSA_NAME \ --namespace NAMESPACE
Reemplaza lo siguiente:
KSA_NAME
: Es el nombre de tu cuenta de servicio de Kubernetes nueva.NAMESPACE
es el nombre del espacio de nombres de Kubernetes para la cuenta de servicio.
Crea una cuenta de servicio de IAM para tu aplicación o usa una cuenta de servicio de IAM existente en su lugar. Puedes usar cualquier cuenta de servicio de IAM en cualquier proyecto de tu organización. En Config Connector, aplica el objeto
IAMServiceAccount
para la cuenta de servicio elegida.gcloud
Para crear una nueva cuenta de servicio de IAM con la CLI de gcloud, ejecuta el siguiente comando.
gcloud iam service-accounts create GSA_NAME \ --project=GSA_PROJECT
Reemplaza lo siguiente:
GSA_NAME
: El nombre de la cuenta de servicio de IAM nueva.GSA_PROJECT
: El ID del proyecto de Google Cloud para tu cuenta de servicio de IAM.
Config Connector
Para usar una cuenta de servicio de IAM nueva o existente con Config Connector, aplica el siguiente archivo de configuración.
Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.
Para implementar este manifiesto, descárgalo en tu equipo comoservice-account.yaml
.Usa
kubectl
para aplicar el manifiesto:kubectl apply -f service-account.yaml
Para obtener información sobre la autorización de cuentas de servicio de IAM a fin de acceder a las API de Google Cloud, consulta la página Comprende las cuentas de servicio.
Asegúrate de que tu cuenta de servicio de IAM tenga las funciones que necesitas. Puedes otorgar funciones adicionales con el siguiente comando:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \ --role "ROLE_NAME"
Reemplaza lo siguiente:
PROJECT_ID
: Es el ID de tu proyecto de Google Cloud.GSA_NAME
: El nombre de tu cuenta de servicio de IAM.GSA_PROJECT
: El ID del proyecto de Google Cloud de la cuenta de servicio de IAM.ROLE_NAME
: es la función de IAM que se asignará a la cuenta de servicio, comoroles/spanner.viewer
.
Para permitir que la cuenta de servicio de Kubernetes actúe en nombre de la cuenta de servicio de IAM, agrega una vinculación de política de IAM entre las dos. Esta vinculación permite que la cuenta de servicio de Kubernetes actúe como la cuenta de servicio de IAM.
gcloud
gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
Config Connector
Nota: En este paso, se necesita Config Connector. Sigue las instrucciones de instalación para instalar Config Connector en el clúster.
Para implementar este manifiesto, descárgalo en tu equipo comopolicy-binding.yaml
. ReemplazaGSA_NAME
,PROJECT_ID
,NAMESPACE
yKSA_NAME
por los valores para tu entorno. Luego, ejecuta lo siguiente:kubectl apply -f policy-binding.yaml
Anota la cuenta de servicio de Kubernetes con la dirección de correo electrónico de la cuenta de servicio de IAM.
kubectl
kubectl annotate serviceaccount KSA_NAME \ --namespace NAMESPACE \ iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com
yaml
apiVersion: v1 kind: ServiceAccount metadata: annotations: iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com name: KSA_NAME namespace: NAMESPACE
Actualiza las especificaciones de tu Pod para programar las cargas de trabajo en los nodos que usan Workload Identity y usar la cuenta de servicio de Kubernetes anotada.
spec: serviceAccountName: KSA_NAME nodeSelector: iam.gke.io/gke-metadata-server-enabled: "true"
Aplica la configuración actualizada al clúster:
kubectl apply -f DEPLOYMENT_FILE
Reemplaza
DEPLOYMENT_FILE
por la ruta a la especificación del pod actualizado.
Verifica la configuración de Workload Identity
Para verificar que las cuentas de servicio estén configuradas de forma correcta, crea un Pod con la cuenta de servicio de Kubernetes que ejecute la imagen de contenedor específica del SO y, a continuación, conéctate a ella con una sesión interactiva.
Linux
Crea un pod que use la cuenta de servicio de Kubernetes anotada y aplica curl
al extremo service-accounts
.
Guarda la siguiente configuración como
wi-test.yaml
.apiVersion: v1 kind: Pod metadata: name: workload-identity-test namespace: NAMESPACE spec: containers: - image: google/cloud-sdk:slim name: workload-identity-test command: ["sleep","infinity"] serviceAccountName: KSA_NAME nodeSelector: iam.gke.io/gke-metadata-server-enabled: "true"
La imagen
google/cloud-sdk
incluye la CLI de Google Cloud, que es una forma conveniente de usar las API de Google Cloud. La descarga de la imagen puede tomar un tiempo.Crea el Pod:
kubectl apply -f wi-test.yaml
Abre una sesión interactiva en el Pod:
kubectl exec -it workload-identity-test \ --namespace NAMESPACE \ -- /bin/bash
Ejecuta el siguiente comando dentro del Pod:
curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/
Si las cuentas de servicio están configuradas de forma correcta, la dirección de correo electrónico de la cuenta de servicio de IAM aparece como la identidad activa (y única). Esto demuestra que, de forma predeterminada, el pod actúa como la autoridad de la cuenta de servicio de IAM cuando se llama a las API de Google Cloud.
Windows
Crea un Pod con la cuenta de servicio de Kubernetes que ejecuta la imagen de contenedor servercore
.
Guarda el siguiente manifiesto:
apiVersion: v1 kind: Pod metadata: name: workload-identity-test namespace: NAMESPACE spec: containers: - image: IMAGE_NAME name: workload-identity-test command: ["powershell.exe", "sleep", "3600"] serviceAccountName: KSA_NAME nodeSelector: kubernetes.io/os: windows cloud.google.com/gke-os-distribution: windows_ltsc iam.gke.io/gke-metadata-server-enabled: "true"
Reemplaza
IMAGE_NAME
por uno de los siguientes valores de imagen de contenedor servercore:Imagen de nodo de Windows Server Imagen de contenedor servercore
WINDOWS_LTSC
,WINDOWS_LTSC_CONTAINERD
mcr.microsoft.com/windows/servercore:ltsc2019
WINDOWS_SAC
,WINDOWS_SAC_CONTAINERD
Verifica la asignación de versiones entre la versión de nodo de GKE y la versión de Windows SAC. En la versión 1909 de Windows Server, especifica mcr.microsoft.com/windows/servercore:1909
. De lo contrario, especificamcr.microsoft.com/windows/servercore:20H2
.Abre una sesión interactiva en el Pod:
kubectl exec -it workload-identity-test \ --namespace NAMESPACE -- powershell
Ejecuta el siguiente comando dentro del Pod:
Invoke-WebRequest -Headers @{"Metadata-Flavor"="Google"} -Uri http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email -UseBasicParsing
Si las cuentas de servicio están configuradas de forma correcta, la dirección de correo electrónico de la cuenta de servicio de IAM aparece como la identidad activa (y única). Esto demuestra que, de forma predeterminada, el Pod usa la autoridad de la cuenta de servicio de IAM cuando llama a las API de Google Cloud.
Usa Workload Identity desde el código
La autenticación en los servicios de Google Cloud desde tu código es el mismo proceso que la autenticación mediante el servidor de metadatos de Compute Engine. Cuando usas Workload Identity, las solicitudes al servidor de metadatos de la instancia se enrutan al servidor de metadatos de GKE. El código existente que se autentica mediante el servidor de metadatos de la instancia (como el código que usa las bibliotecas cliente de Google Cloud) debería funcionar sin modificaciones.
Limpia
Para dejar de usar Workload Identity, revoca el acceso a la cuenta de servicio de IAM y, luego, inhabilita Workload Identity en el clúster.
Revocar acceso
Revoca el acceso a la cuenta de servicio de IAM:
gcloud
gcloud iam service-accounts remove-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
Reemplaza lo siguiente:
PROJECT_ID
: Es el ID del proyecto del clúster de GKE.NAMESPACE
: El nombre del espacio de nombres de Kubernetes en el que se encuentra la cuenta de servicio de Kubernetes.KSA_NAME
: El nombre de la cuenta de servicio de Kubernetes a la que se le revocará el acceso.GSA_NAME
: Es el nombre de la cuenta de servicio de IAM.GSA_PROJECT
: Es el ID del proyecto de la cuenta de servicio de IAM.
Config Connector
Si usaste Config Connector para crear la cuenta de servicio, borra la cuenta de servicio con
kubectl
.kubectl delete -f service-account.yaml
Los tokens almacenados en caché pueden tardar hasta 30 minutos en caducar. Puedes verificar si los tokens almacenados en caché caducaron con este comando:
gcloud auth list
Los tokens almacenados en caché caducaron si la salida de ese comando ya no incluye
GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com
.Quita la anotación de la cuenta de servicio de Kubernetes. Este paso es opcional porque IAM revocó el acceso.
kubectl annotate serviceaccount KSA_NAME \ --namespace NAMESPACE iam.gke.io/gcp-service-account-
Inhabilita Workload Identity
Solo puedes inhabilitar Workload Identity en los clústeres estándar de GKE.
gcloud
Inhabilita Workload Identity en cada grupo de nodos:
gcloud container node-pools update NODEPOOL_NAME \ --cluster=CLUSTER_NAME \ --workload-metadata=GCE_METADATA
Repite este comando para cada grupo de nodos del clúster.
Inhabilita Workload Identity en el clúster:
gcloud container clusters update CLUSTER_NAME \ --disable-workload-identity
Console
Ve a la página de Google Kubernetes Engine en la consola de Cloud.
En la lista de clústeres, haz clic en el nombre del clúster que deseas modificar.
Haz clic en la pestaña Nodos.
A fin de inhabilitar Workload Identity en cada grupo de nodos, haz lo siguiente para cada grupo de nodos en la sección Grupos de nodos:
- Haz clic en el nombre del grupo de nodos que deseas modificar.
- En la página Detalles del grupo de nodos, haz clic en Editar.
- En la página Editar grupo de nodos, en la sección Seguridad, desmarca la selección de la casilla de verificación Habilitar servidor de metadatos de GKE.
- Haz clic en Guardar.
Si deseas inhabilitar Workload Identity para el clúster, haz lo siguiente:
- Haz clic en la pestaña Detalles.
- En la sección Seguridad, junto a Workload Identity, haz clic en Editar.
- En el cuadro de diálogo Editar Workload Identity, desmarca la casilla de verificación Habilitar Workload Identity.
- Haz clic en Guardar cambios.
Inhabilita Workload Identity en la organización
Desde la perspectiva de seguridad, Workload Identity permite que GKE confirme las identidades de las cuentas de servicio de Kubernetes que se pueden autenticar y autorizar en los recursos de Google Cloud. Si eres administrador y realizaste acciones para aislar las cargas de trabajo de los recursos de Google Cloud, como inhabilitar la creación de cuentas de servicio o inhabilitar la creación de claves de cuentas de servicio, también puedes inhabilitar Workload Identity en la organización.
Consulta estas instrucciones para inhabilitar Workload Identity en la organización.
Soluciona problemas
El Pod no se puede autenticar en Google Cloud
Si la aplicación no puede autenticarse en Google Cloud, asegúrate de que las siguientes opciones estén configuradas de forma correcta:
Asegúrate de tener habilitada la API de credenciales de la cuenta de servicio de IAM en el proyecto que contiene el clúster de GKE.
Asegúrate de que Workload Identity esté habilitado en el clúster mediante la verificación de que tiene un grupo de identidades de cargas de trabajo configurado:
gcloud container clusters describe CLUSTER_NAME \ --format="value(workloadIdentityConfig.workloadPool)"
Si aún no especificaste una zona o región predeterminada para
gcloud
, es posible que también debas especificar una marca--region
o--zone
cuando ejecutes este comando.Asegúrate de que el servidor de metadatos de GKE esté configurado en el grupo de nodos en el que se ejecuta la aplicación:
gcloud container node-pools describe NODEPOOL_NAME \ --cluster=CLUSTER_NAME \ --format="value(config.workloadMetadataConfig.mode)"
Asegúrate de que la cuenta de servicio de Kubernetes esté anotada de forma correcta:
kubectl describe serviceaccount \ --namespace NAMESPACE KSA_NAME
El resultado contiene una anotación similar a la siguiente:
iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
Asegúrate de que la cuenta de servicio de IAM esté configurada de forma correcta
gcloud iam service-accounts get-iam-policy \ GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com
El resultado contiene una vinculación similar a la siguiente:
- members: - serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME] role: roles/iam.workloadIdentityUser
Si tienes una política de red del clúster, asegúrate de que permitiste la salida a
127.0.0.1/32
en el puerto988
para los clústeres que ejecutan versiones de GKE anteriores a 1.21.0-gke.1000, o a169.254.169.252/32
en el puerto988
para clústeres que ejecutan la versión 1.21.0-gke.1000 de GKE y versiones posteriores.kubectl describe networkpolicy NETWORK_POLICY_NAME
Errores de tiempo de espera en el inicio del Pod
El servidor de metadatos de GKE necesita unos segundos antes de poder comenzar a aceptar solicitudes en un pod nuevo. Por lo tanto, los intentos de autenticarse con Workload Identity en los primeros segundos de la vida del Pod pueden fallar para aplicaciones y bibliotecas cliente de Google Cloud configuradas con un tiempo de espera breve.
Si encuentras errores de tiempo de espera, puedes cambiar el código de la aplicación para esperar unos segundos y volver a intentarlo. Como alternativa, puedes implementar un initContainer que espere hasta que el servidor de metadatos de GKE esté listo antes de ejecutar el contenedor principal del Pod.
Por ejemplo, el siguiente manifiesto es para un pod con un initContainer
:
apiVersion: v1
kind: Pod
metadata:
name: pod-with-initcontainer
spec:
serviceAccountName: KSA_NAME
initContainers:
- image: gcr.io/google.com/cloudsdktool/cloud-sdk:326.0.0-alpine
name: workload-identity-initcontainer
command:
- '/bin/bash'
- '-c'
- |
curl -s -H 'Metadata-Flavor: Google' 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 30 > /dev/null || exit 1
containers:
- image: gcr.io/your-project/your-image
name: your-main-application-container
Workload Identity falla debido a la falta de disponibilidad del plano de control
El servidor de metadatos no puede mostrar Workload Identity cuando el plano de control del clúster no está disponible. Las llamadas al servidor de metadatos muestran el código de estado 500.
La entrada de registro puede ser similar a la siguiente en el Explorador de registros:
dial tcp 35.232.136.58:443: connect: connection refused
Esto generará una falta de disponibilidad esperada de Workload Identity.
Es posible que el plano de control no esté disponible en clústeres zonales durante el mantenimiento de los clústeres, como la rotación de las IP, la actualización de las VM del plano de control o el cambio de tamaño de clústeres o grupos de nodos. Consulta Elige un plano de control regional o zonal para obtener información sobre la disponibilidad del plano de control. Cambiar al clúster regional elimina este problema.
Workload Identity falla
Si el servidor de metadatos de GKE se bloquea por algún motivo, Workload Identity fallará.
Si usas Istio, debes agregar la siguiente anotación a nivel de la aplicación a todas las cargas de trabajo que usan Workload Identity:
"traffic.sidecar.istio.io/excludeOutboundIPRanges=169.254.169.254/32"
Como alternativa, puedes cambiar la clave global.proxy.excludeIPRanges
de ConfigMap de Istio para hacer lo mismo.
¿Qué sigue?
- Más información sobre Workload Identity
- Lee la descripción general de la seguridad de GKE.
- Consulta Protege metadatos del clúster.
- Obtén información sobre las cuentas de servicio de IAM.