Autenticación con OpenID Connect (OIDC)

Aprenda a configurar GKE en AWS para usar OpenID Connect (OIDC) para la autenticación en clústeres de usuarios. Este tema explica el proceso para configurar GKE en AWS con cualquier proveedor de OpenID.

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

Para obtener una descripción general del flujo de autenticación de GKE en AWS, consulte 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 usuarios. Con OIDC, puede administrar el acceso a los clústeres de Kubernetes mediante los procedimientos estándar de su organización para crear, habilitar y deshabilitar cuentas de usuario.

Antes de empezar

• Este tema asume que está familiarizado con los siguientes conceptos de autenticación y OpenID:

  • OAuth 2.0
  • Conexión OpenID
  • alcances
  • reclamos

• La CLI de Google Cloud debe estar instalada en la máquina local de cada desarrollador.

• Los sistemas sin interfaz gráfica no son compatibles. Para autenticarse, debe abrir un navegador en el equipo local que ejecuta la CLI de gcloud. El navegador le solicitará que autorice su cuenta de usuario.

• Para autenticarse a través de la Google Cloud consola, cada clúster que desee configurar para la autenticación OIDC debe estar registrado con Google Cloud .

Personas

Este tema se refiere a tres personajes:

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

• Administrador de clúster : esta persona crea uno o más clústeres de usuarios y crea archivos de configuración de autenticación para los desarrolladores que utilizan los clústeres.

• Desarrollador : esta persona ejecuta cargas de trabajo en uno o más clústeres y utiliza OIDC para autenticarse.

Elija un proveedor de OpenID

Esta sección es para administradores de la organización .

Puede usar cualquier proveedor de OpenID que prefiera. Para ver una lista de proveedores certificados, consulte Certificación OpenID .

Crear URL de redireccionamiento

Esta sección es para administradores de la organización .

El proveedor de OpenID utiliza URL de redirección para devolver tokens de ID. Debe crear URL de redirección tanto para la CLI de gcloud como paraGoogle Cloud consola.

Establecer la URL de redirección de la CLI de gcloud

Cuando configure su proveedor OpenID, especifique su URL de redireccionamiento CLI como http://localhost: PORT /callback

Reemplace PORT con su número de puerto mayor a 1024.

Establezca el Google Cloud URL de redirección de la consola

La URL de redireccionamiento para el Google Cloud La consola es:

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

Cuando configure su proveedor OIDC, especifique https://console.cloud.google.com/kubernetes/oidc como una de sus URL de redireccionamiento.

Registre sus aplicaciones cliente con el proveedor OpenID

Esta sección es para administradores de la organización .

Antes de que sus desarrolladores puedan usar la CLI de Google Cloud o la Google Cloud Para conectar la consola con su proveedor de OpenID, debe registrar esos dos clientes con dicho proveedor. El registro incluye los siguientes pasos:

• Conozca la URI del emisor de su proveedor. La CLI de gcloud oGoogle Cloud La consola envía solicitudes de autenticación a esta URI.

• Configure su proveedor con la URL de redireccionamiento, incluido su número de puerto, para la CLI de gcloud.

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

• Cree un único ID de cliente que su proveedor utilice para identificar tanto la CLI de Google Cloud como laGoogle Cloud consola.

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

• Cree un ámbito personalizado que la CLI de gcloud o Google Cloud La consola se puede utilizar para solicitar los grupos de seguridad del usuario.

• Crea un nombre de reclamo personalizado que el proveedor utiliza para devolver los grupos de seguridad del usuario.

Configurar su clúster

Esta sección es para administradores de clúster .

Para configurar la autenticación OIDC, debe configurar el recurso AWSCluster de su clúster de usuarios con los detalles de autenticación para un clúster. Los detalles de AWSCluster se utilizan para configurar OIDC tanto para el Google Cloud Consola 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

La siguiente tabla describe los campos del objeto authentication.awsIAM.adminIdentityARNs .

Ejemplo: Autorización de usuarios y grupos

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

• Los identificadores de usuario pueden dificultar la lectura y auditoría de las políticas.
• El uso de 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 un correo electrónico).

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

Supongamos que su 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']
  ...
}

Dado este formato de token, deberá completar la especificación oidc de su 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 haber creado su clúster de usuarios, utilice el control de acceso basado en roles (RBAC) de Kubernetes para otorgar acceso privilegiado a los usuarios autenticados.

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

1. Define un 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. Aplique secret-reader-role.yaml y secret-reader-admins.yaml a su 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 otorga acceso en read-secrets-admins ahora tienen acceso para leer secretos en su clúster.

Crear una configuración de inicio de sesión

