Usa proveedores de identidad externos para autenticarte en GKE

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

En esta página, se explica cómo configurar un proveedor de identidad externo para autenticarse en clústeres de Google Kubernetes Engine (GKE).

Descripción general

El servicio de identidad para GKE extiende las soluciones de identidad existentes para la autenticación en tus clústeres de GKE. Gracias a la compatibilidad con OpenID Connect (OIDC), puedes administrar el acceso a los clústeres de Kubernetes mediante los procedimientos estándar de la organización para crear, habilitar e inhabilitar cuentas de usuario. El servicio de identidad para GKE se limita a los proveedores de identidad de OIDC.

Antes de comenzar

  • En este tema, se supone que estás familiarizado con los siguientes conceptos de autenticación y de OpenID:

  • Los sistemas sin interfaz gráfica no son compatibles. Se usa un flujo de autenticación basado en el navegador para solicitar tu consentimiento y autorizar la cuenta de usuario.

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa la CLI de gcloud.

Quién usa el servicio de identidad para GKE

Las tareas de este documento se aplican a ti si eres uno de los siguientes:

  • Administrador del clúster: Crea uno o más clústeres de usuario y archivos de configuración de autenticación para los desarrolladores que usan los clústeres.

  • Desarrollador: Ejecuta cargas de trabajo en uno o más clústeres y usa OIDC para la autenticación.

Cómo funciona

A fin de configurar y usar Identity Service para GKE en tu clúster de GKE, los administradores de clústeres hacen lo siguiente:

  1. Configuran Identity Service para GKE en un clúster.
  2. Configuran Identity Service para GKE.
  3. Crean una política de RBAC para el clúster.

Después de que los administradores de clústeres configuran Identity Service para GKE, los desarrolladores pueden acceder y autenticarse en el clúster.

Configura Identity Service para GKE en un clúster

Esta sección está destinada a los administradores de clústeres.

De forma predeterminada, Identity and Access Management (IAM) se configura como el proveedor de identidad para la autenticación de clústeres. Si deseas usar OIDC con proveedores de identidad de terceros, puedes habilitar Identity Service para GKE en clústeres nuevos o existentes mediante Google Cloud CLI.

Habilita Identity Service para GKE en un clúster nuevo

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

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

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

Habilita Identity Service para GKE en un clúster existente

A fin de habilitar Identity Service para GKE en un clúster existente, ejecuta el siguiente comando:

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

Reemplaza CLUSTER_NAME por el nombre del clúster.

Objetos de Kubernetes creados por Identity Service para GKE

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

Objetos de Kubernetes
anthos-identity-service Namespace
Se usa para las implementaciones de Identity Service para GKE.
kube-public Namespace
Se usa para el archivo de configuración de cliente default.
gke-oidc-envoy LoadBalancer
El extremo de las solicitudes de OIDC. Externo de forma predeterminada. Si se crea en un clúster privado o en un clúster con una política de red estricta, el extremo es interno del clúster de la nube privada virtual.
Se crea en el espacio de nombres anthos-identity-service.
gke-oidc-service ClusterIP
Facilita la comunicación entre la implementación gke-oidc-envoy y la implementación gke-oidc-service.
Se crea en el espacio de nombres anthos-identity-service.
gke-oidc-envoy Deployment
Ejecuta un proxy expuesto al gke-oidc-envoy LoadBalancer. Se comunica con gke-oidc-service para validar tokens de identidad. Actúa como un proxy para el servidor de la API de Kubernetes y actúa en nombre de los usuarios cuando pasa solicitudes al servidor de la API.
Se crea en el espacio de nombres anthos-identity-service.
gke-oidc-service Deployment
Valida los tokens de identidad y proporciona un webhook de admisión de validación para los recursos ClientConfig.
Se crea en el espacio de nombres anthos-identity-service.
gke-oidc-operator Deployment
Concilia la configuración del cliente y el LoadBalancer gke-oidc-envoy.
Se crea en el espacio de nombres anthos-identity-service.
gke-oidc-certs Secret
Contiene la autoridad certificadora (CA) del clúster y los certificados TLS para el LoadBalancer.
Se crea 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 identidad y las asignaciones de reclamaciones de usuarios y grupos. Se usa para la validación del token de identidad. Los administradores del clúster lo usan para configurar OIDC antes de su distribución a los desarrolladores.
Se crea en el espacio de nombres kube-public

Configura Identity Service para GKE

Esta sección está destinada a los administradores de clústeres.

