Autenticarse con OpenID Connect (OIDC)

Consulta cómo configurar GKE en AWS para usar OpenID Connect (OIDC) para la autenticación en clústeres de usuarios. En este tema se explica el proceso para configurar GKE en AWS con cualquier proveedor de OpenID.

Para actualizar un clúster que usa la autenticación OIDC a Kubernetes 1.21, consulta Actualizar a 1.21.

Para obtener una descripción general del flujo de autenticación de GKE en AWS, consulta Autenticación.

Información general

GKE en AWS admite OIDC como uno de los mecanismos de autenticación para interactuar con el servidor de la API de Kubernetes de un clúster de usuario. Con OIDC, puedes gestionar el acceso a los clústeres de Kubernetes mediante los procedimientos estándar de tu organización para crear, habilitar e inhabilitar cuentas de usuario.

Antes de empezar

  • En este tema se da por hecho que conoces los siguientes conceptos de autenticación y OpenID:

  • Google Cloud CLI debe estar instalado en el equipo local de cada desarrollador.

  • No se admiten sistemas sin interfaz gráfica. Para autenticarte, debes abrir un navegador en el equipo local en el que se ejecuta la CLI de gcloud. A continuación, el navegador te pedirá que autorices tu cuenta de usuario.

  • Para autenticarte a través de la consola Google Cloud , cada clúster que quieras configurar para la autenticación OIDC debe registrarse en Google Cloud.

Perfiles ficticios

En este tema se hace referencia a tres perfiles:

  • Administrador de la organización: esta persona elige un proveedor de OpenID y registra las aplicaciones cliente con el proveedor.

  • Administrador del clúster: esta persona crea uno o varios clústeres de usuarios y archivos de configuración de autenticación para los desarrolladores que usan los clústeres.

  • Desarrollador: esta persona ejecuta cargas de trabajo en uno o varios clústeres y usa OIDC para autenticarse.

Elegir un proveedor de OpenID

Esta sección está dirigida a los administradores de organizaciones.

Puedes usar el proveedor de OpenID que quieras. Para ver una lista de proveedores certificados, consulta Certificación de OpenID.

Crear URLs de redirección

Esta sección está dirigida a los administradores de organizaciones.

El proveedor de OpenID usa URLs de redirección para devolver tokens de ID. Debes crear URLs de redirección para la CLI de gcloud y para la consola deGoogle Cloud .

Definir la URL de redirección de gcloud CLI

Cuando configures tu proveedor de OpenID, especifica tu URL de redirección de la CLI como http://localhost:PORT/callback

Sustituye PORT por el número de puerto que quieras, siempre que sea superior a 1024.

Definir la Google Cloud URL de redirección de la consola

La URL de redirección de la consola Google Cloud es:

https://console.cloud.google.com/kubernetes/oidc

Cuando configure su proveedor de OIDC, especifique https://console.cloud.google.com/kubernetes/oidc como una de sus URLs de redirección.

Registrar tus aplicaciones cliente con el proveedor de OpenID

Esta sección está dirigida a los administradores de organizaciones.

Para que tus desarrolladores puedan usar la CLI de Google Cloud o la Google Cloud consola con tu proveedor de OpenID, debes registrar esos dos clientes con el proveedor de OpenID. El registro incluye estos pasos:

  • Consulta el URI de la entidad emisora de tu proveedor. La CLI de gcloud o laGoogle Cloud consola envían solicitudes de autenticación a este URI.

  • Configura tu proveedor con la URL de redirección, incluido el número de puerto, para la CLI de gcloud.

  • Configura tu proveedor con la URL de redirección de la consola Google Cloud , https://console.cloud.google.com/kubernetes/oidc.

  • Crea un único ID de cliente que tu proveedor utilice para identificar tanto la interfaz de línea de comandos de Google Cloud como laGoogle Cloud consola.

  • Crea un único secreto de cliente que la CLI de gcloud y la consola utilicen para autenticarse en el proveedor de OpenID. Google Cloud

  • Crea un ámbito personalizado que la CLI de gcloud o la consola puedan usar para solicitar los grupos de seguridad del usuario. Google Cloud

  • Crea un nombre de reclamación personalizado que el proveedor use para devolver los grupos de seguridad del usuario.

Configura el clúster

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

Para configurar la autenticación OIDC, debes configurar el recurso AWSCluster de tu clúster de usuario con los detalles de autenticación de un clúster. Los detalles de AWSCluster se usan para configurar OIDC tanto para la consola como para el complemento de autenticación de GKE. Google Cloud La configuración incluye la siguiente información de OIDC:

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET 
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

Campos de autenticación

En la siguiente tabla se describen los campos del objeto authentication.awsIAM.adminIdentityARNs.

