En esta página, se muestra cómo resolver problemas relacionados con las configuraciones de seguridad en los clústeres de Google Kubernetes Engine (GKE) Autopilot y Standard.
Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.IAM y RBAC
Las cuentas autenticadas de IAM no pueden realizar acciones en el clúster
El siguiente problema ocurre cuando intentas realizar una acción en el clúster, pero GKE no puede encontrar una política de RBAC que autorice la acción. GKE intenta encontrar una política de permisos de IAM que otorgue el mismo permiso. Si eso falla, verás un mensaje de error similar al siguiente:
Error from server (Forbidden): roles.rbac.authorization.k8s.io is forbidden:
User "example-account@example-project.iam.gserviceaccount.com" cannot list resource "roles" in
API group "rbac.authorization.k8s.io" in the namespace "kube-system": requires
one of ["container.roles.list"] permission(s).
Para resolver este problema, usa una política de RBAC para otorgar los permisos de la acción que se intentó. Por ejemplo, para resolver el problema en la muestra anterior, otorga un rol que tenga el permiso list
en los objetos roles
del espacio de nombres kube-system
. Para obtener instrucciones, consulta Autoriza acciones en clústeres mediante el control de acceso basado en roles.
Federación de identidades para cargas de trabajo para GKE
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:
Verifica que hayas habilitado la API de Service Account Credentials de IAM en el proyecto que contiene el clúster de GKE.
Confirma que la federación de identidades para cargas de trabajo para GKE esté habilitada en el clúster mediante la verificación de que tiene un grupo de identidades para cargas de trabajo configurado:
gcloud container clusters describe CLUSTER_NAME \ --format="value(workloadIdentityConfig.workloadPool)"
Reemplaza
CLUSTER_NAME
por el nombre de tu clúster de GKE.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)"
Reemplaza lo siguiente:
NODEPOOL_NAME
por el nombre de tu grupo de nodos.CLUSTER_NAME
por el nombre de tu clúster de GKE.
Verifica que la cuenta de servicio de Kubernetes esté anotada de forma correcta:
kubectl describe serviceaccount \ --namespace NAMESPACE KSA_NAME
Reemplaza lo siguiente:
NAMESPACE
por el espacio de nombres del clúster de GKE.KSA
por el nombre de tu cuenta de servicio de Kubernetes.
El resultado esperado contiene una anotación similar a la siguiente:
iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
Verifica 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 esperado 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, debes permitir 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. Para los clústeres que ejecutan GKE Dataplane V2, debes permitir la salida a169.254.169.254/32
en el puerto80
.kubectl describe networkpolicy NETWORK_POLICY_NAME
Reemplaza
NETWORK_POLICY_NAME
por el nombre de tu política de red de GKE.
Problemas con la resolución de DNS
Algunas bibliotecas cliente de Google Cloud están configuradas para conectarse a los servidores de metadatos de GKE y Compute Engine mediante la resolución del nombre de DNS metadata.google.internal
; para estas bibliotecas, la resolución de DNS en buen estado en el clúster es una dependencia crítica para tus cargas de trabajo se autentiquen en los servicios de Google Cloud.
La detección de este problema depende de los detalles de la aplicación implementada, incluida su configuración de registro. Busca los siguientes mensajes de error:
- te indica que configures GOOGLE_APPLICATION_CREDENTIALS, o bien
- te indica que tus solicitudes a un servicio de Google Cloud se rechazaron porque la solicitud no tenía credenciales.
Si tienes problemas con la resolución de DNS de metadata.google.internal
, se puede indicar a algunas bibliotecas cliente de Google Cloud que omitan la resolución de DNS mediante la configuración de la variable de entorno GCE_METADATA_HOST
como 169.254.169.254
:
apiVersion: v1
kind: Pod
metadata:
name: example-pod
namespace: default
spec:
containers:
- image: debian
name: main
command: ["sleep", "infinity"]
env:
- name: GCE_METADATA_HOST
value: "169.254.169.254"
Esta es la dirección IP codificada en la que el servicio de metadatos siempre está disponible en las plataformas de procesamiento de Google Cloud.
Bibliotecas de Google Cloud compatibles:
- Python
- Java
- Node.js
- Golang (Sin embargo, ten en cuenta que la biblioteca cliente de Golang ya prefiere conectarse por IP en lugar de nombre de DNS).
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. Los intentos de autenticarse con la federación de identidades para cargas de trabajo para GKE en los primeros segundos de la vida del Pod podrían fallar para aplicaciones y bibliotecas cliente de Google Cloud configuradas con un tiempo de espera breve.
Si encuentras errores de tiempo de espera, intenta lo siguiente:
- Actualiza las bibliotecas cliente de Google Cloud que usan tus cargas de trabajo.
- Cambia el código de la aplicación para que espere unos segundos y vuelve a intentarlo.
Implementa 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:alpine name: workload-identity-initcontainer command: - '/bin/bash' - '-c' - | curl -sS -H 'Metadata-Flavor: Google' 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 60 --connect-timeout 3 --fail --retry-all-errors > /dev/null && exit 0 || echo 'Retry limit exceeded. Failed to wait for metadata server to be available. Check if the gke-metadata-server Pod in the kube-system namespace is healthy.' >&2; exit 1 containers: - image: gcr.io/your-project/your-image name: your-main-application-container
La federación de identidades para cargas de trabajo para GKE falla debido a la falta de disponibilidad del plano de control
El servidor de metadatos no puede mostrar la federación de identidades para cargas de trabajo para GKE cuando el plano de control del clúster no está disponible. Las llamadas al servidor de metadatos muestran el código de estado 500.
Una entrada de registro puede ser similar a la siguiente en el Explorador de registros:
dial tcp 35.232.136.58:443: connect: connection refused
Este comportamiento genera una falta de disponibilidad de la federación de identidades para cargas de trabajo para GKE.
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 IPs, la actualización de las VMs 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 a un clúster regional elimina este problema.
La federación de identidades para cargas de trabajo para la autenticación de GKE falla en los clústeres con Istio
Si el servidor de metadatos de GKE se bloquea por algún motivo, la federación de identidades para cargas de trabajo para la autenticación de GKE falla.
Si usas Istio o Cloud Service Mesh, agrega la siguiente anotación a nivel de Pod a todas las cargas de trabajo que usan la federación de identidades para cargas de trabajo para GKE para excluir la IP del redireccionamiento:
traffic.sidecar.istio.io/excludeOutboundIPRanges: 169.254.169.254/32
Puedes cambiar la clave global.proxy.excludeIPRanges
de ConfigMap de Istio para hacer lo mismo.
Como alternativa, también puedes agregar la siguiente anotación a nivel de Pod a todas las cargas de trabajo que usan la federación de identidades para cargas de trabajo para GKE para retrasar el inicio del contenedor de la aplicación hasta que el sidecar esté listo:
proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
Puedes cambiar la clave global.proxy.holdApplicationUntilProxyStarts
de ConfigMap de Istio para hacer lo mismo.
El pod gke-metadata-server
falla
El Pod DaemonSet del sistema gke-metadata-server
facilita la federación de identidades para cargas de trabajo para GKE en tus nodos. El pod usa recursos de memoria proporcionales a la cantidad de cuentas de servicio de Kubernetes en tu clúster.
El siguiente problema se produce cuando el uso de recursos del pod gke-metadata-server
excede sus límites. kubelet expulsa el pod con un error de memoria insuficiente.
Es posible que tengas este problema si el clúster tiene más de 3,000 cuentas de servicio
de Kubernetes.
Para identificar el problema, haz lo siguiente:
Busca Pods de
gke-metadata-server
con fallas en el espacio de nombreskube-system
:kubectl get pods -n=kube-system | grep CrashLoopBackOff
El resultado es similar a este:
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system gke-metadata-server-8sm2l 0/1 CrashLoopBackOff 194 16h kube-system gke-metadata-server-hfs6l 0/1 CrashLoopBackOff 1369 111d kube-system gke-metadata-server-hvtzn 0/1 CrashLoopBackOff 669 111d kube-system gke-metadata-server-swhbb 0/1 CrashLoopBackOff 30 136m kube-system gke-metadata-server-x4bl4 0/1 CrashLoopBackOff 7 15m
Describe el Pod que falla para confirmar que la causa fue una expulsión de memoria insuficiente:
kubectl describe pod POD_NAME --namespace=kube-system | grep OOMKilled
Reemplaza
POD_NAME
con el nombre del Pod que deseas verificar.
Para restablecer la funcionalidad en el servidor de metadatos de GKE, reduce la cantidad de cuentas de servicio en el clúster a menos de 3,000.
La federación de identidades para cargas de trabajo para GKE no se pudo habilitar con el mensaje de error de DeployPatch con errores
GKE usa el agente de servicio de Kubernetes Engine administrado por Google Cloud a fin de facilitar la federación de identidades para cargas de trabajo para GKE en tus clústeres. Google Cloud otorga de forma automática a este agente de servicio el rol de agente de servicio de Kubernetes Engine (roles/container.serviceAgent
) en tu proyecto cuando habilitas la API de Google Kubernetes Engine.
Si intentas habilitar la federación de identidades para cargas de trabajo para GKE en clústeres en un proyecto en el que el agente de servicio no tiene el rol de agente de servicio de Kubernetes Engine, la operación falla con un mensaje de error similar al siguiente:
Error waiting for updating GKE cluster workload identity config: DeployPatch failed
Para resolver este problema, realiza las siguientes acciones:
Comprueba si el agente de servicio existe en el proyecto y está configurado de forma correcta:
gcloud projects get-iam-policy PROJECT_ID \ --flatten=bindings \ --filter=bindings.role=roles/container.serviceAgent \ --format="value[delimiter='\\n'](bindings.members)"
Reemplaza
PROJECT_ID
por el ID del proyecto de Google Cloud.Si el agente de servicio está configurado de forma correcta, el resultado muestra la identidad completa del agente de servicio:
serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
Si el resultado no muestra el agente de servicio, debes otorgarle la función de agente de servicio de Kubernetes Engine. Para otorgar este rol, completa los siguientes pasos.
Obtén tu número de proyecto de Google Cloud:
gcloud projects describe PROJECT_ID \ --format="value(projectNumber)"
El resultado es similar a este:
123456789012
Otorga el rol al agente de servicio:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \ --role=roles/container.serviceAgent \ --condition=None
Reemplaza
PROJECT_NUMBER
por el número de proyecto de Google Cloud.Vuelve a habilitar la federación de identidades para cargas de trabajo para GKE.