Autenticar con el servicio de identidad para GKE


En esta página, se explica cómo configurar un proveedor de identidad externo para autenticarse en clústeres de Google Kubernetes Engine (GKE).

Descripción general

El servicio de identidad para GKE extiende las soluciones de identidad existentes para la autenticación en tus clústeres de GKE. Gracias a la compatibilidad con OpenID Connect (OIDC), puedes administrar el acceso a los clústeres de Kubernetes mediante los procedimientos estándar de la organización para crear, habilitar e inhabilitar cuentas de usuario. El servicio de identidad para GKE se limita a los proveedores de identidad de OIDC.

Antes de comenzar

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

  • Los sistemas sin interfaz gráfica no son compatibles. Se usa un flujo de autenticación basado en el navegador para solicitar tu consentimiento y autorizar la cuenta de usuario.

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Asegúrate de que habilitaste la API de Google Kubernetes Engine.
  • Habilitar la API de Google Kubernetes Engine
  • Asegúrate de que instalaste el SDK de Cloud.
  • Establece la configuración predeterminada de la herramienta de línea de comandos de gcloud para tu proyecto mediante uno de los siguientes métodos:
    • Usa gcloud init si deseas ver una explicación sobre cómo configurar los valores predeterminados del proyecto.
    • Usa gcloud config para configurar el ID, la zona y la región del proyecto de manera individual.

    gcloud init

    1. Ejecuta gcloud init y sigue las instrucciones:

      gcloud init

      Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:

      gcloud init --console-only
    2. Sigue las instrucciones para autorizar a la herramienta de gcloud a usar tu cuenta de Google Cloud.
    3. Crea una configuración nueva o selecciona una existente.
    4. Elige un proyecto de Google Cloud.
    5. Elige una zona de Compute Engine predeterminada.
    6. Elige una región de Compute Engine predeterminada.

    gcloud config

    1. Establece tu ID del proyecto predeterminado:
      gcloud config set project PROJECT_ID
    2. Configura la región de Compute Engine predeterminada (por ejemplo, us-central1):
      gcloud config set compute/region COMPUTE_REGION
    3. Configura la zona de Compute Engine predeterminada (por ejemplo, us-central1-c):
      gcloud config set compute/zone COMPUTE_ZONE
    4. Actualiza gcloud a la versión más reciente:
      gcloud components update

    Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la herramienta gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Personas

En este tema, se hace referencia a dos perfiles:

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

Habilita el servicio de identidad para GKE en un clúster nuevo

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

De forma predeterminada, Identity and Access Management 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 el servicio de identidad para GKE durante la creación del clúster con la herramienta de línea de comandos de gcloud.

A fin de crear un clúster con el servicio de identidad para GKE habilitado mediante la herramienta de gcloud, ejecuta el siguiente comando:

gcloud beta container clusters create CLUSTER_NAME \
    --enable-identity-service

Reemplaza CLUSTER_NAME por el nombre de tu clúster nuevo.

Habilita el servicio de identidad para GKE en un clúster existente

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

Puedes habilitar el servicio de identidad para GKE en un clúster existente con la herramienta de línea de comandos de gcloud.

Cuando actualices el clúster, especifica la opción --enable-identity-service:

gcloud beta container clusters update CLUSTER_NAME \
    --enable-identity-service

Reemplaza CLUSTER_NAME por el nombre del clúster.

Configura el servicio de identidad para GKE en un clúster

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

La configuración del proveedor de identidad de GKE se controla a través de una CRD (definición de recursos personalizados) de Kubernetes, que contiene información como la configuración del proveedor de identidad, el método de autenticación preferido, y la asignación de reclamaciones de usuarios y grupos.

