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 a través de la puerta de enlace de Connect para los siguientes tipos de clústeres:

• GKE en Google Cloud: Todas las versiones disponibles. Para configurar la puerta de enlace de Connect, configura Grupos de Google para RBAC y, luego, otorga roles de IAM a Grupos de Google.
• Google Distributed Cloud (solo software) en VMware y equipos físicos: Todas las versiones disponibles.
• Google Distributed Cloud conectado: Todas las versiones disponibles.
• Clústeres conectados de GKE: versión 1.28.0-gke.2 y posteriores

• GKE en AWS y GKE en Azure: Todas las versiones disponibles

Para usar esta función con entornos que no se encuentren en la lista anterior, 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. Con 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 alice@example.com 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 Google Cloud de Alice.

1. El usuario alice@example.com accede a gcloud CLI con su identidad de terceros a través del 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 Google Cloud consola.
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 al componente del servicio de identidad en el clúster, que la valida.
8. El componente del servicio de identidad devuelve 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

Accede a tu cuenta de Google Cloud . Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Instala Google Cloud CLI.

Si usas un proveedor de identidad externo (IdP), primero debes acceder a la gcloud CLI con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente comando:

gcloud init

Verifica que tengas los permisos necesarios para completar esta guía.

Habilita las APIs de Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service y Cloud Resource Manager:

Roles necesarios para habilitar las APIs

Para habilitar las APIs, necesitas el rol de IAM de administrador de Service Usage (roles/serviceusage.serviceUsageAdmin), que contiene el permiso serviceusage.services.enable. Obtén más información para otorgar roles.

gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

Instala Google Cloud CLI.

Si usas un proveedor de identidad externo (IdP), primero debes acceder a la gcloud CLI con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente comando:

gcloud init

Verifica que tengas los permisos necesarios para completar esta guía.

Habilita las APIs de Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service y Cloud Resource Manager:

Roles necesarios para habilitar las APIs

Para habilitar las APIs, necesitas el rol de IAM de administrador de Service Usage (roles/serviceusage.serviceUsageAdmin), que contiene el permiso serviceusage.services.enable. Obtén más información para otorgar roles.

gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

1. Para los clústeres fuera de Google Cloud, los componentes de autenticación de tu clúster deben llamar a la API de Cloud Identity. Verifica si tienes políticas de red que requieren que el tráfico de salida de tu clúster pase por un proxy.

Roles obligatorios

Para obtener los permisos que necesitas para configurar la puerta de enlace de Connect y tus clústeres, pídele a tu administrador que te otorgue el rol de IAM de Editor (roles/editor) en el proyecto. Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios a través de roles personalizados o cualquier otro rol predefinido.

Configura asignaciones de atributos de identidad de terceros con la federación de identidades de personal

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

Configura la compatibilidad con grupos

La puerta de enlace de Connect usa componentes de autenticación en tu clúster para recuperar información de pertenencia a grupos. Para habilitar los componentes necesarios, consulta uno de los siguientes documentos según tu tipo de clúster:

• GKE en Google Cloud: Configura Grupos de Google para RBAC y, luego, ve a la sección Otorga roles de IAM a grupos.
• Clústeres conectados de GKE:
  • Conéctate a tu clúster adjunto de EKS
  • Conéctate a tu clúster adjunto de AKS
  • Cómo conectarte a tus otros tipos de clústeres

• Google Distributed Cloud: Para habilitar la compatibilidad con grupos, actualiza el recurso personalizado ClientConfig en tu clúster. Distributed Cloud crea automáticamente un ClientConfig llamado default en el espacio de nombres kube-public de cada clúster. Para verificar que este recurso personalizado exista, ejecuta el siguiente comando:

  kubectl --kubeconfig CLUSTER_KUBECONFIG get ClientConfig default -n kube-public
  

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

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.

En las siguientes secciones, se muestra cómo actualizar el recurso personalizado ClientConfig para habilitar la compatibilidad con grupos. Estas secciones solo se aplican a los clústeres de Google Distributed Cloud. Para otros tipos de clústeres, como GKE enGoogle Cloud, GKE en AWS y GKE en Azure, pasa a la sección Otorga roles de IAM a grupos.

En el caso de Distributed Cloud, puedes configurar la compatibilidad con grupos para clústeres individuales o para una flota. El tipo de clúster que uses determinará cómo configurar la compatibilidad con grupos, de la siguiente manera:

• Distributed Cloud conectado: Solo clústeres individuales. No se admite la configuración a nivel de la flota.
• Google Distributed Cloud (solo software) en VMware y equipos físicos: Clústeres o flotas individuales

Configura la compatibilidad con grupos usando la API de Fleet de GKE

En el caso de Google Distributed Cloud (solo software) en VMware y equipos físicos, puedes configurar la asistencia para grupos a nivel de la flota. Si ya configuraste la autenticación a nivel de la flota, por ejemplo, para otro proveedor de identidad, la autenticación de grupos ya está habilitada. Sin embargo, si tu política de red requiere que el tráfico de salida pase por un proxy, debes actualizar la configuración existente con información sobre ese proxy.

Para configurar la compatibilidad con grupos a nivel de la flota, selecciona una de las siguientes opciones:

Después de configurar la compatibilidad con grupos a nivel de la flota, el controlador de la flota administra la configuración. La configuración a nivel de la flota anula cualquier cambio local que realices en la configuración de un clúster específico.

Configura la compatibilidad con grupos para clústeres individuales

Para todos los clústeres de Distributed Cloud, incluido Distributed Cloud Connected, habilita la compatibilidad con grupos actualizando el ClientConfig de default en cada clúster:

1. Obtén los detalles de la membresía de tu clúster:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml
   

   Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster. 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.

   En la respuesta, consulta el campo spec.owner.id para recuperar los detalles de la membresía del clúster. El identificador de membresía tiene el formato //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP.

   El resultado es similar a lo siguiente:

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

2. Abre el ClientConfig default en tu clúster para editarlo:

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

3. Para habilitar la compatibilidad con grupos, agrega el campo google al campo spec.authentication:

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

   Reemplaza CLUSTER_IDENTIFIER por los detalles de membresía de tu clúster.

   Asegúrate de que el campo internalServer tenga el valor https://kubernetes.default.svc.

4. Opcional: Si necesitas acceder al proveedor de identidad de Google a través de un proxy, agrega el campo proxy a la configuración anterior:

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

   Reemplaza PROXY_URL por la dirección del servidor proxy al que se conectará la identidad de Google. Por ejemplo: http://user:password@10.10.10.10:8888

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 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:

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"

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"

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.

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 el clúster no tiene configurada la autenticación de identidades externas de terceros, 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á configurada la autenticación de identidades externas de terceros. 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.

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.