Usa proveedores de identidad externos para autenticarte en GKE

Estándar

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 Kubernetes Engine de Google.

Habilitar la API de Kubernetes Engine de Google

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. 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.

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:

Configuran Identity Service para GKE en un clúster.
Configuran Identity Service para GKE.
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.

Descarga el ClientConfig default:

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

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.
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, es posible que los comandos kubectl fallen.
Haz una copia del archivo de configuración client-config.yaml:
```
cp client-config.yaml login-config.yaml
```
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.
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:

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.
Si gke-oidc-envoy se crea como un balanceador de cargas interno, exponlo en tu VPC.
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.

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"]

Aplica el manifiesto de ClusterRole:

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

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.

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.

Descarga el archivo login-config.yaml que proporcionó el administrador.
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
```
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.
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?

Obtén más información sobre la implementación de cargas de trabajo.
Obtén más información sobre OpenID Connect.
Obtén más información sobre los permisos y las reclamaciones.