Se genera de forma automática un archivo de configuración ClientConfig llamado default para el clúster en el espacio de nombres kube-public.

  1. Descarga este archivo de configuración mediante la ejecución del siguiente comando:

    kubectl get clientconfig default -n kube-public -o yaml > login-config.yaml
    
  2. Actualiza el archivo de configuración ClientConfig descargado con la configuración de OIDC en la sección Spec.authentication.

    apiVersion: authentication.gke.io/v2alpha1
    kind: ClientConfig
    metadata:
    annotations:
      controller-gen.kubebuilder.io/version: v0.2.4
    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: CLOUD_CONSOLE_REDIRECT_URI
         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 OpenID.
    • OIDC_PROVIDER_CERTIFICATE: un certificado de codificación PEM codificada en base64 para el proveedor de OIDC (opcional). Este campo puede ser útil si tu proveedor de OIDC usa certificados autofirmados. El servicio de identidad para GKE incluye de forma predeterminada un conjunto de raíces públicas.
      • 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==
    • EXTRA_PARAMS: son 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.
    • ISSUER_URI: es 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 buscar claves públicas para la verificación de tokens. El URI debe usar HTTPS.
    • CLOUD_CONSOLE_REDIRECT_URI: es la URL de redireccionamiento de Cloud Console, por ejemplo, https://console.cloud.google.com/kubernetes/oidc
    • KUBECTL_REDIRECT_URL: es la URL de redireccionamiento que usa kubectl para la autorización.
    • SCOPES: son los permisos adicionales que se deben enviar al proveedor de OpenID. Microsoft Azure y Okta requieren el permiso offline_access.
    • 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 entidad emisora 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. Por ejemplo, https://example.com/adfs#123123123 en el que https://example.com/adfs es ISSUER_URI y 123123123 es tu reclamación del usuario desde el JWT. Google recomienda usar un prefijo; sin embargo, si deseas inhabilitar el prefijo, puedes configurar USER_PREFIX como -.
    • GROUP_PREFIX: es 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.
  3. Después de completar la configuración, ejecuta el siguiente comando para aplicarla:

    kubectl apply -f login-config.yaml
    

    Después de aplicar esta configuración, el servicio de identidad para GKE se ejecuta dentro del clúster y entrega solicitudes detrás de un balanceador de cargas de Google Cloud. Si el clúster está configurado con un extremo privado, el balanceador de cargas es interno. De lo contrario, el balanceador de cargas es externo y se puede acceder a él desde la Internet pública.

  4. Vuelve a actualizar 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. Para evitar subir el secreto del cliente a kube-apiserver, no vuelvas a ejecutar el comando kubectl apply a fin de aplicar la configuración.

  5. Distribuye el archivo login-config.yaml actualizado a tus desarrolladores y, luego, pídeles que coloquen el archivo de configuración en la ubicación adecuada para su plataforma.

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

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

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, los administradores deben otorgar funciones 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, supongamos que deseas que un usuario pueda ver todos los objetos secretos del clúster.

A continuación, se muestra un manifiesto para una ClusterRole con el nombre secret-viewer. Una persona a la que se le otorga esta función puede obtener, visualizar y enumerar cualquier Secreto 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"]

A continuación, se muestra un manifiesto para una ClusterRoleBinding con el nombre people-who-view-secrets. La vinculación otorga la función 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
  1. Reemplaza ISSUER_URI por el URI de la entidad emisora de spec.authentication.oidc.issuerURI en el archivo de configuración del cliente. Reemplaza USER por el identificador de usuario en el token en el nombre de la reclamación configurado en spec.authentication.oidc.userClaim en el archivo de configuración del cliente. Por ejemplo, https://example.com/adfs#123123123, en la que https://example.com/adfs es ISSUER_URI y 123123123 es tu identificador de usuario.

  2. Para crear la ClusterRole, guarda el manifiesto en un archivo llamado secret-viewer-cluster-role.yaml y ejecuta el siguiente comando:

    kubectl apply -f secret-viewer-cluster-role.yaml
    
  3. Para crear la ClusterRoleBinding, guarda el manifiesto en un archivo llamado secret-viewer-cluster-role-binding.yaml y ejecuta el siguiente comando:

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

Accede al clúster y autentica en el clúster

Esta sección está destinada a los desarrolladores.

Ahora que tienes el archivo de configuración de autenticación de tu administrador, puedes autenticarte en tus clústeres.

  1. Descarga el archivo login-config.yaml que proporcionó el administrador y colócalo en la ubicación correcta de tu plataforma.

  2. Instala el SDK de SDK de Cloud, que ofrece un componente de OIDC independiente. Para instalarlo, puedes ejecutar el siguiente comando:

    gcloud components install kubectl-oidc
    
  3. Ejecuta el siguiente comando para autenticarte en el 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.

  4. Después de la autenticación, puedes ejecutar comandos de kubectl, por ejemplo:

    kubectl get pods
    

Inhabilita el servicio de identidad para GKE

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

Puedes inhabilitar el servicio de identidad para GKE con la herramienta de línea de comandos de gcloud. A fin de inhabilitar el servicio de identidad para GKE, especifica la opción --no-enable-identity-service:

gcloud beta container clusters update CLUSTER_NAME --no-enable-identity-service

¿Qué sigue?