Configura la puerta de enlace de Connect con identidades de terceros

Esta guía está dirigida a los administradores de la plataforma que necesitan configurar la puerta de enlace de Connect en un proyecto que contiene usuarios que no tienen identidades de Google y no pertenecen a Google Workspace. En esta guía, estas identidades se denominan “identidades de terceros”. Antes de leer esta guía, debes familiarizarte con los conceptos de la descripción general de la puerta de enlace de Connect. Para autorizar cuentas de Google individuales, consulta Configura la puerta de enlace de Connect. Para obtener asistencia sobre los Grupos de Google, consulta Configura la puerta de enlace de Connect con Grupos de Google.

La configuración de esta guía permite a los usuarios acceder a clústeres de flotas con la Google Cloud CLI, la puerta de enlace de Connect y la consola de Google Cloud.

Tipos de clústeres compatibles

Puedes configurar el control de acceso con identidades de terceros usando la puerta de enlace de Connect para los siguientes tipos de clústeres registrados:

• Clústeres de GKE
• GKE en VMware y GKE on Bare Metal desde Anthos (GKE Enterprise) 1.13 y versiones posteriores
• GKE en AWS y GKE en Azure desde la versión 1.25 de Kubernetes y versiones posteriores.
• Clústeres conectados desde Anthos (GKE Enterprise) 1.16 y versiones posteriores.

Si necesitas actualizar los clústeres locales para usar esta función, consulta Actualiza los clústeres de GKE Enterprise para VMWare y Actualiza los clústeres de GKE Enterprise en Bare Metal.

Si tienes un caso de uso para entornos de clústeres de GKE que no sean los ya mencionados, comunícate con la Atención al cliente de Cloud o con el equipo de la puerta de enlace de Connect.

Cómo funciona

Como se describe en la descripción general, es posible que los usuarios usen proveedores de identidad que no sean Google Workspace ni Cloud Identity. Mediante la federación de identidades del personal, los usuarios pueden usar sus proveedores de identidad de terceros, como Okta o Azure Active Directory, para acceder a sus clústeres a través de la puerta de enlace de Connect. A diferencia de las cuentas de Google, los usuarios de terceros están representados por una principal de administración de identidades y accesos (IAM) que sigue este formato:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE

• WORKFORCE_POOL_ID es el nombre del grupo de personal que contiene el proveedor de identidad de terceros relevante.

• El SUBJECT_VALUE es la asignación de la identidad de terceros a un sujeto de Google.

Para los grupos de terceros, la principal de IAM sigue el siguiente formato:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_VALUE

En el siguiente diagrama, se muestra un flujo típico de un usuario de terceros que se autentica y ejecuta comandos en un clúster con este servicio habilitado. Para que este flujo sea exitoso, se debe aplicar una política de control de acceso basado en roles (RBAC) en el clúster, ya sea para el usuario o un grupo.

Para los usuarios individuales, debe existir una política de RBAC que use el nombre principal de IAM completo del usuario en el clúster.

Si se usa la funcionalidad de grupo, debe existir una política de RBAC que use el nombre principal de IAM completo en el clúster para un grupo que haga lo siguiente:

1. Contiene al usuario [e-mail] como miembro.

2. Se incluye en la asignación de un proveedor de identidad dentro de un grupo de trabajadores que se encuentra en la organización de Google Cloud de Alice.

Nota: GKE Identity Service se debe configurar para que funcione la funcionalidad de grupos de terceros. en clústeres miembros de la flota fuera de Google Cloud.

1. El usuario [e-mail] accede a gcloud con su identidad de terceros mediante el acceso basado en el navegador de terceros. Para usar el clúster desde la línea de comandos, el usuario obtiene la puerta de enlace del clúster kubeconfig, como se describe en Usa la puerta de enlace de Connect.
2. El usuario envía una solicitud a través de la ejecución de un comando kubectl o la apertura de las páginas Cargas de trabajo o Navegador de objetos de Google Kubernetes Engine en la consola de Google Cloud.
3. La puerta de enlace de Connect, que controla la autenticación de terceros mediante la federación de identidades de personal, recibe la solicitud.
4. La puerta de enlace de Connect realiza una verificación de autorización con IAM.
5. El servicio de Connect reenvía la solicitud al agente de Connect que se ejecuta en el clúster. La solicitud incluye la información de la credencial del usuario para usarla en la autenticación y la autorización del clúster.
6. El agente de Connect reenvía la solicitud al servidor de la API de Kubernetes.
7. El servidor de la API de Kubernetes reenvía la solicitud a GKE Identity Service, que la valida.
8. GKE Identity Service muestra la información del usuario y el grupo de terceros al servidor de la API de Kubernetes. El servidor de la API de Kubernetes puede usar esta información para autorizar la solicitud en función de las políticas de RBAC configuradas del clúster.