Si deseas configurar los parámetros de Identity Service para GKE, descarga y modifica el ClientConfig default.

  1. Descarga el ClientConfig default:

    kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml
    
  2. Actualiza la sección spec.authentication con tu configuración preferida:

    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
    

    Reemplaza lo siguiente:

    • CLIENT_ID: es el ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de OIDC.
    • OIDC_PROVIDER_CERTIFICATE: (Opcional) es un certificado de PEM para el proveedor de OIDC. Este campo puede ser útil si tu proveedor de OIDC usa certificados autofirmados. Identity Service para GKE incluye un conjunto de raíces públicas de forma predeterminada.
    • EXTRA_PARAMS: parámetros de clave-valor adicionales para enviar al proveedor de OpenID.
      • Para autorizar grupos, usa resource=token-groups-claim.
      • Para autenticar Microsoft Azure y Okta, usa prompt=consent.
      • Para 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 a fin de buscar claves públicas para la verificación de tokens. El URI debe usar HTTPS. Para Cloud Identity, usa https://accounts.google.com.
    • KUBECTL_REDIRECT_URL: la URL de redireccionamiento que usa kubectl oidc login para la autorización. Por lo general, tiene el formato http://localhost:PORT/callback, en el que PORT es cualquier puerto superior a 1024 que estará disponible en las estaciones de trabajo de desarrolladores, por ejemplo, http://localhost:10000/callback. Debes registrar la URL con tu proveedor de OIDC como una URL de redireccionamiento autorizada para la aplicación cliente. Si usas Google Identity como tu proveedor de OIDC, lee Establece un URI de redireccionamiento para obtener instrucciones.
    • SCOPES: son los permisos adicionales que se deben enviar al proveedor de OIDC.
      • Microsoft Azure y Okta requieren el permiso offline_access.
      • Para Cloud Identity, usa openid, email a fin de obtener tokens de ID que contengan la dirección de correo electrónico en la reclamación email.
    • USER: es la reclamación del usuario del token de identidad.
    • GROUPS: es la reclamación del grupo del token de identidad.
    • USER_PREFIX: es el prefijo que se antepone a las reclamaciones de usuarios para evitar conflictos con los nombres existentes. De forma predeterminada, se agrega un prefijo de emisor al userID que se proporciona al servidor de la API de Kubernetes (a menos que la reclamación del usuario sea email). El identificador de usuario resultante es ISSUER_URI#USER. Recomendamos usar un prefijo, pero puedes inhabilitarlo si configuras USER_PREFIX como -.
    • GROUP_PREFIX: el prefijo que se antepone a las reclamaciones de grupos para evitar conflictos con los nombres existentes. Por ejemplo, si tienes dos grupos llamados foobar, agrega un 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 dentro del clúster y entrega solicitudes detrás del balanceador de cargas gke-oidc-envoy. La dirección IP en el campo spec.server debe ser la dirección IP del balanceador de cargas. Si cambias el campo spec.server, los comandos kubectl podrían fallar.

  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 la configuración clientSecret en la sección spec.authentication.oidc.

    clientSecret: CLIENT_SECRET
    

    Reemplaza 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.

Configura Identity Service para GKE en clústeres con políticas estrictas

A fin de configurar Identity Service para GKE para que funcione como se espera en clústeres que tienen políticas de red estrictas, como los clústeres privados, haz lo siguiente:

  1. Agrega una regla de firewall para el puerto TCP 15000 a fin de permitir que tu plano de control se comunique con el webhook de validación ClientConfig.
  2. Si gke-oidc-envoy se crea como un balanceador de cargas interno, exponlo en tu VPC.
  3. Si tienes políticas que rechazan el tráfico dentro de tu clúster, agrega una regla de firewall para el puerto TCP 8443 a fin de permitir que la implementación de gke-oidc-envoy se comunique con la implementación de gke-oidc-service.

El servicio de identidad para la versión 0.2.20 del componente de GKE y versiones posteriores no usa el puerto TCP 15000. Si tu versión del componente es 0.2.20 o posterior, no es necesario que agregues una regla de firewall para el puerto 15000. Para verificar tu versión de componente, ejecuta el siguiente comando:

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

Agrega propiedades personalizadas al balanceador de cargas

Después de configurar Identity Service para GKE, puedes agregar anotaciones y propiedades personalizadas, como una dirección IP estática, al balanceador de cargas gke-oidc-envoy. Para borrar el servicio gke-oidc-envoy, ejecuta el siguiente comando:

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

Consulta la documentación sobre cómo configurar el balanceo de cargas TCP/UDP para GKE.

Crea una política de RBAC para el clúster de usuario

Esta sección está destinada a los administradores de clústeres.

Los administradores pueden usar el control de acceso basado en funciones (RBAC) de Kubernetes para otorgar acceso a los usuarios del clúster autenticados. Si deseas configurar RBAC para tu clúster, debes otorgar roles de RBAC a cada desarrollador. Para otorgar acceso a los recursos en un espacio de nombres en particular, crea una Role y una RoleBinding. Para otorgar acceso a los recursos en la totalidad de un clúster, crea una ClusterRole y una ClusterRoleBinding.

Por ejemplo, considera un usuario que necesita ver todos los objetos Secret del clúster. Los siguientes pasos otorgan 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 otorga este rol puede obtener, visualizar y enumerar cualquier Secret en el 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 otorga 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
    

    Reemplaza lo siguiente:

    • ISSUER_URI: es el URI del emisor de spec.authentication.oidc.issuerURI en el archivo de configuración del cliente.
    • USER: es el identificador de usuario en el token bajo 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
    

Accede y autentícate en el clúster

Esta sección está destinada a los desarrolladores.

Cuando recibes el archivo de configuración de OIDC de tu administrador, puedes autenticarte en tus clústeres.

  1. Descarga el archivo login-config.yaml que proporcionó el administrador.

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

    gcloud components install kubectl-oidc
    
  3. Realiza la autenticación 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. Después de la autenticación, puedes ejecutar comandos de kubectl, por ejemplo:

    kubectl get pods
    

Inhabilita Identity Service para GKE

Esta sección está destinada a los administradores de clústeres.

Puedes inhabilitar Identity Service para GKE con la CLI de gcloud. A fin de inhabilitar Identity Service para GKE, ejecuta el siguiente comando:

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

¿Qué sigue?