Usar proveedores de identidades externos para autenticarse en GKE

En esta página se explica cómo configurar la autenticación en clústeres de Google Kubernetes Engine (GKE) desde proveedores de identidades (IdPs) externos.

Esta página está dirigida a administradores y operadores de la plataforma, así como a administradores de identidades y cuentas que usen un IdP externo compatible con OpenID Connect (OIDC) o con el lenguaje de marcado para confirmaciones de seguridad (SAML) 2.0.

Antes de leer esta página, asegúrate de que conoces los siguientes conceptos de autenticación y OpenID:

Métodos de autenticación de proveedores de identidades externos en GKE

Recomendado: federación de identidades para los trabajadores

La federación de identidades de Workforce es una función de IAM que te permite autenticarte en Google Cloud desde cualquier IdP externo que admita OIDC o SAML 2.0. La Federación de Identidades de Workforce no requiere ninguna instalación en el clúster, funciona con clústeres Autopilot y Standard, y está integrada en Google Cloud. Para obtener más información, consulta la documentación de gestión de identidades y accesos sobre la Federación de Identidades de Workforce.

No recomendado: Identity Service for GKE

En los clústeres de GKE Standard, GKE también admite Identity Service for GKE. Identity Service para GKE se limita a los proveedores de identidades de OIDC e instala componentes adicionales en tu clúster. GKE recomienda encarecidamente usar Workforce Identity Federation en lugar de Identity Service for GKE. También debes tener en cuenta una limitación conocida de Identity Service for GKE que impide el autoescalado.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Cuestiones importantes

Los sistemas sin interfaz no son compatibles con la federación de identidades de Workforce ni con Identity Service for GKE. Un flujo de autenticación basado en navegador te pide que des tu consentimiento y que autorices tu cuenta de usuario.

Usar la federación de identidades para los trabajadores en GKE

Para usar la federación de identidades de Workforce en tus clústeres de GKE, haz lo siguiente:

  1. Configura la federación de identidades de los trabajadores de tu organización y el proveedor de identidades externo. Para obtener instrucciones, consulta Configurar una federación de trabajadores de Identity.
  2. Configura el acceso desde tu proveedor de identidades externo a la consola de federación de identidades de trabajo. Google Cloud Para obtener más información, consulta Configurar el acceso de los usuarios a la consola (federado).

  3. Configure el acceso de los usuarios mediante uno de los siguientes mecanismos de autorización:

  4. Indica a tus usuarios que accedan a los clústeres siguiendo estos pasos:

    1. Inicia sesión en gcloud CLI con la identidad federada.
    2. Configura kubectl para que se autentique en un clúster específico ejecutando gcloud container clusters get-credentials.

Configurar el acceso de los usuarios a los clústeres mediante RBAC

Google Cloud usa identificadores principales para identificar a los usuarios de tus grupos de identidades de Workforce. Puedes hacer referencia a estos identificadores principales en tus políticas de control de acceso basado en roles (RBAC) de Kubernetes o en políticas de gestión de identidades y accesos. Puedes conceder permisos a usuarios concretos o a grupos de usuarios, como en los siguientes ejemplos:

Identidad Identificador principal
Un solo usuario 
principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE

Haz los cambios siguientes:

  • WORKFORCE_IDENTITY_POOL: el nombre del grupo de identidades de Workforce.
  • SUBJECT_ATTRIBUTE_VALUE: el valor de un atributo en la aserción del asunto del token de identidad. Por ejemplo, puede ser el valor del campo NameID de una aserción SAML 2.0.

Por ejemplo:

principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com
Todos los usuarios de un grupo 
principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/group/GROUP_NAME

Haz los cambios siguientes:

  • WORKFORCE_IDENTITY_POOL: el nombre del grupo de identidades de Workforce.
  • GROUP_NAME: el nombre de un grupo al que pertenece el usuario que se autentica. La aserción del token de tu proveedor de identidades debe tener una asignación de atributos al atributo Google Cloud google.groups.

Por ejemplo:

principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre

Para ver todos los identificadores principales que admite la federación de identidades de Workforce, consulta Representar usuarios del grupo de trabajo en políticas de IAM.

En el siguiente ejemplo se muestra cómo dar acceso de solo lectura a los secretos de todo el clúster a cualquier entidad del grupo de trabajo full-time-employees que forme parte del grupo sre en su token de IdP.

  1. Guarda el siguiente manifiesto de ClusterRole como secret-viewer-cluster-role.yaml:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-viewer
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

    Cualquier principal al que asocies este ClusterRole puede ver los secretos.

  2. Guarda el siguiente manifiesto de ClusterRoleBinding como secret-viewer-cluster-role-binding.yaml:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name:  users-view-secrets
subjects:
- kind: Group
  name: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io

    Este ClusterRoleBinding concede el ClusterRole secret-viewer a cualquier usuario que forme parte del grupo sre.

  3. Despliega ClusterRole y ClusterRoleBinding:

    kubectl apply -f secret-viewer-cluster-role.yaml
kubectl apply -f secret-viewer-cluster-role-binding.yaml

Iniciar sesión y autenticarse en el clúster

  1. Pide al usuario que inicie sesión con la CLI de Google Cloud para Google Cloud.

  2. El usuario puede configurar kubectl para autenticarse en el clúster de las siguientes formas:

    gcloud container clusters get-credentials

Migrar clústeres de Identity Service for GKE a Workforce Identity Federation

Si usas Identity Service for GKE en clústeres de GKE, migra a la federación de identidades de los empleados. Estos métodos usan sintaxis diferentes para hacer referencia a los mismos principales, tal como se muestra en la siguiente tabla:

Sintaxis de Identity Service for GKE Sintaxis de Workforce Identity Federation
amal@example.com principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com
sre-group principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre-group

Para migrar un clúster a Workforce Identity Federation, sigue estos pasos:

  1. Configura la federación de identidades de los trabajadores de tu organización y el proveedor de identidades externo. Para obtener instrucciones, consulta Configurar una federación de trabajadores de Identity.

  2. Actualiza los manifiestos de todos los RoleBindings y ClusterRoleBindings de tus clústeres para que usen la sintaxis del identificador de Workforce Identity Federation. Usa una de las siguientes opciones:

    • Actualizaciones programáticas: instala y ejecuta la utilidad gke-identity-service-migrator. Para obtener instrucciones, consulta el archivo README del repositorio GoogleCloudPlatform/gke-utilities.

      Esta utilidad busca las vinculaciones RBAC que usan la sintaxis de Identity Service for GKE y crea manifiestos que usan los identificadores principales de la federación de identidades de los empleados correspondientes.

    • Actualizaciones manuales: por cada enlace que haga referencia a un usuario o grupo autenticado, cree una copia independiente del archivo de manifiesto del objeto que utilice la sintaxis del identificador de la federación de identidades de la plantilla.

  3. Aplica los manifiestos actualizados de RoleBindings y ClusterRoleBindings a tu clúster.

  4. Comprueba que los usuarios puedan acceder a los mismos recursos cuando se autentiquen mediante Workforce Identity Federation.

  5. Elimina las vinculaciones de RBAC obsoletas de tu clúster.

  6. Inhabilita Identity Service for GKE.

Usar Identity Service for GKE

Para configurar y usar Identity Service para GKE en tu clúster de GKE en modo estándar, los administradores del clúster deben hacer lo siguiente:

  1. Habilita Identity Service para GKE en un clúster.
  2. Configura Identity Service for GKE.
  3. Crea una política de control de acceso basado en roles para tu clúster.

Una vez que los administradores del clúster configuren el servicio de identidad para GKE, los desarrolladores podrán iniciar sesión y autenticarse en el clúster.

Objetos de Kubernetes creados por Identity Service for GKE

En la siguiente tabla se describen los objetos de Kubernetes que se crean cuando habilitas Identity Service para GKE en un clúster:

Objetos de Kubernetes
anthos-identity-service Namespace
Se usa en las implementaciones de Identity Service for GKE.
kube-public Namespace
Se usa para el archivo de configuración del cliente default.
gke-oidc-envoy LoadBalancer
Endpoint de las solicitudes de OIDC. Externa de forma predeterminada. Si se crea en un clúster sin endpoint de IP externa, el endpoint será interno a la nube privada virtual del clúster.
Se ha creado en el espacio de nombres anthos-identity-service.
gke-oidc-service ClusterIP
Facilita la comunicación entre la gke-oidc-envoy y la gke-oidc-service.
Se ha creado en el espacio de nombres anthos-identity-service.
gke-oidc-envoy Deployment
Ejecuta un proxy expuesto a gke-oidc-envoy LoadBalancer. Se comunica con gke-oidc-service para validar tokens de identidad. Actúa como proxy del servidor de la API de Kubernetes y suplanta la identidad de los usuarios al reenviar solicitudes al servidor de la API.
Se ha creado en el espacio de nombres anthos-identity-service.
gke-oidc-service Deployment
Valida tokens de identidad y proporciona un webhook de admisión de validación para recursos de ClientConfig.
Se ha creado en el espacio de nombres anthos-identity-service.
gke-oidc-operator Deployment
Concilia la configuración del cliente y el gke-oidc-envoy LoadBalancer.
Se ha creado en el espacio de nombres anthos-identity-service.
gke-oidc-certs Secret
Contiene la autoridad de certificación (CA) del clúster y los certificados TLS del balanceador de carga.
Creado en el espacio de nombres anthos-identity-service
default ClientConfig CRD
Contiene parámetros de OIDC, como el método de autenticación preferido, la configuración del proveedor de identidades y las asignaciones de reclamaciones de usuarios y grupos. Se usa para validar tokens de identidad. Los administradores de clústeres la usan para configurar los ajustes de OIDC antes de distribuirlos a los desarrolladores.
Creado en el espacio de nombres kube-public

Habilitar Identity Service para GKE en un clúster

De forma predeterminada, Gestión de Identidades y Accesos (IAM) se configura como proveedor de identidades para la autenticación de clústeres. Si quieres usar OIDC con proveedores de identidades de terceros, puedes habilitar el servicio de identidad para GKE en clústeres nuevos o ya creados mediante la CLI de Google Cloud.

Habilitar Identity Service para GKE en un clúster nuevo

Para crear un clúster con Identity Service for GKE habilitado, ejecuta el siguiente comando:

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

Sustituye CLUSTER_NAME por el nombre de tu nuevo clúster.

Habilitar Identity Service para GKE en un clúster disponible

Para habilitar Identity Service para GKE en un clúster, ejecuta el siguiente comando:

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

Sustituye CLUSTER_NAME por el nombre de tu clúster.

Configurar Identity Service for GKE

