Configurar la pasarela de conexión con identidades de terceros

Esta guía está dirigida a administradores de plataformas que necesitan configurar la puerta de enlace Connect en un proyecto que contiene usuarios que no tienen identidades de Google y que no pertenecen a Google Workspace. En esta guía, nos referimos a estas identidades como "identidades de terceros". Antes de leer esta guía, debes familiarizarte con los conceptos que se explican en el resumen de la conexión de pasarela. Para autorizar cuentas de Google concretas, consulta Configurar la pasarela Connect. Para obtener asistencia sobre Grupos de Google, consulta el artículo Configurar la pasarela de conexión con Grupos de Google.

La configuración de esta guía permite a los usuarios iniciar sesión en clústeres de la flota mediante la CLI de Google Cloud, la puerta de enlace de Connect y la Google Cloud consola.

Tipos de clúster admitidos

Puedes configurar el control de acceso con identidades de terceros a través de la pasarela Connect para los siguientes tipos de clúster registrados:

Si necesitas actualizar los clústeres locales para usar esta función, consulta los artículos Actualizar un clúster para VMware y Actualizar clústeres en hardware desnudo.

Si tienes un caso práctico para entornos de clústeres de GKE que no se incluyan en la lista anterior, ponte en contacto con el equipo de Atención al Cliente de Cloud o con el equipo de la pasarela Connect.

Cómo funciona

Como se describe en la descripción general, los usuarios pueden usar proveedores de identidades que no sean Google Workspace ni Cloud Identity. Con Workforce Identity Federation, los usuarios pueden usar sus proveedores de identidades externos, como Okta o Azure Active Directory, para acceder a sus clústeres a través de Connect Gateway. A diferencia de las cuentas de Google, los usuarios de terceros se representan mediante un principal de gestión de identidades y accesos (IAM) que sigue el formato:

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

  • WORKFORCE_POOL_ID es el nombre del grupo de trabajadores que contiene el proveedor de identidades de terceros correspondiente.

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

En el caso de los grupos de terceros, el principal de gestión de identidades y accesos sigue el 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 se complete correctamente, debe aplicarse una política de control de acceso basado en roles (RBAC) en el clúster al usuario o a un grupo.

En el caso de los usuarios individuales, debe haber una política de control de acceso basado en roles que utilice el nombre principal completo de gestión de identidades y accesos del usuario en el clúster.

Si se usa la función de grupo, debe haber una política de control de acceso basado en roles en el clúster que utilice el nombre principal de gestión de identidades y accesos completo para un grupo que:

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

  2. Se incluye en una asignación de un proveedor de identidades de un grupo de identidades para el trabajo que pertenece a la organización de Google Cloud de Alicia.

Diagrama que muestra el flujo de identidad de terceros de la pasarela

  1. El usuario alice@example.com inicia sesión en gcloud con su identidad de terceros mediante el inicio de sesión basado en navegador de terceros. Para usar el clúster desde la línea de comandos, el usuario obtiene la pasarela del clúster kubeconfig, tal como se describe en Usar la pasarela de conexión.
  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. La pasarela de conexión recibe la solicitud, que gestiona la autenticación de terceros mediante Workforce Identity Federation.
  4. La pasarela de conexión realiza una comprobación de autorización con gestión de identidades y accesos.
  5. 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.
  6. El agente de conexión reenvía la solicitud al servidor de la API de Kubernetes.
  7. El servidor de la API de Kubernetes reenvía la solicitud al servicio de identidad de GKE, que la valida.
  8. GKE Identity Service devuelve la información de usuarios y grupos 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 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 externos a Google Cloud, GKE Identity Service debe llamar a las APIs de Google desde tu clúster para completar la autenticación. Comprueba si tu política de red requiere que el tráfico saliente pase por un proxy.

Configurar mapeos de atributos de identidad de terceros con Workforce Identity

Asegúrate de que haya un grupo de usuarios y un proveedor de identidades configurados para tu organización de Google Cloud siguiendo las instrucciones correspondientes a tu proveedor de identidades:

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.

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 identidades de terceros de la pasarela de conectividad 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 identidades de terceros. 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 utilizas clústeres adjuntos de GKE con la pasarela, no es necesario usar Identity Service de GKE para admitir identidades de terceros. Sigue las instrucciones correspondientes al tipo de clúster que hayas elegido para configurar la compatibilidad con identidades de terceros:

Asegúrate de que Identity Service para GKE esté instalado

El servicio de identidades de GKE se instala de forma predeterminada en los clústeres de GKE a partir de la versión 1.7 (aunque la compatibilidad con identidades de terceros requiere la versión 1.13 o 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 compatibilidad con identidades de terceros para grupos

Si tu clúster o flota ya está configurado para admitir Grupos de Google, no tienes que hacer nada más y puedes ir a la sección Conceder roles de IAM a usuarios y grupos de terceros.

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 de grupos de terceros.

Si es la primera vez que usas GKE Identity Service, puedes configurar la compatibilidad con grupos de terceros mediante las APIs de flota (opción recomendada) o kubectl.

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 de grupos de terceros estará habilitada 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 GKE Identity Service para otro proveedor de identidades en cada clúster, consulta la sección Kubectl que aparece más abajo para obtener instrucciones sobre cómo actualizar la configuración de la función de grupos de terceros.

Fleet

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

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

  2. En el panel Servicio de identidad, haz clic en Detalles. Se mostrarán los detalles del clúster de tu proyecto.

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

  4. 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.

  5. En la sección Configurar proveedores de identidades, puede conservar, añadir, actualizar o quitar un proveedor de identidades.

  6. 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.

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

  8. 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 de grupos de terceros mediante un proxy

Si necesitas acceder al proveedor de identidades 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: authentication-method
      google:
        disable: false
      proxy: PROXY_URL

donde

  • disable (opcional) indica si quieres habilitar o inhabilitar la función de grupos de terceros 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.

Kubectl

Para configurar tu clúster de forma que use el servicio de identidad de GKE con la función de grupos de terceros, debes actualizar el ClientConfig del servicio de identidad de GKE 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 CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

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.

A continuación, se muestra 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 de grupos de terceros. 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 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 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 usuarios y grupos de terceros

Las identidades de terceros 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 usuarios acceder a la API Connect Gateway.
    • Si los usuarios solo necesitan acceso de solo lectura a los clústeres conectados, se puede usar roles/gkehub.gatewayReader.
    • Si los usuarios necesitan acceso de lectura y escritura a los clústeres conectados, pueden usar roles/gkehub.gatewayEditor.
  • roles/gkehub.viewer. Este rol permite a los usuarios ver las pertenencias a clústeres registradas.

A continuación, se muestra cómo añadir los roles necesarios a identidades concretas y grupos asignados:

Identidades únicas

Para conceder los roles necesarios a una sola identidad del 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 los valores roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o gkehub.gatewayEditor.
  • WORKFORCE_POOL_ID: es el ID del grupo de identidades de Workforce.
  • SUBJECT_VALUE: es la identidad del usuario.

Grupos

Para asignar los roles necesarios a todas las identidades de un grupo específico del 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 los valores roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o gkehub.gatewayEditor.
  • WORKFORCE_POOL_ID: es el ID del grupo de trabajadores.
  • GROUP_ID: es un grupo de la reclamación google.groups asignada.

Consulta la configuración de tu proveedor de identidades en Configurar asignaciones de terceros con Workforce Identity para obtener más información sobre las personalizaciones, como especificar atributos de departamento, al aplicar la política de control de acceso basado en roles.

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 de los usuarios y grupos de terceros 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 sujeto en el clúster.

Los sujetos de las políticas de RBAC deben usar el mismo formato que los enlaces de IAM. Los usuarios externos deben empezar por principal://iam.googleapis.com/ y los grupos externos, por 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 roles o roles de clúster, para un usuario de terceros. En ese caso, sigue estos pasos para configurar el control de acceso basado en roles y añade la entidad de terceros que empieza por principal://iam.googleapis.com/ como usuario.

En el siguiente ejemplo se muestra cómo conceder permisos cluster-admin a los miembros de un grupo de terceros en un clúster en el que se ha configurado el servicio de identidad de GKE. A continuación, puedes guardar el archivo de política como /tmp/admin-permission.yaml y aplicarlo al clúster asociado al 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

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