Antes de comenzar

• Asegúrate de tener instaladas las siguientes herramientas de línea de comandos:

  • La versión más reciente de Google Cloud CLI, la herramienta de línea de comandos para interactuar con Google Cloud.
  • La herramienta de línea de comandos de Kubernetes, kubectl, para interactuar con tus clústeres.

  Si usas Cloud Shell como entorno de shell para interactuar con Google Cloud, estas herramientas están instaladas.

• Asegúrate de haber inicializado la CLI de gcloud para usarla en tu proyecto.

• En esta guía, se supone que tienes roles/owner en tu proyecto. Si no eres propietario de un proyecto, es posible que necesites permisos adicionales para realizar algunos de los pasos de configuración.

• Para los clústeres fuera de Google Cloud, GKE Identity Service necesita llamar a las APIs de Google desde tu clúster para completar la autenticación. Verifica si tu política de red requiere que el tráfico saliente pase por un proxy.

Configura asignaciones de atributos de identidad de terceros con Workforce Identity

Asegúrate de que haya un grupo de trabajadores y un proveedor de identidad configurados para tu organización de Google Cloud. Para ello, sigue las instrucciones correspondientes a tu proveedor de identidad:

• Azure AD
• Okta
• Otro OIDC o SAML 2.0

Nota: Existe un límite de asignación de atributos de 4 kilobytes, que incluye grupos, para cada proveedor de identidad.

Habilita las APIs

Para agregar la puerta de enlace al proyecto, habilita la API de puerta de enlace de Connect y las API de dependencia requeridas. Si tus usuarios solo desean autenticarse en los clústeres mediante la consola de Google Cloud, no necesitas habilitar connectgateway.googleapis.com, pero sí debes habilitar las API restantes.

gcloud services enable --project=PROJECT_ID  \
connectgateway.googleapis.com \
anthos.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com

Nota:Si no eres propietario de un proyecto, debes tener el permiso serviceusage.services.enable para poder habilitar las APIs en tu proyecto.

Configura GKE Identity Service

La función de asistencia de identidad de terceros de la puerta de enlace de Connect usa GKE Identity Service para obtener información de pertenencia a un grupo de terceros de Google. Puedes obtener más información sobre GKE Identity Service en Introducción a GKE Identity Service.

Asegúrate de que GKE Identity Service esté instalado

GKE Identity Service se instala de forma predeterminada en los clústeres de GKE a partir de la versión 1.7 (aunque la asistencia de identidad de terceros requiere la versión 1.13 o una posterior). Para confirmar que esté instalado correctamente en tu clúster, ejecuta el siguiente comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG get all -n anthos-identity-service

Reemplaza CLUSTER_KUBECONFIG por la ruta de acceso al kubeconfig del clúster.

Configura la compatibilidad de identidad de terceros para grupos

Si tu clúster o flota ya está configurado para la asistencia de Grupos de Google, no hay pasos adicionales y puedes pasar a Otorga roles de IAM a usuarios y grupos de terceros.

Si usas Google Distributed Cloud en VMware o Bare Metal, la forma en que configuras GKE Identity Service determina cómo necesitas configurar la función de grupos de terceros.

Si usas GKE Identity Service por primera vez, puedes elegir entre configurar la asistencia de grupos de terceros mediante las APIs de Fleet (recomendado) o mediante kubectl.

Si no es la primera vez que usas GKE Identity Service, ten en cuenta una de las siguientes opciones:

• Si ya configuraste GKE Identity Service para otro proveedor de identidad a nivel de la flota, la función de grupos de terceros está habilitada de forma predeterminada. Consulta la sección Flota que se encuentra a continuación para obtener más detalles y cualquier configuración adicional que puedas necesitar.

• Si ya configuraste GKE Identity Service para otro proveedor de identidad por clúster, consulta la sección Kubectl a continuación para obtener instrucciones sobre cómo actualizar la configuración para el tercero de grupos.

Flota

Puedes usar la consola de Google Cloud o la línea de comandos para configurar el acceso a grupos de terceros mediante las APIs de funciones de flotas.

Console