En la siguiente tabla se describen los campos del objeto `oidc`.
Campo Obligatorio Descripción Formato
adminIdentityARNs Sí, si vas a configurar OIDC. Nombre de recurso de Amazon (ARN) de las identidades de gestión de identidades y accesos de AWS (usuarios o roles) a las que GKE en AWS ha concedido acceso de administrador de clústeres. Ejemplo: arn:aws:iam::123456789012:group/Developers Cadena
Campo Obligatorio Descripción Formato
certificateAuthorityData No Un certificado codificado en PEM codificado en base64 para el proveedor de OIDC. Para crear la cadena, codifica el certificado, incluidos los encabezados, en base64. Incluye la cadena resultante en certificateAuthorityData como una sola línea. Ejemplo: certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT== Cadena
clientID Sí ID de la aplicación cliente que envía solicitudes de autenticación al proveedor de OpenID. Cadena
clientSecret No Secreto compartido entre la aplicación cliente de OIDC y el proveedor de OIDC. Cadena
extraParams No Parámetros de pares clave-valor adicionales que se enviarán al proveedor de OpenID. Si vas a autorizar un grupo, introduce resource=token-groups-claim.

Si tu servidor de autorización solicita el consentimiento para la autenticación con Microsoft Azure y Okta, define extraParams como prompt=consent. En Cloud Identity, define extraParams como prompt=consent,access_type=offline.

Lista delimitada por comas
groupsClaim No Reclamación JWT que usa el proveedor para devolver tus grupos de seguridad. Cadena
groupPrefix No Prefijo añadido a las reclamaciones de grupo para evitar conflictos con nombres ya existentes. Por ejemplo, si tienes dos grupos llamados foobar, añade un prefijo gid-. El grupo resultante será gid-foobar. Cadena
issuerURI Sí URL a la que se envían las solicitudes de autorización a tu OpenID, como https://example.com/adfs. El servidor de la API de Kubernetes usa esta URL para descubrir las claves públicas que se utilizan para verificar los tokens. El URI debe usar HTTPS. URL String
kubectlRedirectURI Sí La URL de redirección que usa `kubectl` para la autorización. URL String
permisos Sí Permisos adicionales que se enviarán al proveedor de OpenID. Microsoft Azure y Okta requieren el permiso offline_access. Lista delimitada por comas
userClaim No Reclamación de JWT que se usará como nombre de usuario. Puedes elegir otras reclamaciones, como el correo o el nombre, en función del proveedor de OpenID. Sin embargo, las reclamaciones que no sean de correo electrónico tienen el prefijo de la URL del emisor para evitar conflictos de nombres. Cadena
userPrefix No Prefijo añadido a las reclamaciones de nombre de usuario para evitar conflictos con nombres ya existentes. Cadena

Ejemplo: autorizar usuarios y grupos

Muchos proveedores codifican propiedades que identifican a los usuarios, como el correo electrónico y los IDs de usuario, en un token. Sin embargo, estas propiedades implican riesgos para las políticas de autenticación:

  • Los IDs de usuario pueden dificultar la lectura y la auditoría de las políticas.
  • El uso de direcciones de correo puede suponer un riesgo de disponibilidad (si un usuario cambia su correo principal) y un riesgo de seguridad (si se puede reasignar un correo).

En lugar de asignar IDs de usuario, te recomendamos que uses políticas de grupo, que pueden ser persistentes y más fáciles de auditar.

Supongamos que tu proveedor crea tokens de identidad que incluyen los siguientes campos:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

Con este formato de token, rellenarías la especificación oidc de tu archivo de configuración de la siguiente manera:

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

Una vez que hayas creado el clúster de usuario, usa el control de acceso basado en roles (RBAC) de Kubernetes para conceder acceso privilegiado a los usuarios autenticados.

En el siguiente ejemplo, se crea un ClusterRole que concede a sus usuarios acceso de solo lectura a los secretos del clúster y se crea un recurso ClusterRoleBinding para vincular el rol al grupo autenticado.

  1. Define un ClusterRole. Copia el siguiente código YAML en un archivo llamado secret-reader-role.yaml.

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

  2. Define un ClusterRoleBinding. Copia el siguiente código YAML en un archivo llamado secret-reader-admins.yaml.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

  3. Aplica secret-reader-role.yaml y secret-reader-admins.yaml a tu clúster con kubectl.

    env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f secret-reader-role.yaml && \
  kubectl apply -f secret-reader-admins.yaml

    Los usuarios a los que se les ha concedido acceso en read-secrets-admins ahora pueden leer secretos en tu clúster.

Crear una configuración de inicio de sesión

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

