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.
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:
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 | principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE Reemplaza lo siguiente:
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:
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 atributoaccess_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 deGoogleCloudPlatform/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.
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
.
- Para autorizar grupos, usa
ISSUER_URI
: la URL para enviar solicitudes de autorización de OIDC, comohttps://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, usahttps://accounts.google.com
.KUBECTL_REDIRECT_URL
: la URL de redireccionamiento que usakubectl oidc login
para la autorización. Por lo general, tiene el formatohttp://localhost:PORT/callback
, en el quePORT
es cualquier puerto superior a1024
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ónemail
.
- Microsoft Azure y Okta requieren el permiso
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 aluserID
que se proporciona al servidor de la API de Kubernetes (a menos que la reclamación del usuario seaemail
). El identificador de usuario resultante esISSUER_URI#USER
. Recomendamos usar un prefijo, pero puedes inhabilitarlo si configurasUSER_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 llamadosfoobar
, agrega un prefijogid-
. El grupo resultante esgid-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 campospec.server
debe ser la dirección IP del balanceador de cargas. Si cambias el campospec.server
, es posible que los comandoskubectl
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ónclientSecret
en la secciónspec.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ónClientConfig
. - 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 degke-oidc-envoy
se comunique con la implementación degke-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 rolsecret-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 despec.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 enspec.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.