Si no configuraste GKE Identity Service para una flota, sigue las instrucciones en Configura clústeres para GKE Identity Service.

Selecciona los clústeres y actualiza la configuración

1. En la consola de Google Cloud, ve a la página Administrador de funciones.

   Ir a Administrador de funciones

2. Haz clic en Detalles en el panel Servicio de identidad. Se muestran los detalles del clúster de tu proyecto.

3. Haz clic en Actualizar el servicio de identidad para abrir el panel de configuración.

4. Selecciona los clústeres que deseas configurar. Puedes elegir clústeres individuales o especificar que deseas que todos los clústeres se configuren con la misma configuración de identidad.

5. En la sección Configure Identity Providers, puedes optar por retener, agregar, actualizar o quitar un proveedor de identidad.

6. Haz clic en Continuar para ir al siguiente paso de configuración. Si seleccionaste al menos un clúster apto para esta configuración, se mostrará la sección Google Authentication.

7. Selecciona Habilitar para habilitar la autenticación de Google en los clústeres seleccionados. Si necesitas acceder al proveedor de identidad de Google a través de un proxy, ingresa los detalles del proxy.

8. Haz clic en Actualizar configuración. Esto aplica la configuración de identidad en los clústeres seleccionados.

gcloud

Si no configuraste GKE Identity Service para una flota, sigue las instrucciones en Configura clústeres para GKE Identity Service. Especifica solo la siguiente configuración en tu archivo auth-config.yaml:

spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false

Configura el acceso a grupos de terceros con un proxy

Si necesitas acceder al proveedor de identidad con un proxy, usa un campo proxy en el archivo auth-config.yaml. Es posible que debas configurarlo si, por ejemplo, tu clúster está en una red privada y necesita conectarse a un proveedor de identidad pública. Debes agregar esta configuración incluso si ya configuraste GKE Identity Service para otro proveedor.

Para configurar proxy, así es como puedes actualizar la sección authentication del archivo de configuración existente auth-config.yaml.

  spec:
    authentication:
    - name: authentication-method
      google:
        disable: false
      proxy: PROXY_URL

donde

• disable (opcional) denota si quieres habilitar o inhabilitar la función de grupos de terceros para los clústeres. Este valor se establece en falso de forma predeterminada. Si deseas inhabilitar esta función, puedes establecerla como verdadero.

• PROXY_URL es la dirección del servidor proxy para conectarse a la identidad de Google (opcional). Por ejemplo: http://user:password@10.10.10.10:8888.

Aplica la configuración

Para aplicar la configuración a un clúster, ejecuta el siguiente comando:

gcloud container fleet identity-service apply \
--membership=CLUSTER_NAME \
--config=/path/to/auth-config.yaml

donde

CLUSTER_NAME es el nombre de membresía único del clúster dentro de la flota.

Una vez aplicada, el controlador de GKE Identity Service administra esta configuración. El controlador concilia todos los cambios locales realizados en la configuración del cliente de GKE Identity Service con la configuración especificada en esta configuración.

Kubectl

Si deseas configurar tu clúster para usar GKE Identity Service con la función de grupos de terceros, debes actualizar el ClientConfig de GKE Identity Service del clúster. Este es un tipo de recurso personalizado (CRD) de Kubernetes que se usa para la configuración del clúster. Cada clúster de GKE Enterprise tiene un recurso ClientConfig llamado default en el espacio de nombres kube-public que se actualiza con los detalles de la configuración.

Para editar la configuración, usa el siguiente comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Si hay varios contextos en kubeconfig, se usa el contexto actual. Es posible que debas restablecer el contexto actual en el clúster correcto antes de ejecutar el comando.

Este es un ejemplo de cómo puedes actualizar el ClientConfig con un método de autenticación nuevo que tiene una configuración de tipo google para habilitar la función de grupos de terceros. Si el campo internalServer está vacío, asegúrate de que esté configurado como https://kubernetes.default.svc, como se muestra a continuación.

spec:
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method
    proxy: PROXY_URL
  internalServer: https://kubernetes.default.svc

donde

CLUSTER_IDENTIFIER denota los detalles de la membresía del clúster (obligatorio). Puedes recuperar los detalles de la membresía del clúster a través del siguiente comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG get memberships membership -o yaml

donde

CLUSTER_KUBECONFIG es la ruta al archivo kubeconfig del clúster. En la respuesta, consulta el campo spec.owner.id para recuperar los detalles de la membresía del clúster.

