Configurar la pasarela de conexión con Grupos de Google

Esta guía está dirigida a administradores de plataformas que necesiten configurar la pasarela Connect para que la usen las cuentas de usuario de su proyecto. Para ello, deben usar Grupos de Google para la autorización. Antes de leer esta página, familiarízate con los conceptos que se explican en nuestra página de introducción. Para autorizar cuentas concretas, consulta la configuración predeterminada.

Esta configuración permite a los usuarios iniciar sesión en los clústeres de la flota configurados mediante la CLI de Google Cloud, la pasarela de Connect y la consola de Google Cloud .

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

Tipos de clúster admitidos

Si utilizas clústeres de GKE en Google Cloud con Connect Gateway, no es necesario que sigas toda esta configuración con Identity Service para GKE para usar grupos de Google con fines de autorización. En su lugar, sigue las instrucciones de Configurar Grupos de Google para RBAC, que también permite a los usuarios iniciar sesión en clústeres de GKE desde la consola de Google Cloud mediante Grupos de Google para controlar el acceso. Una vez que lo hayas hecho, sigue las instrucciones que se indican más abajo en Asigna roles de gestión de identidades y accesos a grupos de Google para permitir que los miembros del grupo accedan a los clústeres a través de la pasarela Connect.

Puedes configurar el control de acceso con Grupos de Google a través de la pasarela de conexión para los siguientes tipos de clústeres:

Para usar esta función con entornos distintos de los que se indican en esta sección, ponte en contacto con Cloud Customer Care o con el equipo de Connect Gateway.

Cómo funciona

Como se describe en la descripción general, a menudo es útil poder dar acceso a los usuarios a los clústeres en función de su pertenencia a Grupos de Google, es decir, grupos creados en Google Workspace. Al autorizar el acceso en función de la pertenencia a un grupo, no tienes que configurar una autorización independiente para cada cuenta, lo que simplifica la gestión de las políticas y facilita la auditoría. Por ejemplo, puedes compartir fácilmente el acceso a un clúster con un equipo, lo que elimina la necesidad de añadir o quitar manualmente usuarios de los clústeres cuando se unan al equipo o lo abandonen. Con una configuración adicional mediante GKE Identity Service, puedes configurar la pasarela de Connect para obtener información sobre la pertenencia a grupos de Google de cada usuario que inicie sesión en el clúster. Después, puede usar la información de estos grupos en sus políticas de control de acceso.

A continuación, se muestra el flujo habitual de un usuario que se autentica en un clúster con este servicio habilitado y ejecuta comandos en él. Para que este flujo se complete correctamente, debe haber una política de RBAC en el clúster para un grupo que cumpla los siguientes requisitos:

  1. Contiene el alice@example.com del usuario como miembro.

  2. Es un grupo anidado de gke-security-groups@example.com.

Diagrama que muestra el flujo de Grupos de Google de la pasarela

  1. El usuario alice@example.com inicia sesión con su identidad de Google y, si tiene previsto usar el clúster desde la línea de comandos, obtiene la kubeconfig de la pasarela del clúster, tal como se describe en Usar la pasarela Connect.
  2. El usuario envía una solicitud ejecutando un comando kubectl o abriendo las páginas Cargas de trabajo o Explorador de objetos de Google Kubernetes Engine en la consola de Google Cloud .
  3. El servicio Connect recibe la solicitud y realiza una comprobación de autorización con IAM.
  4. El servicio Connect reenvía la solicitud al agente Connect que se ejecuta en el clúster. La solicitud va acompañada de la información de las credenciales del usuario para usarla en la autenticación y la autorización en el clúster.
  5. El agente de conexión reenvía la solicitud al servidor de la API de Kubernetes.
  6. El servidor de la API de Kubernetes reenvía la solicitud al servicio de identidad de GKE, que la valida.
  7. GKE Identity Service devuelve la información de usuarios y grupos 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 empezar

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

    • La versión más reciente de la CLI de Google Cloud, 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 ya están instaladas.

  • Asegúrate de haber inicializado gcloud CLI para usarlo con tu proyecto.

  • En esta guía se da por hecho que tienes roles/owner en tu proyecto. Si no eres el propietario del proyecto, es posible que necesites permisos adicionales para completar algunos de los pasos de configuración.

  • En el caso de los clústeres que no están en Google Cloud, GKE Identity Service debe llamar a la API de identidad de Google desde tu clúster. Comprueba si tu política de red requiere que el tráfico saliente pase por un proxy.