Esta sección es para administradores de clúster .

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

1. Desde su directorio anthos-aws , use anthos-gke para cambiar el contexto a su clúster de usuarios.

   cd anthos-aws
   env HTTPS_PROXY=http://localhost:8118 \
     anthos-gke aws clusters get-credentials CLUSTER_NAME

   Reemplace CLUSTER_NAME con el nombre de su clúster de usuarios.

2. Crea la configuración con gcloud anthos .

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

   Reemplace usercluster-kubeconfig con la ruta del archivo kubeconfig de su clúster de usuarios. 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 los desarrolladores usan para autenticarse en el clúster con la CLI de gcloud. No debe modificar este archivo.

Para comprender más sobre el contenido de kubectl-anthos-config.yaml , consulte el apéndice .

Distribuir la configuración de inicio de sesión

Distribuya el archivo de configuración a los usuarios que necesiten autenticarse en sus clústeres. Puede distribuir la configuración de la siguiente manera:

• 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 para cada sistema operativo son las siguientes:

Linux

$HOME/.config/google/anthos/kubectl-anthos-config.yaml , donde $HOME es el directorio de inicio del usuario.

macOS

$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml , donde $HOME es el directorio de inicio del usuario.

Ventanas

%APPDATA%/google/anthos/kubectl-anthos-config.yaml , donde %APPDATA% es el directorio de datos de la aplicación del usuario.

Una vez distribuida la configuración de inicio de sesión, los desarrolladores están listos para configurar la CLI de gcloud para acceder al clúster.

Modifique su clúster después de actualizar a Kubernetes 1.21

Después de actualizar su clúster a Kubernetes 1.21, debe configurar el Servicio de Identidad de GKE y eliminar la información de OIDC de la configuración del clúster. Para actualizar la configuración, siga estos pasos:

1. Siga los pasos que se indican en Actualizar su clúster .

2. Desde su directorio anthos-aws , use anthos-gke para cambiar el contexto a su clúster de usuarios.

   cd anthos-aws
   env HTTPS_PROXY=http://localhost:8118 \
     anthos-gke aws clusters get-credentials CLUSTER_NAME

   Reemplace CLUSTER_NAME con el nombre de su clúster de usuarios.

3. Abra el manifiesto que contiene el clúster de AWS en un editor de texto. Mantenga el archivo abierto y use los valores del objeto oidc para seguir los pasos de la sección "Configuración de clústeres para el Servicio de Identidad de GKE" .

4. Desde su directorio anthos-aws , use anthos-gke para cambiar el contexto a su servicio de administración.

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

5. Abra el archivo YAML que creó su AWSCluster en un editor de texto. Si no tiene el archivo YAML inicial, puede usar kubectl edit .

   Editar YAML

   Si siguió las instrucciones de "Crear un clúster de usuarios" , su archivo YAML se llamará cluster-0.yaml . Abra este archivo en un editor de texto.

   edición de kubectl

   Para usar kubectl edit para editar su AWSCluster, ejecute el siguiente comando:

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

   Reemplace cluster-name por su clúster de AWS. Por ejemplo, para editar el clúster predeterminado, cluster-0 , ejecute 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. Guarde el archivo. Si usa kubectl edit , kubectl aplicará los cambios automáticamente. Si edita el archivo YAML, aplíquelo a su servicio de administración con el siguiente comando:

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

   A continuación, el servicio de administración actualiza su AWSCluster.

Configurar gcloud para acceder a su clúster

Esta sección es para desarrolladores o administradores de clúster .

Prerrequisitos

Para completar esta sección, deberá completar lo siguiente:

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

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

  gcloud components update
  gcloud components install anthos-auth
  

• Verifique que la CLI de gcloud se haya instalado correctamente ejecutando el siguiente comando, que debería responder con detalles sobre los argumentos requeridos y las opciones disponibles.

  gcloud anthos auth
  

Autenticarse en su clúster

Puede autenticarse en su clúster de las siguientes maneras:

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

• Con Connect en el Google Cloud consola.

gcloud anthos auth login --cluster CLUSTER_NAME

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

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

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Actualización de la configuración de OIDC

Para actualizar la configuración de OIDC en su clúster, utilice 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 su editor predeterminado. Para actualizar la configuración, guarde el archivo. La herramienta kubectl actualiza el recurso ClientConfig en su clúster.

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

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

A continuación se muestra un ejemplo de kubectl-anthos-config.yaml . Este ejemplo se incluye para comprender su contenido. Siempre debe 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, consulte Campos de autenticación .

¿Qué sigue?

Implemente su primera carga de trabajo en GKE en AWS.