Configura la puerta de enlace de Connect con identidades de terceros

Esta guía está destinada 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 con los Grupos de Google, consulta Configura la puerta de enlace de Connect mediante Grupos de Google.

En la configuración de esta guía, los usuarios pueden acceder a clústeres de flotas mediante 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 a través de la puerta de enlace de Connect para los siguientes tipos de clústeres registrados:

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

Si necesitas actualizar los clústeres locales para usar esta función, Actualiza los clústeres de GKE Enterprise para VMWare y Actualiza los clústeres de GKE Enterprise en un equipo físico..

Si tienes un caso de uso para entornos de clústeres de GKE distintos de los mencionados anteriormente, 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 un principal de Identity and Access Management (IAM) que sigue el formato siguiente:

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

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

A continuación, se muestra el flujo típico de un usuario de terceros que se autentica y ejecuta comandos en un clúster de Anthos con este servicio habilitado. Para que este flujo tenga éxito, se debe aplicar una política de control de acceso basado en roles (RBAC) en el clúster al usuario o al grupo.

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

Si usas 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 cumpla con las siguientes características:

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

2. Está incluido en una asignación para un proveedor de identidad dentro de un grupo de personal 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 de Anthos.

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 kubeconfig del clúster 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 del personal, recibe la solicitud.
4. La puerta de enlace de Connect realiza una verificación de autorización mediante 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 mediante Workforce Identity

Asegúrate de que haya un grupo de personal y un proveedor de identidad configurados para tu organización de Google Cloud mediante 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 asistencia con identidad de terceros para grupos

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

Si usas GKE en Bare Metal o GKE en VMware, 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 la flota.

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 Funciones de GKE Enterprise.

   Ir a Funciones de GKE Enterprise

2. En la tabla Funciones, haz clic en Detalles en la fila 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 de grupos de terceros mediante un proxy

Si necesitas acceder al proveedor de identidad a través de 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 deseas 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 ClientConfig del clúster de GKE Identity Service. 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.

A continuación, se muestra un ejemplo de cómo puedes actualizar 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. Este rol permite a los usuarios acceder a la API de la puerta de enlace de Connect.
  • Si los usuarios solo 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 únicas

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 Workforce Identity.
• 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 para tu proveedor de identidad que se indica en Configura asignaciones de terceros con Workforce Identity para obtener más personalizaciones, como especificar atributos de departamento, cuando se aplica 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 especificados. 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 usuario o grupo 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 comienzan con principal://iam.googleapis.com/ y grupos de terceros que comienzan con principalSet://iam.googleapis.com/. Si GKE Identity Service no está configurado para el clúster, necesitarás políticas de robo de identidad además de roles/clusterroles para un usuario de terceros. En ese caso, sigue estos pasos de configuración de RBAC y agrega el principal de terceros que comienza 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 se configura GKE Identity Service. Luego, puedes guardar el archivo de la 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.