Autentica con OpenID Connect (OIDC)

Obtén información sobre cómo configurar GKE on AWS de modo que use OpenID Connect (OIDC) para la autenticación en clústeres de usuarios. En este tema, se abarca el proceso para configurar GKE on AWS con cualquier proveedor de OpenID.

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

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

Descripción general

GKE en AWS admite OIDC como uno de los mecanismos de autenticación para interactuar con el servidor de API de Kubernetes de un clúster de usuario. Con OIDC, puedes administrar el acceso a los clústeres de Kubernetes mediante los procedimientos estándar de la organización para la creación, la habilitación y la inhabilitación de cuentas de usuario.

Antes de comenzar

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

  • Google Cloud CLI debe instalarse en la máquina local de cada desarrollador.

  • Los sistemas sin interfaz gráfica no son compatibles. Para autenticarte, debes abrir un navegador en la máquina local que ejecuta la CLI de gcloud. A continuación, el navegador te solicita que autorices tu cuenta de usuario.

  • Si quieres realizar la autenticación a través de la consola de Google Cloud, cada clúster que desees configurar para la autenticación de OIDC debe estar registrado en Google Cloud.

Personas

En este tema, se hace referencia a tres personas:

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

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

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

Elige un proveedor de OpenID

Esta sección está destinada a los administradores de la organización.

Puedes usar el proveedor de OpenID que desees. Para ver una lista de proveedores certificados, consulta OpenID Certification (Certificación de OpenID).

Crea URL de redireccionamiento

Esta sección está destinada a los administradores de la organización.

El proveedor de OpenID usa URL de redireccionamiento para mostrar tokens de ID. Debes crear URLs de redireccionamiento para gcloud CLI y la consola de Google Cloud.

Configura la URL de redireccionamiento de la CLI de gcloud

Cuando configures el proveedor de OpenID, especifica la URL de redireccionamiento de la CLI como http://localhost:PORT/callback.

Reemplaza PORT por el número de puerto mayor que 1024.

Configura la URL de redireccionamiento de la consola de Google Cloud

La URL de redireccionamiento de la consola de Google Cloud es la siguiente:

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

Cuando configures el proveedor de OIDC, especifica https://console.cloud.google.com/kubernetes/oidc como una de tus URL de redireccionamiento.

Registra las aplicaciones cliente con el proveedor de OpenID

Esta sección está destinada a los administradores de la organización.

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

  • Obtén más información sobre el URI de la entidad emisora del proveedor. gcloud CLI o la consola de Google Cloud envía solicitudes de autenticación a este URI.

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

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

  • Crea un ID de cliente único que tu proveedor usará para identificar Google Cloud CLI y la consola de Google Cloud.

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

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

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

Configura tu clúster

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

Para configurar la autenticación de OIDC, necesitas configurar el recurso de AWSCluster del clúster de usuario con detalles de autenticación para un clúster. Los detalles de AWSCluster se usan a fin de configurar OIDC para la consola de Google Cloud y el complemento de autenticación para GKE Enterprise. 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 se configura OIDC. El nombre del recurso de Amazon (ARN) de las identidades de AWS IAM (usuarios o funciones) a los que GKE on AWS otorgó acceso de administrador de clústeres. Ejemplo: arn:aws:iam::123456789012:group/Developers String
Campo Obligatorio Descripción Formato
certificateAuthorityData No Un certificado con codificación PEM codificada en base64 para el proveedor de OIDC. Para crear la string, codifica el certificado, incluidos los encabezados, en base64. Incluye la string resultante en certificateAuthorityData como una sola línea. Ejemplo: certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT== String
clientID Sí El ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de OpenID. String
clientSecret No Un secreto compartido entre la aplicación cliente de OIDC y el proveedor de OIDC. String
extraParams No Los parámetros de clave-valor adicionales para enviar al proveedor de OpenID. Si autorizas un grupo, pasa resource=token-groups-claim.

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

