Configura la puerta de enlace de Connect con Grupos de Google

Esta guía está dirigida a los administradores de la plataforma que necesitan configurar la puerta de enlace de Connect para que la usen las cuentas de usuarios del proyecto a través de Grupos de Google para la autorización. Antes de leer esta página, asegúrate de que estés familiarizado con los conceptos de nuestra descripción general. Para autorizar cuentas individuales, consulta la configuración predeterminada.

Esta configuración permite que los usuarios accedan a los clústeres de flotas configurados a través de la Google Cloud CLI, la puerta de enlace de Connect y la Google Cloud consola de Cloud.

Esta función usa Grupos de Google asociados con Google Workspace o cualquier edición de Cloud Identity.

Tipos de clústeres compatibles

Puedes configurar el control de acceso con Grupos de Google 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 Bare Metal: 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 versiones posteriores.

• GKE en AWS y GKE en Azure: todas las versiones disponibles.

  Precaución: GKE en AWS y GKE en Azure están obsoletos. Para obtener más información, consulta el anuncio de baja de GKE en AWS y el anuncio de baja de GKE en Azure.

Para usar esta función con entornos que no estén 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, suele ser útil poder brindar a los usuarios acceso a los clústeres según su pertenencia a Grupos de Google, es decir, grupos creados en Google Workspace. La autorización basada en la pertenencia a un grupo significa que no tienes que configurar una autorización distinta para cada cuenta, lo que simplifica la administración de las políticas y facilita su auditoría. Por ejemplo, puedes compartir con facilidad el acceso al clúster a un equipo, sin la necesidad de agregar o quitar usuarios individuales de los clústeres cuando se unen al equipo o salen de él. Puedes configurar la puerta de enlace de Connect para obtener información de la pertenencia a un Grupo de Google para cada usuario que acceda al clúster. Luego, puedes usar esta información en tus políticas de control de acceso.

Nota: Las cuentas de servicio (cuentas que terminan en gserviceaccount.com) no son compatibles con la funcionalidad de Grupos de Google.

A continuación, se muestra el flujo típico de un usuario que se autentica y ejecuta comandos en un clúster con este servicio habilitado. Para que este flujo funcione correctamente, debe existir una política de RBAC en el clúster para un grupo que cumpla con lo siguiente:

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

2. Es un grupo anidado de [e-mail].

1. El usuario [e-mail] accede con su identidad de Google y, si planea usar el clúster desde la línea de comandos, obtiene la puerta de enlace del clúster gateway 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 kubectl comando o la apertura de las páginas Cargas de trabajo o Navegador de objetos de Google Kubernetes Engine en la Google Cloud consola de Cloud.
3. El servicio de Connect, que realiza una verificación de autorización mediante IAM, recibe la solicitud.
4. 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.
5. El agente de Connect reenvía la solicitud al servidor de la API de Kubernetes.
6. El servidor de la API de Kubernetes reenvía la solicitud al pod anthos-identity-service en el clúster, que la valida.
7. El pod anthos-identity-service muestra la información del usuario y el grupo 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 Google Cloud cuenta de. 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.

Nota: Si ya instalaste gcloud CLI, asegúrate de tener la versión más reciente ejecutando gcloud components update.

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 la puerta de enlace de Connect, 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 serviceusage.services.enable permiso. 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.

Nota: Si ya instalaste gcloud CLI, asegúrate de tener la versión más reciente ejecutando gcloud components update.

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 la puerta de enlace de Connect, 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 serviceusage.services.enable permiso. 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 requieran 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 Editor (roles/editor) rol de IAM 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 los usuarios y grupos

Asegúrate de que los grupos que deseas usar con esta función estén configurados de la siguiente manera:

1. Asegúrate de que haya un grupo en Google Workspace de tu organización con el formato gke-security-groups@YOUR-DOMAIN. Si no tienes ese grupo, sigue las instrucciones que se indican en Crea un grupo en tu organización para crear el grupo con la Consola del administrador de Google.
2. Sigue las instrucciones en Agrega un grupo a otro grupo para agregar los grupos que deseas usar para el control de acceso como grupos anidados de gke-security-groups. No agregues usuarios individuales como miembros de gke-security-groups.

Las cuentas de usuario que desees utilizar con esta función deben usar el mismo nombre de dominio que el de su grupo.

Nota: La cantidad de grupos que se muestran para un usuario en el grupo gke-security-groups está limitada por el límite de tamaño del encabezado HTTP de 8 KB. Si bien no hay un límite estricto en la cantidad de grupos, los nombres de grupos largos pueden hacer que la solicitud exceda este límite y generar errores que podrían requerir que reestructures la jerarquía de grupos.

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 la 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, pasa 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: habilita la compatibilidad con grupos actualizando el recurso personalizado ClientConfig en tu clúster. Distributed Cloud crea automáticamente un ClientConfig llamado default en el espacio de nombres kube-public en cada clúster. Para verificar que existe este recurso personalizado, 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.

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 en Google CloudGKE en AWS y GKE en Azure, pasa a la sección Otorga roles de IAM a grupos.