Para configurar los parámetros de Identity Service for GKE, descarga y modifica el archivo default ClientConfig.

  1. Descarga el archivo defaultClientConfig:

    kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml

  2. Actualiza la sección spec.authentication con los ajustes que prefieras:

    apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  name: cluster-name
  server: https://192.168.0.1:6443
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_ID
      certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
      extraParams: EXTRA_PARAMS
      issuerURI:  ISSUER_URI
      cloudConsoleRedirectURI: https://console.cloud.google.com/kubernetes/oidc
      kubectlRedirectURI: KUBECTL_REDIRECT_URL
      scopes: SCOPES
      userClaim: USER
      groupsClaim: GROUPS
      userPrefix: USER_PREFIX
      groupPrefix: GROUP_PREFIX

    Haz los cambios siguientes:

    • CLIENT_ID: el ID de la aplicación cliente que envía solicitudes de autenticación al proveedor de OIDC.
    • OIDC_PROVIDER_CERTIFICATE: (Opcional) un certificado PEM para el proveedor de OIDC. Este campo puede ser útil si tu proveedor de OIDC usa certificados autofirmados. Identity Service for GKE incluye un conjunto de raíces públicas de forma predeterminada.
    • EXTRA_PARAMS: parámetros de pares clave-valor adicionales que se envían al proveedor de OIDC.
      • Para autorizar grupos, usa resource=token-groups-claim.
      • Para autenticar Microsoft Azure y Okta, usa prompt=consent.
      • En Cloud Identity, usa prompt=consent,access_type=offline.
    • ISSUER_URI: la URL para enviar solicitudes de autorización de OIDC, como https://example.com/adfs. El servidor de la API de Kubernetes usa esta URL para descubrir las claves públicas con las que verificar los tokens. La URI debe usar HTTPS. En Cloud Identity, usa https://accounts.google.com.
    • KUBECTL_REDIRECT_URL: la URL de redirección que usa kubectl oidc login para la autorización. Por lo general, tiene el formato http://localhost:PORT/callback, donde PORT es cualquier puerto mayor que 1024 que estará disponible en las estaciones de trabajo de los desarrolladores, por ejemplo, http://localhost:10000/callback. Debes registrar la URL en tu proveedor de OIDC como URL de redirección autorizada para la aplicación cliente. Si usas la identidad de Google como proveedor de OIDC, consulta las instrucciones para definir un URI de redirección.
    • SCOPES: los ámbitos adicionales que se enviarán al proveedor de OIDC.
      • Microsoft Azure y Okta requieren el permiso offline_access.
      • En Cloud Identity, usa openid, email para obtener tokens de ID que contengan la dirección de correo en la reclamación email.
    • USER: la reclamación de usuario del token de identidad.
    • GROUPS: la reclamación de grupo del token de identidad.
    • USER_PREFIX: prefijo que se añade a las reclamaciones de usuario para evitar conflictos con nombres ya utilizados. De forma predeterminada, se añade un prefijo de emisor al userID proporcionado al servidor de la API de Kubernetes (a menos que la reclamación de usuario sea email). El identificador de usuario resultante es ISSUER_URI#USER. Te recomendamos que uses un prefijo, pero puedes inhabilitarlo si asignas el valor - a USER_PREFIX.
    • GROUP_PREFIX: prefijo que se añade a las reclamaciones de grupo para evitar conflictos con nombres ya existentes. Por ejemplo, si tiene dos grupos llamados foobar, añada el prefijo gid-. El grupo resultante es gid-foobar.

  3. Aplica la configuración actualizada:

    kubectl apply -f client-config.yaml

    Después de aplicar esta configuración, Identity Service para GKE se ejecuta en tu clúster y atiende las solicitudes detrás del balanceador de carga gke-oidc-envoy. La dirección IP del campo spec.server debe ser la dirección IP del balanceador de carga. Si cambias el campo spec.server, es posible que los comandos kubectl no funcionen.

  4. Haz una copia del archivo de configuración client-config.yaml:

    cp client-config.yaml login-config.yaml

  5. Actualiza el archivo de configuración login-config.yaml con el ajuste clientSecret de la sección spec.authentication.oidc.

    clientSecret: CLIENT_SECRET

    Sustituye CLIENT_SECRET por el secreto compartido entre la aplicación cliente de OIDC y el proveedor de OIDC.

  6. Distribuye el archivo login-config.yaml actualizado a tus desarrolladores.

Configurar Identity Service for GKE en clústeres con políticas estrictas

Para configurar Identity Service para GKE de forma que funcione correctamente en clústeres que tengan políticas de red estrictas, haz lo siguiente:

  1. Añade una regla de cortafuegos para el puerto TCP 15000 para permitir que tu plano de control se comunique con el webhook de validación ClientConfig.
  2. Si el gke-oidc-envoy se crea como un balanceador de carga interno, expónlo en tu VPC.
  3. Si tienes políticas que deniegan el tráfico en tu clúster, añade una regla de cortafuegos para el puerto TCP 8443 para permitir que la implementación de gke-oidc-envoy se comunique con la implementación de gke-oidc-service.