Lista delimitada por comas
groupsClaim No La reclamación de JWT que el proveedor usa para mostrar los grupos de seguridad. String
groupPrefix No 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 y agregas un prefijo gid-, el grupo resultante es gid-foobar. String
issuerURI Sí La URL a la que se envían las solicitudes de autorización al OpenID, como https://example.com/adfs. El servidor de la API de Kubernetes usa esta URL a fin de descubrir claves públicas para la verificación de tokens. El URI debe usar HTTPS. String de URL
kubectlRedirectURI Sí La URL de redireccionamiento que usa “kubectl” para la autorización. String de URL
scopes Sí Los permisos adicionales que se deben enviar al proveedor de OpenID. Microsoft Azure y Okta requieren el permiso offline_access. Lista delimitada por comas
userClaim No Es la reclamación de JWT que se debe usar como nombre de usuario. Puedes elegir otras reclamaciones, como el correo electrónico o el nombre, según el proveedor de OpenID. Sin embargo, las reclamaciones que no sean de correo electrónico tienen el prefijo de la URL de la entidad emisora para evitar conflictos de nombres. String
userPrefix No El prefijo que se antepone a las reclamaciones de nombre de usuario para evitar conflictos con los nombres existentes. String

Ejemplo: Autoriza usuarios y grupos

Muchos proveedores codifican las propiedades de identificación de los usuarios, como el correo electrónico y los ID de usuario, en un token. Sin embargo, estas propiedades tienen riesgos implícitos para las políticas de autenticación:

  • Los ID de usuario pueden dificultar la lectura y la auditoría de las políticas.
  • Usar direcciones de correo electrónico puede crear un riesgo de disponibilidad (si un usuario cambia su correo electrónico principal) y un riesgo de seguridad (si se puede reasignar uno).

En lugar de asignar el ID de usuario, se recomiendan las 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']
  ...
}

En este formato de token, deberías propagar la especificación oidc del 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'
...

Después de crear el clúster de usuario, usa el control de acceso basado en funciones (RBAC) de Kubernetes para otorgar acceso con privilegios a los usuarios autenticados.

En el siguiente ejemplo, debes crear una ClusterRole que otorga a sus usuarios acceso de solo lectura a los Secretos del clúster y crea un recurso ClusterRoleBinding para vincular la función al grupo autenticado.

  1. Define una ClusterRole. Copia el siguiente 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 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 otorgó acceso en read-secrets-admins ahora tienen acceso para leer Secretos en tu clúster.

Crea una configuración de acceso

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

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

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

    cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
    Reemplaza 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

    Reemplaza usercluster-kubeconfig por la ruta de acceso al archivo kubeconfig de tu clúster de usuario. En Linux y macOS, de forma predeterminada, este archivo se encuentra 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.

Distribuye el archivo de configuración de acceso

Distribuye el archivo de configuración a los usuarios que necesitan autenticarse en tus clústeres de usuario. Puedes distribuir el archivo de configuración de las siguientes maneras:

  • Coloca el archivo en el directorio predeterminado.
  • Distribuye el archivo de manera segura.
  • Aloja el archivo en un servidor HTTPS.

Directorios predeterminados de los archivos de configuración de acceso

Las ubicaciones predeterminadas de almacenamiento del archivo de configuración para cada SO son las siguientes:

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

Una vez que se distribuyó el archivo de configuración de acceso, los desarrolladores están listos para configurar la CLI de gcloud a fin de acceder al clúster.

Modifica tu clúster después de actualizar a Kubernetes 1.21

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

  1. Sigue los pasos en Actualiza tu clúster.

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

    cd anthos-aws
env HTTPS_PROXY=http://localhost:8118 \
  anthos-gke aws clusters get-credentials CLUSTER_NAME
    Reemplaza 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 a fin de seguir los pasos en Configura clústeres para GKE Identity Service.

  4. Desde tu directorio de anthos-aws, usa anthos-gke para cambiar el contexto a tu servicio administrado. 

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

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

    Edita YAML

    Si seguiste las instrucciones en Crea un clúster de usuario, el archivo YAML se llama cluster-0.yaml. Abre este archivo en un editor de texto.

    Edita mediante kubectl

    Para usar kubectl edit a fin de editar el AWSCluster, ejecuta el siguiente comando:

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

    Reemplaza cluster-name por el 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. Borra el objeto oidc del manifiesto del clúster.

  7. Guarde el archivo. Si usas kubectl edit, kubectl aplica los cambios de forma automática. Si editas el archivo YAML, aplícalo al servicio de administración mediante el siguiente comando:

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

    Luego, el servicio de administración actualiza el AWSCluster.