Configurar usuarios y grupos

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

  1. Asegúrate de que haya un grupo en el Google Workspace de tu organización con el formato gke-security-groups@YOUR-DOMAIN. Si no tienes ningún grupo de este tipo, sigue las instrucciones de Crear un grupo en tu organización para crearlo con la consola de administración de Google Workspace.
  2. Sigue las instrucciones del artículo Añadir un grupo a otro grupo para añadir los grupos que quieras usar para controlar el acceso como grupos anidados de gke-security-groups. No añadas usuarios concretos como miembros de gke-security-groups.

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

Habilitar APIs

Para añadir la pasarela a tu proyecto, habilita la API Connect Gateway y las APIs de dependencia necesarias. Si tus usuarios solo quieren autenticarse en los clústeres mediante la Google Cloud consola, no tienes que habilitar connectgateway.googleapis.com, pero sí las APIs restantes.

PROJECT_ID=example_project
gcloud services enable --project=${PROJECT_ID}  \
connectgateway.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com

Configurar el servicio de identidad de GKE

La función de compatibilidad con Grupos de Google de la pasarela Connect usa el servicio de identidad de GKE para obtener información sobre la pertenencia a grupos de Google. Puedes obtener más información sobre el servicio de identidad de GKE en el artículo Presentamos el servicio de identidad de GKE.

Si usas clústeres de GKE con la pasarela, no necesitas configurar Identity Service para GKE para usar la compatibilidad con Grupos de Google. En su lugar, sigue las instrucciones de Configurar Grupos de Google para el control de acceso basado en roles y ve a Conceder roles de gestión de identidades y accesos para conceder acceso a los clústeres a través de la pasarela.

Si usas clústeres adjuntos de GKE con la pasarela, no es necesario usar Identity Service de GKE para admitir grupos de Google. Sigue las instrucciones del tipo de clúster que hayas elegido para configurar la compatibilidad con Grupos de Google:

Asegúrate de que Identity Service para GKE 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 para usar Grupos de Google se necesita la versión 1.13 o una posterior). Para confirmar que se ha instalado correctamente en tu clúster, ejecuta el siguiente comando:

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

Sustituye CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster.

Configurar la asistencia de Grupos de Google

Si usas GKE en AWS o GKE en Azure, tu clúster se configura automáticamente para admitir grupos de Google, por lo que puedes ir directamente a Asignar roles de gestión de identidades y accesos a grupos de Google.

Si usas Google Distributed Cloud en VMware o en bare metal, la forma en que configures GKE Identity Service determina cómo debes configurar la función Grupos de Google.

Si es la primera vez que usas GKE Identity Service, puedes elegir entre configurar Grupos de Google a nivel de flota (opción recomendada) o configurar por clúster.

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

  • Si ya has configurado GKE Identity Service para otro proveedor de identidades a nivel de flota, la función Grupos de Google se habilitará de forma predeterminada. Consulta la sección Flota que aparece más abajo para obtener más información y saber si necesitas realizar alguna configuración adicional.

  • Si ya has configurado el servicio de identidad de GKE para otro proveedor de identidades en cada clúster, consulta la sección Por clúster que aparece más abajo para obtener instrucciones sobre cómo actualizar la configuración de la función Grupos de Google.

Fleet

Puedes usar la Google Cloud consola o la línea de comandos para configurar el acceso a grupos de Google a nivel de flota.

Si ya has configurado GKE Identity Service a nivel de flota con otro proveedor de identidades (como Microsoft AD FS u Okta), la función Grupos de Google de la puerta de enlace de Connect ya estará habilitada de forma predeterminada en los clústeres configurados, siempre que se pueda acceder al proveedor de identidades de Google sin necesidad de usar un proxy.

Consola

Si no has configurado GKE Identity Service para una flota anteriormente, sigue las instrucciones que se indican en Configurar clústeres para GKE Identity Service.

Seleccionar clústeres y actualizar la configuración

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

Ir a Gestor de funciones

  1. En el panel Servicio de identidad, haz clic en Detalles. Se mostrarán los detalles del clúster de tu proyecto.
  2. Haz clic en Actualizar servicio de identidad para abrir el panel de configuración.
  3. Selecciona los clústeres que quieras configurar. Puedes elegir clústeres concretos o especificar que quieres que todos los clústeres se configuren con la misma configuración de identidad.
  4. En la sección Configurar proveedores de identidades, puede conservar, añadir, actualizar o quitar un proveedor de identidades.
  5. Haz clic en Continuar para ir al siguiente paso de configuración. Si has seleccionado al menos un clúster apto para esta configuración, se mostrará la sección Autenticación de Google.
  6. Selecciona Habilitar para habilitar la autenticación de Google en los clústeres seleccionados. Si necesitas acceder al proveedor de identidades de Google a través de un proxy, introduce los detalles del proxy.
  7. Haz clic en Update Configuration (Actualizar configuración). De esta forma, se aplica la configuración de identidad a los clústeres seleccionados.