Después de crear un clúster de usuarios, debes generar un archivo de configuración para el clúster mediante gcloud anthos create-login-config.

  1. En tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu clúster de usuarios. 

    cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
     Sustituye CLUSTER_NAME por el nombre de tu clúster de usuario.

  2. Crea la configuración con gcloud anthos.

    gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig

    Sustituye usercluster-kubeconfig por la ruta al archivo kubeconfig de tu clúster de usuario. En Linux y macOS, este archivo se encuentra de forma predeterminada en ~/.kube/config.

Este comando genera un archivo (kubectl-anthos-config.yaml) que contiene la información de configuración que usan los desarrolladores para autenticarse en el clúster con la CLI de gcloud. No debes modificar este archivo.

Para obtener más información sobre el contenido de kubectl-anthos-config.yaml, consulta el apéndice.

Distribuir la configuración de inicio de sesión

Distribuye el archivo de configuración a los usuarios que necesiten autenticarse en tus clústeres de usuarios. Puedes distribuir la configuración de las siguientes formas:

  • Colocando el archivo en el directorio predeterminado.
  • Distribuir el archivo de forma segura.
  • Alojar el archivo en un servidor HTTPS.

Directorios predeterminados de configuración de inicio de sesión

Las ubicaciones predeterminadas para almacenar el archivo de configuración de cada sistema operativo son las siguientes:

Linux
$HOME/.config/google/anthos/kubectl-anthos-config.yaml, donde $HOME es el directorio principal del usuario.
macOS
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml, donde $HOME es el directorio principal del usuario.
Windows
%APPDATA%/google/anthos/kubectl-anthos-config.yaml, donde %APPDATA% es el directorio de datos de la aplicación del usuario.

Una vez que se haya distribuido la configuración de inicio de sesión, los desarrolladores podrán configurar la CLI de gcloud para acceder al clúster.

Modificar un clúster después de actualizarlo a Kubernetes 1.21

Después de actualizar tu clúster a Kubernetes 1.21, debes configurar GKE Identity Service y eliminar la información de OIDC de la configuración de tu clúster. Para actualizar la configuración, sigue estos pasos:

  1. Sigue los pasos que se indican en Actualizar un clúster.

  2. En tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu clúster de usuarios. 

    cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
     Sustituye CLUSTER_NAME por el nombre de tu clúster de usuario.

  3. Abre el manifiesto que contiene el AWSCluster en un editor de texto. Mantén el archivo abierto y usa los valores del objeto oidc para seguir los pasos que se indican en Configurar clústeres para el servicio de identidad de GKE.

  4. En tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu servicio de gestión. 

    cd anthos-aws
anthos-gke aws management get-credentials

  5. Abre el archivo YAML que creó tu AWSCluster en un editor de texto. Si no tienes el archivo YAML inicial, puedes usar kubectl edit.

    Editar YAML

    Si has seguido las instrucciones de Crear un clúster de usuario, tu archivo YAML se llama cluster-0.yaml. Abre este archivo en un editor de texto.

    kubectl edit

    Para usar kubectl edit y editar tu AWSCluster, ejecuta el siguiente comando:

    env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-name

    Sustituye cluster-name por tu AWSCluster. Por ejemplo, para editar el clúster predeterminado, cluster-0, ejecuta el siguiente comando:

    env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit awscluster cluster-0

  6. Elimina el objeto oidc del manifiesto de tu clúster.

  7. Guarda el archivo. Si usas kubectl edit, kubectl aplica los cambios automáticamente. Si estás editando el archivo YAML, aplícalo a tu servicio de gestión con el siguiente comando:

    env HTTPS_PROXY=http://localhost:8118 \
  kubectl apply -f cluster-0.yaml

    A continuación, el servicio de gestión actualiza tu AWSCluster.

Configurar gcloud para acceder al clúster

Esta sección está dirigida a desarrolladores o administradores de clústeres.

Requisitos previos

Para completar esta sección, debes hacer lo siguiente:

  • Una configuración de inicio de sesión.

  • Una versión actualizada de gcloud CLI con los anthos-auth componentes.

    gcloud components update
gcloud components install anthos-auth

  • Para comprobar que la CLI de gcloud se ha instalado correctamente, ejecuta el siguiente comando, que debería responder con detalles sobre los argumentos necesarios y las opciones disponibles.

    gcloud anthos auth

Autenticarse en el clúster

Puedes autenticarte en tu clúster de las siguientes formas:

  • Con la CLI de gcloud en tu máquina local.
  • Con la CLI de gcloud en una máquina remota mediante un túnel SSH.

  • Conéctate en la consola de Google Cloud .

gcloud local

Usa gcloud anthos auth login para autenticarte en tu clúster con tu configuración de inicio de sesión.

Si has colocado la configuración de inicio de sesión en la ubicación predeterminada y has configurado el nombre del clúster, puedes usar gcloud anthos auth login sin opciones. También puedes configurar el clúster, el usuario y otros detalles de autenticación con parámetros opcionales.

Predeterminado