En Distributed Cloud, puedes configurar la compatibilidad con grupos para clústeres individuales o para una flota. El tipo de clúster que usas determina cómo configuras la compatibilidad con grupos, de la siguiente manera:

• Google 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 Bare Metal: clústeres individuales o flotas.

Configura la compatibilidad con grupos mediante la API de GKE Fleet

En Google Distributed Cloud (solo software) en VMware y Bare Metal, puedes configurar la compatibilidad con grupos a nivel de la flota. Si configuraste previamente la autenticación a nivel de la flota, por ejemplo, para un proveedor de identidad diferente, 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:

Console

1. En la Google Cloud consola de Cloud, ve a la página GKE Identity Service.

   Ir a Servicio de identidad de GKE

2. Haz clic en Habilitar Identity Service.

3. Selecciona los clústeres de Google Distributed Cloud (solo software) en VMware y Bare Metal que deseas configurar.

4. Haz clic en Actualizar configuración. Se abrirá el panel Editar la configuración de los clústeres del servicio 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

1. Habilita la función de servicio de identidad a nivel de la flota y configura los clústeres, como se describe en Configura la administración de autenticación a nivel de la flota.

2. En el archivo auth-config.yaml que contiene tu especificación de ClientConfig, agrega el siguiente campo:

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

   El valor de false en el campo google.disable habilita la compatibilidad con grupos. Para inhabilitar la compatibilidad con grupos, modifica este valor a true.

3. 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:
     authentication:
     - name: google-authentication-method
       google:
         disable: false
       proxy: PROXY_URL
   

   Reemplaza PROXY_URL por la dirección del servidor proxy para conectarte a la identidad de Google. Por ejemplo: http://user:password@10.10.10.10:8888

4. Aplica la configuración a un clúster de tu flota:

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

   Reemplaza CLUSTER_NAME por el nombre de membresía único de tu clúster dentro de la flota.

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 conectado, habilita la compatibilidad con grupos actualizando el ClientConfig 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 este:

   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 la membresía de tu clúster.

   Asegúrate de que el campo internalServer tenga un valor de 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 para conectarte a la identidad de Google. Por ejemplo: http://user:password@10.10.10.10:8888

Otorga funciones de IAM a Grupos de Google

Nota: Cuando administres el acceso para los usuarios en proveedores de identidad externos, reemplaza las instancias de los identificadores principales de la Cuenta de Google, como user:[e-mail], group:[e-mail], y domain:example.com, por los identificadores principales de la federación de identidades de personal adecuados.

Los grupos necesitan las siguientes funciones adicionales 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 miembros del grupo acceder a la API de la puerta de enlace de Connect.
  • Si los miembros del grupo necesitan únicamente acceso de solo lectura a los clústeres conectados, se puede usar roles/gkehub.gatewayReader en su lugar.
  • Si los miembros del grupo necesitan acceso de lectura/escritura a los clústeres conectados, se puede usar roles/gkehub.gatewayEditor en su lugar.
• roles/gkehub.viewer: Este rol permite a los miembros del grupo veer las membresías registradas a los clústeres.

Debes otorgar estas funciones mediante el comando gcloud projects add-iam-policy-binding, de la siguiente manera:

gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=GATEWAY_ROLE PROJECT_ID
gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=roles/gkehub.viewer PROJECT_ID

donde

• GROUP_NAME es el grupo de Google al que deseas otorgar la función.
• DOMAIN es tu dominio de Google Workspace.
• GROUP_NAME@DOMAIN es un grupo anidado en gke-security-groups@DOMAIN
• GATEWAY_ROLE es uno de roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o gkehub.gatewayEditor.
• PROJECT_ID es tu proyecto.

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 de los grupos que especificaste. Para cada clúster, debes agregar una política de permisos RBAC que especifique qué permisos tiene el grupo en el clúster.

En el siguiente ejemplo, verás cómo otorgar a los miembros del grupo cluster-admin-team permisos cluster-admin en el clúster, guardar el archivo de política como /tmp/admin-permission.yaml y aplicarlo al clúster asociado con el contexto actual. Asegúrate de incluir también el grupo cluster-admin-team en el grupo gke-security-groups.

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: [e-mail]
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 en Cloud Build para ver un ejemplo de cómo usar la puerta de enlace de Connect con parte de tu automatización de DevOps.