Esta es una respuesta de ejemplo que muestra los detalles de la membresía de un clúster:

id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef

que corresponde al siguiente formato: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP

Otorga roles de IAM a usuarios y grupos de terceros

Las identidades de terceros necesitan los siguientes roles adicionales de Google Cloud para interactuar con los clústeres conectados a través de la puerta de enlace:

• roles/gkehub.gatewayAdmin. Esta función permite que los usuarios accedan a la API de la puerta de enlace de Connect.
  • Si los usuarios necesitan acceso de solo lectura a clústeres conectados, se puede usar roles/gkehub.gatewayReader en su lugar.
  • Si los usuarios necesitan acceso de lectura/escritura a clústeres conectados, se puede usar roles/gkehub.gatewayEditor en su lugar.
• roles/gkehub.viewer. Este rol permite a los usuarios ver las membresías registradas a los clústeres.

A continuación, se muestra cómo agregar los roles necesarios a las identidades individuales y los grupos asignados:

Identidades individuales

Para otorgar los roles necesarios a una sola identidad para el proyecto PROJECT_ID, ejecuta el siguiente comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

donde

• PROJECT_ID: es el ID del proyecto.
• GATEWAY_ROLE es uno de roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o gkehub.gatewayEditor.
• WORKFORCE_POOL_ID: es el ID del grupo de identidades de personal.
• SUBJECT_VALUE: es la identidad del usuario.

Grupos

Para otorgar los roles necesarios a todas las identidades dentro de un grupo específico para el proyecto PROJECT_ID, ejecuta el siguiente comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

donde

• PROJECT_ID: es el ID del proyecto.
• GATEWAY_ROLE es uno de roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o gkehub.gatewayEditor.
• WORKFORCE_POOL_ID: es el ID del grupo de personal.
• GROUP_ID: es un grupo en la reclamación google.groups asignada.

Consulta la configuración de tu proveedor de identidad que se indica en Configura asignaciones de terceros con Workforce Identity para obtener más personalizaciones, como especificar los atributos de los departamentos, cuando apliques la política de RBAC.

Para obtener más información sobre cómo otorgar permisos y roles de IAM, consulta Otorga, cambia y revoca el acceso a los recursos.

Configura políticas de control de acceso basado en roles (RBAC)

Por último, el servidor de la API de Kubernetes de cada clúster debe poder autorizar los comandos de kubectl que provienen de la puerta de enlace del usuario y los grupos de terceros que especificaste. Para cada clúster, debes agregar una política de permisos RBAC que especifique qué permisos tiene el sujeto en el clúster.

Nota: La ruta del recurso para un usuario de terceros no incluye el nombre del proveedor de identidad. Para evitar permisos inesperados, asegúrate de no usar los mismos nombres de usuarios o grupos en diferentes proveedores de identidad para un solo grupo de personal.

Los sujetos en las políticas de RBAC deben usar el mismo formato que las vinculaciones de IAM, con usuarios de terceros que empiezan con principal://iam.googleapis.com/ y grupos de terceros que empiezan con principalSet://iam.googleapis.com/. Si GKE Identity Service no está configurado para el clúster, necesitarás políticas de suplantación de identidad, además de los roles/clusterroles de un usuario externo. En ese caso, sigue estos pasos de configuración de RBAC y agrega el principal de terceros que empieza con principal://iam.googleapis.com/ como el usuario.

En el siguiente ejemplo, se muestra cómo otorgar a los miembros de un grupo de terceros permisos cluster-admin en un clúster en el que está configurado GKE Identity Service. Luego, puedes guardar el archivo de política como /tmp/admin-permission.yaml y aplicarlo al clúster asociado con el contexto actual.

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: "principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply permission policy to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/admin-permission.yaml

Puedes obtener más información sobre cómo especificar permisos de RBAC en Usa la autorización de RBAC.

Nota: Aunque en nuestros ejemplos se muestra cómo aplicar actualizaciones de políticas directamente con kubectl, para su uso real, recomendamos usar Policy Controller para crear y administrar políticas con el Sincronizador de configuración para sincronizar esas políticas y otras opciones de configuración en tus clústeres.

Próximos pasos

• Obtén más información sobre cómo usar la puerta de enlace de Connect para conectarte a clústeres desde la línea de comandos.
• Consulta un instructivo sobre cómo integrar con Cloud Build para ver un ejemplo de cómo usar la puerta de enlace de Connect con parte de tu automatización de DevOps.