gcloud

Si no has configurado GKE Identity Service para una flota anteriormente, sigue las instrucciones de Configurar clústeres para GKE Identity Service. Especifica solo la siguiente configuración en el archivo auth-config.yaml:

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

Configurar el acceso a Grupos de Google mediante un proxy

Si necesitas acceder al proveedor de identidades de Google a través de un proxy, usa un campo proxy en tu archivo auth-config.yaml. Puede que tengas que definirlo si, por ejemplo, tu clúster está en una red privada y necesita conectarse a un proveedor de identidades público. Debes añadir esta configuración aunque ya hayas configurado GKE Identity Service para otro proveedor.

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

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

donde

  • disable (opcional) indica si quieres habilitar o inhabilitar la función Grupos de Google para los clústeres. El valor predeterminado es false. Si quieres inhabilitar esta función, puedes asignarle el valor true.

  • PROXY_URL (opcional) es la dirección del servidor proxy para conectarse a la identidad de Google. 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 pertenencia único de tu clúster en la flota.

Una vez aplicada, esta configuración la gestiona el controlador de Identity Service de GKE. El controlador reconcilia cualquier cambio local que se haya hecho en la configuración del cliente de Identity Service for GKE con la configuración especificada en esta configuración.

Por clúster

Para configurar tu clúster de forma que use GKE Identity Service con la función Grupos de Google, debes actualizar el ClientConfig de GKE Identity Service del clúster. Se trata de un tipo de recurso personalizado de Kubernetes (CRD) que se usa para la configuración del clúster. Cada clúster tiene un recurso ClientConfig llamado default en el espacio de nombres kube-public, que debes actualizar con los detalles de tu configuración.

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

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

donde USER_CLUSTER_KUBECONFIG es la ruta al archivo kubeconfig de tu clúster.

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

Aquí tienes un ejemplo de cómo puedes actualizar el ClientConfig con un nuevo método de autenticación que tenga una configuración de tipo google para habilitar la función Grupos de Google. Si el campo internalServer está vacío, asegúrate de que esté definido 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 (obligatorio) indica los detalles de la pertenencia a tu clúster. Puedes consultar los detalles de la pertenencia a tu clúster con el siguiente comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml

donde

USER_CLUSTER_KUBECONFIG es la ruta al archivo kubeconfig del clúster. En la respuesta, consulta el campo spec.owner.id para obtener los detalles de la pertenencia al clúster.

A continuación se muestra un ejemplo de respuesta que muestra los detalles de pertenencia 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

Conceder roles de gestión de identidades y accesos a grupos de Google

Los grupos necesitan los siguientes roles adicionales Google Cloud para interactuar con los clústeres conectados a través de la pasarela:

  • roles/gkehub.gatewayAdmin. Este rol permite a los miembros del grupo acceder a la API de pasarela Connect.
    • Si los miembros del grupo solo necesitan acceso de solo lectura a los clústeres conectados, se puede usar roles/gkehub.gatewayReader.
    • Si los miembros del grupo necesitan acceso de lectura y escritura a los clústeres conectados, se puede usar roles/gkehub.gatewayEditor.
  • roles/gkehub.viewer. Este rol permite a los miembros del grupo ver las pertenencias a clústeres registradas.

Para asignar estos roles, usa el comando gcloud projects add-iam-policy-binding, como se indica a continuación:

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 quieres conceder el rol.
  • DOMAIN es tu dominio de Google Workspace
  • GROUP_NAME@DOMAIN es un grupo anidado de gke-security-groups@DOMAIN
  • GATEWAY_ROLE es uno de los valores roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o gkehub.gatewayEditor.
  • PROJECT_ID es tu proyecto

Para obtener más información sobre cómo conceder roles y permisos de gestión de identidades y accesos, consulta el artículo Conceder, cambiar y revocar el acceso a los recursos.

Configurar 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 kubectl que lleguen a través de la pasarela desde los grupos que hayas especificado. En cada clúster, debe añadir una política de permisos de control de acceso basado en roles que especifique qué permisos tiene el grupo en el clúster.

En el siguiente ejemplo, verás cómo conceder permisos de cluster-admin-team a los miembros del grupo cluster-admin en el clúster, guardar el archivo de política como /tmp/admin-permission.yaml y aplicarlo al clúster asociado al contexto actual. No olvides 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: cluster-admin-team@example.com
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

Para obtener más información sobre cómo especificar permisos de RBAC, consulta el artículo Usar la autorización de RBAC.

Siguientes pasos