La versión 0.2.20 y posteriores del componente Identity Service for GKE no usan el puerto TCP 15000. Si la versión de tu componente es la 0.2.20 o una posterior, no es necesario que añadas una regla de cortafuegos para el puerto 15000. Para comprobar la versión de tu componente, ejecuta el siguiente comando:

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

Añadir propiedades personalizadas al balanceador de carga

Después de configurar Identity Service for GKE, puedes añadir anotaciones y propiedades personalizadas, como una dirección IP estática, al gke-oidc-envoybalanceador de carga. Para editar el servicio gke-oidc-envoy, ejecuta el siguiente comando:

kubectl edit service gke-oidc-envoy -n anthos-identity-service

Consulta los parámetros del servicio LoadBalancer para obtener más información sobre cómo configurar el balanceo de carga TCP/UDP en GKE.

Crear una política de RBAC para el clúster

Los administradores pueden usar el control de acceso basado en roles (RBAC) de Kubernetes para conceder acceso a los usuarios autenticados del clúster. Para configurar el control de acceso basado en roles en tu clúster, debes asignar roles de control de acceso basado en roles a cada desarrollador. Para conceder acceso a los recursos de un espacio de nombres concreto, crea un rol y un RoleBinding. Para conceder acceso a los recursos de todo un clúster, crea un ClusterRole y un ClusterRoleBinding.

Por ejemplo, supongamos que un usuario necesita ver todos los objetos Secret del clúster. Sigue estos pasos para asignar los roles de RBAC necesarios a este usuario.

  1. Guarda el siguiente manifiesto de ClusterRole como secret-viewer-cluster-role.yaml. Una persona a la que se le haya concedido este rol puede obtener, ver y enumerar cualquier secreto del clúster.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-viewer
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

  2. Aplica el manifiesto de ClusterRole:

    kubectl apply -f secret-viewer-cluster-role.yaml

  3. Guarda el siguiente manifiesto de ClusterRoleBinding como secret-viewer-cluster-role-binding.yaml. La vinculación concede el rol secret-viewer a un nombre de usuario definido en el archivo de configuración del cliente.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name:  people-who-view-secrets
subjects:
- kind: User
  name: ISSUER_URI#USER
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io

    Haz los cambios siguientes:

    • ISSUER_URI: el URI del emisor de spec.authentication.oidc.issuerURI en el archivo de configuración del cliente.
    • USER: el identificador de usuario del token en el nombre de la reclamación configurado en spec.authentication.oidc.userClaim en el archivo de configuración del cliente.

  4. Aplica el manifiesto de ClusterRoleBinding:

    kubectl apply -f secret-viewer-cluster-role-binding.yaml

Iniciar sesión y autenticarse en el clúster

Como desarrollador que recibe el archivo de configuración de OIDC de tu administrador, puedes autenticarte en tus clústeres.

  1. Descarga el archivo login-config.yaml que te haya proporcionado tu administrador.

  2. Instala el SDK de la CLI de Google Cloud, que ofrece un componente OIDC independiente. Para instalarlo, ejecuta el siguiente comando:

    gcloud components install kubectl-oidc

  3. Autentícate en tu clúster:

    kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml

    Se abrirá un navegador web para completar el proceso de autenticación.

  4. Una vez que te hayas autenticado, podrás ejecutar comandos de kubectl, como los siguientes:

    kubectl get pods

Inhabilitar Identity Service for GKE

Puedes inhabilitar Identity Service for GKE con la CLI de gcloud. Para inhabilitar Identity Service for GKE, ejecuta el siguiente comando:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

Limitaciones conocidas

El componente gke-oidc-envoy, que se encarga de autenticar tu clúster mediante Identity Service for GKE, tiene un número fijo de réplicas. Esto significa que no se ajusta automáticamente para gestionar el aumento del tráfico. En los clústeres regionales, este componente se implementa con tres réplicas.

No puedes escalar directamente la implementación de gke-oidc-envoy. Te recomendamos que migres a la Federación de Identidades de Workforce para disfrutar de una solución más robusta y escalable.

Siguientes pasos