Configura gcloud para acceder a tu clúster

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

Requisitos

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

  • Un archivo de configuración de acceso

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

    gcloud components update
gcloud components install anthos-auth

  • Verifica que la CLI de gcloud se haya instalado con éxito mediante la ejecución del siguiente comando, que debería dar como resultado detalles sobre los argumentos necesarios y las opciones disponibles

    gcloud anthos auth

Autentícate en tu clúster

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

  • 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 Connect en la consola de Google Cloud.

gcloud local

Usa gcloud anthos auth login para autenticarte en el clúster con tu archivo de configuración de acceso.

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

Predeterminada

gcloud anthos auth login --cluster CLUSTER_NAME

Reemplaza CLUSTER_NAME por un nombre de clúster completamente calificado. 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 Es el nombre del clúster para autenticar. La configuración predeterminada es el clúster en “kubectl-anthos-config.yaml”.
user Es el nombre de usuario de las credenciales en kubeconfig. La configuración predeterminada es {cluster-name}-anthos-default-user.
login-config Es la ruta de acceso al archivo de configuración que genera el administrador del clúster para el desarrollador o una URL que aloja el archivo. La configuración predeterminada es kubectl-anthos-config.yaml.
login-config-cert Si usas una URL para login-config, es la ruta de acceso al archivo del certificado de CA a fin de realizar conexiones HTTPS.
kubeconfig Es la ruta de acceso al archivo kubeconfig que contiene los tokens. La configuración predeterminada es $HOME/.kube/config`.
dry-run Prueba las opciones de la línea de comandos sin cambiar la configuración o el clúster.

El comando gcloud anthos login inicia un navegador que le pide al usuario que acceda con sus credenciales empresariales, realiza el intercambio de credenciales de OIDC y adquiere los tokens pertinentes. Luego, la CLI de gcloud escribe los tokens en un archivo kubeconfig. kubectl usa este archivo para autenticarse en el clúster de usuario.

Para verificar que la autenticación se realizó con éxito, ejecuta cualquier comando de kubectl con tu archivo kubeconfig:

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

túnel de gcloud

Si deseas autenticarte en un clúster de usuario desde una máquina remota, puedes realizar la autenticación con un túnel SSH. Para usar un túnel, tu archivo de configuración de autenticación debe estar en la máquina remota y debes poder alcanzar tu proveedor de ID abierto desde tu máquina local.

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

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Reemplaza lo siguiente:

  • USERNAME por un usuario que tenga acceso SSH a la máquina remota.

  • REMOTE_MACHINE por el nombre de host o la dirección IP de la máquina remota.

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

  • REMOTE_PORT es el puerto que configuraste para la URL de redireccionamiento de OIDC. El número de puerto es parte del campo kubectlRedirectURI del archivo de configuración de autenticación.

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

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

Reemplaza AUTH_CONFIG_FILE por la ruta de acceso de tu archivo de configuración de autenticación en la máquina remota. La CLI de gcloud ejecuta un servidor web en la máquina remota.

En un navegador de la máquina local, ve a http://localhost:LOCAL_PORT/login y completa el flujo de acceso de OIDC.

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

En la shell con SSH, verifica que tengas acceso al clúster de usuario:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Console

Puedes autenticar con la consola de Google Cloud para iniciar el flujo de autenticación desde la página Clústeres de Kubernetes en la consola de Google Cloud:

  1. Abre la consola de Google Cloud:

    Visitar la página Clústeres de Kubernetes

  2. Localiza el clúster de GKE en AWS en la lista y haz clic en Acceder.

  3. Selecciona Authenticate with the Identity Provider configured for the cluster y, luego, haz clic en ACCEDER.

    Se te redireccionará al proveedor de identidad, en el que es posible que debas acceder u otorgar consentimiento a la consola de Google Cloud para que acceda a tu cuenta. Luego, se te redireccionará a la página Clústeres de Kubernetes de la consola de Google Cloud.

Actualiza 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 en tu clúster.

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

Apéndice: Configuración de acceso de ejemplo

Sigue un ejemplo de kubectl-anthos-config.yaml. Este ejemplo se incluye para que obtengas información sobre 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 del campo, consulta Campos de autenticación.

¿Qué sigue?

Implementa la primera carga de trabajo en GKE en AWS.