Se usó la API de Cloud Translation para traducir esta página.

Usa proveedores de identidad externos para autenticarte en GKE

Autopilot Estándar

En esta página, se muestra cómo configurar la autenticación en los clústeres de Google Kubernetes Engine (GKE) desde proveedores de identidad externos (IdP).

Esta página está destinada a los administradores y operadores de la plataforma, y a los administradores de identidad y cuentas que usan un IdP externo que admite OpenID Connect (OIDC) o el lenguaje de marcado para confirmaciones de seguridad (SAML) 2.0.

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

Métodos de autenticación de IdP externos en GKE

Recomendado: Federación de identidades de personal

La federación de identidades de personal 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 personal no requiere ninguna instalación en el clúster, funciona con clústeres de Autopilot y clústeres estándar, y está integrada en Google Cloud. Para obtener más información, consulta la documentación de IAM sobre Workforce Identity Federation.

No recomendado: Identity Service para GKE

Solo en los clústeres de GKE Standard, GKE también admite Identity Service para GKE. El servicio de identidad para GKE se limita a los IDP de OIDC y, además, instala componentes adicionales en tu clúster. GKE recomienda usar la federación de identidades de personal en lugar de Identity Service para GKE.

Antes de comenzar

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

Consideraciones

Los sistemas sin interfaz gráfica no son compatibles con la federación de identidades de personal ni con Identity Service para GKE. Un flujo de autenticación basado en el navegador te solicita consentimiento y autorización para tu cuenta de usuario.

Usa la federación de identidades de Workforce en GKE

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

Configura la federación de identidades de personal para tu organización y el IdP externo. Para obtener instrucciones, consulta Configura la federación de identidades de personal.
Configura el acceso desde tu IdP externo a la Google Cloud consola de la federación de identidades de personal. Para obtener más información, consulta Configura el acceso de usuario a la consola (federada).
Configura el acceso de los usuarios con uno de los siguientes mecanismos de autorización:
- RBAC de Kubernetes
- Políticas de permisos de IAM

Configura el acceso de los usuarios a los clústeres con el RBAC

Google Cloud usa identificadores principales para identificar a los usuarios en tus grupos de identidades de personal. Puedes hacer referencia a estos identificadores principales en tus políticas de RBAC de Kubernetes o en las políticas de IAM. Puedes otorgar permisos a personas o grupos de usuarios, como en los siguientes ejemplos:

Identidad Identificador de principal

Único usuario

Identidad	Identificador de principal
Único usuario	principal://iam.googleapis.com/locations/global/workforcePools/`WORKFORCE_IDENTITY_POOL`/subject/`SUBJECT_ATTRIBUTE_VALUE` Reemplaza lo siguiente: `WORKFORCE_IDENTITY_POOL`: El nombre del grupo de identidades de personal. `SUBJECT_ATTRIBUTE_VALUE`: Es el valor de un atributo en la aserción de asunto del token de identidad. Por ejemplo, este podría ser el valor del campo `NameID` en una aserción de 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` Reemplaza lo siguiente: `WORKFORCE_IDENTITY_POOL`: El nombre del grupo de identidades de personal. `GROUP_NAME`: Es el nombre de un grupo del que es miembro el usuario que se autentica. La aserción en tu token de IdP 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

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE

Reemplaza lo siguiente:

WORKFORCE_IDENTITY_POOL: El nombre del grupo de identidades de personal.
SUBJECT_ATTRIBUTE_VALUE: Es el valor de un atributo en la aserción de asunto del token de identidad. Por ejemplo, este podría ser el valor del campo NameID en una aserción de 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

Reemplaza lo siguiente:

WORKFORCE_IDENTITY_POOL: El nombre del grupo de identidades de personal.
GROUP_NAME: Es el nombre de un grupo del que es miembro el usuario que se autentica. La aserción en tu token de IdP 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 cada identificador principal que admite la federación de identidades de personal, consulta Representa a los usuarios del grupo de personal en políticas de IAM.

En el siguiente ejemplo, se muestra cómo otorgar acceso de solo lectura en todo el clúster a secretos a cualquier entidad del grupo de personal full-time-employees que tenga el atributo access_level="sensitive" en su token de IdP.

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 vincules este ClusterRole puede ver los Secrets.

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/attribute.access_level/sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io

Este ClusterRoleBinding otorga el ClusterRole secret-viewer a cualquier usuario que tenga el atributo access_level="sensitive".

Implementa el ClusterRole y el ClusterRoleBinding:

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

Migra Identity Service para clústeres de GKE a la federación de identidades de Workforce

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

Sintaxis de Identity Service para GKE	Sintaxis de la federación de identidades de personal
`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 para que use la federación de identidades de personal, haz lo siguiente:

Configura la federación de identidades de personal para tu organización y el IdP externo. Para obtener instrucciones, consulta Configura la federación de identidades de personal.
Actualiza los manifiestos de cualquier RoleBinding y ClusterRoleBinding en tus clústeres para usar la sintaxis del identificador de la federación de identidades de personal. 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 de GoogleCloudPlatform/gke-utilities.
  
  Esta utilidad encuentra vinculaciones de RBAC existentes que usan la sintaxis de Identity Service para GKE y crea manifiestos nuevos que usan los identificadores principales de la federación de identidades de personal correspondientes.
- Actualizaciones manuales: Para cada vinculación que haga referencia a un usuario o grupo autenticado, crea una copia independiente del archivo de manifiesto del objeto que use la sintaxis del identificador de la Federación de Identidades de Workforce.
Aplica los manifiestos actualizados de RoleBindings y ClusterRoleBindings a tu clúster.
Prueba que los usuarios puedan acceder a los mismos recursos cuando se autentiquen con la federación de identidades del personal.
Quita las vinculaciones de RBAC obsoletas de tu clúster.
Inhabilita Identity Service para GKE.

Usa Identity Service para GKE

Para configurar y usar Identity Service para GKE en tu clúster de GKE en modo estándar, 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.

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 sin un extremo de IP externo, 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 en un clúster

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.

Configura Identity Service para GKE

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

Para configurar Identity Service para GKE para que funcione como se espera en clústeres que tienen políticas de red estrictas, 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 Parámetros del servicio LoadBalancer para obtener más información sobre la configuración del balanceo de cargas TCP/UDP para GKE.

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

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

Como desarrollador que recibe 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

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 federación de identidades de personal.
Obtén más información sobre la implementación de cargas de trabajo.