gcloud anthos auth login --cluster CLUSTER_NAME

Sustituye CLUSTER_NAME por el nombre completo del clúster. Por ejemplo, projects/my-gcp-project/locations/global/memberships/cluster-0-0123456a.

Parámetros opcionales

gcloud anthos auth login admite los siguientes parámetros opcionales:

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

Los parámetros se describen en la siguiente tabla.

Parámetro Descripción
cluster Nombre del clúster al que se va a autenticar. El valor predeterminado es el clúster de `kubectl-anthos-config.yaml`.
user Nombre de usuario de las credenciales de kubeconfig. El valor predeterminado es {cluster-name}-anthos-default-user.
login-config La ruta al archivo de configuración generado por el administrador del clúster para el desarrollador o una URL que aloje el archivo. El valor predeterminado es kubectl-anthos-config.yaml.
login-config-cert Si se usa una URL para login-config, la ruta al archivo de certificado de la AC para establecer conexiones HTTPS.
kubeconfig Ruta al archivo kubeconfig que contiene los tokens. El valor predeterminado es $HOME/.kube/config`.
Prueba de funcionamiento Prueba las opciones de línea de comandos sin cambiar la configuración ni el clúster.

El comando gcloud anthos login inicia un navegador que pide al usuario que inicie sesión con sus credenciales de empresa, realiza el intercambio de credenciales de OIDC y obtiene los tokens correspondientes. A continuación, gcloud CLI escribe los tokens en un archivo kubeconfig. kubectl usa este archivo para autenticarse en el clúster de usuarios.

Para verificar que la autenticación se ha realizado correctamente, ejecuta cualquier comando kubectl con tu archivo kubeconfig:

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

gcloud tunnel

Si quieres autenticarte en un clúster de usuario desde una máquina remota, puedes hacerlo mediante un túnel SSH. Para usar un túnel, el archivo de configuración de autenticación debe estar en la máquina remota y debes poder acceder a tu proveedor de OpenID desde tu máquina local.

En tu máquina local, ejecuta el siguiente comando:

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Haz los cambios siguientes:

  • USERNAME con un usuario que tenga acceso SSH al equipo remoto.

  • REMOTE_MACHINE con el nombre de host o la dirección IP del equipo remoto.

  • LOCAL_PORT es un puerto disponible en tu máquina local que ssh usa para crear un túnel a la máquina remota.

  • REMOTE_PORT es el puerto que has configurado para tu URL de redirección de OIDC. El número de puerto forma parte del campo kubectlRedirectURI de tu archivo de configuración de autenticación.

En tu shell SSH, ejecuta el siguiente comando para iniciar la autenticación:

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

Sustituye AUTH_CONFIG_FILE por la ruta del archivo de configuración de autenticación en el equipo remoto. La CLI de gcloud ejecuta un servidor web en el equipo remoto.

En tu máquina local, abre un navegador, ve a http://localhost:LOCAL_PORT/login y sigue el flujo de inicio de sesión de OIDC.

El archivo kubeconfig de tu máquina remota ahora tiene el token para acceder al clúster de usuarios.

En tu shell SSH, comprueba que tienes acceso al clúster de usuarios:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Consola

Puedes autenticarte con la Google Cloud consola e iniciar el flujo de autenticación desde la página de clústeres de Kubernetes de la Google Cloud consola:

  1. Abre la Google Cloud consola:

    Visitar la página Clústeres de Kubernetes

  2. Busca tu clúster de GKE en AWS en la lista y haz clic en Iniciar sesión.

  3. Selecciona Autenticar con el proveedor de identidades configurado para el clúster y, a continuación, haz clic en INICIAR SESIÓN.

    Se te redirigirá a tu proveedor de identidades, donde es posible que tengas que iniciar sesión o dar tu consentimiento para que la consola acceda a tu cuenta. Google Cloud A continuación, se te redirigirá a la página Clústeres de Kubernetes de la consola de Google Cloud .

Actualizando la configuración de OIDC

Para actualizar la configuración de OIDC en tu clúster, usa el comando kubectl edit.

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

La herramienta kubectl carga el recurso ClientConfig en tu editor predeterminado. Para actualizar la configuración, guarda el archivo. La herramienta kubectl actualiza el recurso ClientConfig de tu clúster.

Para obtener información sobre el contenido del recurso ClientConfig, consulta la siguiente sección.

Apéndice: ejemplo de configuración de inicio de sesión

A continuación, se muestra un ejemplo kubectl-anthos-config.yaml. Este ejemplo se incluye para entender su contenido. Siempre debes generar el archivo con gcloud anthos create-login-config.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

Para obtener explicaciones sobre el contenido de los campos, consulta Campos de autenticación.

Siguientes pasos

Despliega tu primera carga de trabajo en GKE en AWS.