Configurar la pasarela de conexión

Esta guía está dirigida a administradores de plataformas que necesiten configurar la pasarela Connect para que la usen los usuarios y las cuentas de servicio de su proyecto. Esta configuración permite a los usuarios hacer lo siguiente:

  • Usa la Google Cloud consola para iniciar sesión en clústeres registrados fuera deGoogle Cloud con su Google Cloud identidad.

  • Usa kubectl para acceder a los clústeres a través de la pasarela de conexión.

Esta configuración solo permite la autenticación de usuarios y servicios en función de sus IDs individuales, no de su pertenencia a Grupos de Google. Para configurar la asistencia adicional de grupos, consulta Configurar la pasarela de conexión con Grupos de Google.

Si no conoces la pasarela Connect, consulta nuestra descripción general para obtener una explicación de los conceptos básicos y cómo funciona.

Antes de empezar

  1. 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.
    • kubectl para ejecutar comandos en clústeres de Kubernetes. Si necesitas instalar kubectl, sigue estas instrucciones.

    Si usas Cloud Shell como entorno de shell para interactuar conGoogle Cloud, estas herramientas ya están instaladas.

  2. Inicializa la CLI de gcloud para usarla con tu proyecto o ejecuta los siguientes comandos para autorizar la CLI de gcloud y definir tu proyecto como predeterminado:

    gcloud auth login
gcloud config set project PROJECT_ID

Roles de gestión de identidades y accesos necesarios para la configuración

En esta guía se da por hecho que tienes el permiso roles/owner en tu proyecto. Si no eres el propietario de un proyecto, pídele a uno que te conceda permisos adicionales en el proyecto para que puedas hacer lo siguiente:

  • Para habilitar APIs, necesitas el permiso serviceusage.services.enable, que está incluido en el rol Administrador de uso de servicio (roles/serviceusage.serviceUsageAdmin). El propietario de un proyecto puede crear un rol personalizado con el permiso serviceusage.services.enable habilitado o asignarte el rol roles/serviceusage.serviceUsageAdmin, como se indica a continuación:

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/serviceusage.serviceUsageAdmin'

  • Para conceder permisos de gestión de identidades y accesos a usuarios y cuentas de servicio para que puedan usar la pasarela Connect, necesitas el rol Administrador de gestión de identidades y accesos de proyectos (roles/resourcemanager.projectIamAdmin), que puede conceder el propietario del proyecto con el siguiente comando:

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/resourcemanager.projectIamAdmin'

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 clústeres mediante la consola Google Cloud , no es necesario que habilites connectgateway.googleapis.com, pero sí que habilites las otras APIs.

gcloud services enable --project=PROJECT_ID  \
    connectgateway.googleapis.com \
    gkeconnect.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com

Verificar clústeres registrados

Solo se puede acceder a los clústeres registrados en la flota de tu proyecto a través de la pasarela Connect. Los clústeres de GKE on‐premise y en otras nubes públicas se registran automáticamente cuando se crean. Sin embargo, los clústeres de GKE en Google Cloud y los clústeres adjuntos deben registrarse por separado. Si necesitas registrar un clúster, sigue las instrucciones de nuestras guías de registro de clústeres. Ten en cuenta que los clústeres de GKE deben estar registrados en la flota para usar la pasarela.

Para comprobar que los clústeres se han registrado, ejecuta el siguiente comando:

gcloud container fleet memberships list

Debería ver una lista de todos los clústeres registrados, como en este ejemplo de salida:

NAME         EXTERNAL_ID
cluster-1    0192893d-ee0d-11e9-9c03-42010a8001c1
cluster-2    f0e2ea35-ee0c-11e9-be79-42010a8400c2

Conceder roles de gestión de identidades y accesos a usuarios

El acceso a los clústeres se controla mediante la gestión de identidades y accesos (IAM). Los roles de gestión de identidades y accesos necesarios para acceder a los clústeres mediante kubectl difieren ligeramente de los roles necesarios para acceder a los clústeres en la consola Google Cloud , tal como se explica en las siguientes secciones.

Asignar roles para acceder a través de kubectl

Como mínimo, los usuarios y las cuentas de servicio necesitan los siguientes roles de gestión de identidades y accesos para usar kubectl e interactuar con los clústeres a través de la pasarela Connect, a menos que el usuario tenga roles/owner en el proyecto:

  • roles/gkehub.gatewayAdmin: este rol permite a un usuario acceder a la API de la pasarela Connect para usar kubectl y gestionar el clúster. Este rol incluye el permiso gkehub.gateway.stream, que permite a los usuarios ejecutar los comandos attach, cp y exec kubectl. Para consultar los requisitos adicionales para ejecutar esos comandos, consulta Compatibilidad con la versión preliminar de los comandos.

    • Si un usuario solo necesita acceso de lectura a los clústeres conectados, puedes concederle roles/gkehub.gatewayReader.

    • Si un usuario necesita acceso de lectura o escritura a los clústeres conectados, puede concederle roles/gkehub.gatewayEditor.

  • roles/gkehub.viewer: este rol permite a un usuario obtener clústeres kubeconfigs.

Para obtener información sobre los permisos incluidos en estos roles, consulta Roles de GKE Hub en la documentación de gestión de identidades y accesos.

Puedes usar los siguientes comandos para conceder estos roles:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=GATEWAY_ROLE
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

donde:

  • MEMBER es la cuenta de usuario o de servicio, que tiene el formato user|serviceAccount:emailID. Por ejemplo:

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com

  • GATEWAY_ROLE puede ser roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o roles/gkehub.gatewayEditor.

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.

Asignar roles para acceder a través de la Google Cloud consola

Los usuarios que quieran interactuar con clústeres fuera de Google Cloud mediante la Google Cloud consola necesitan al menos los siguientes roles de gestión de identidades y accesos para ver clústeres:

  • roles/container.viewer. Este rol permite a los usuarios ver la página Clústeres de GKE y otros recursos de contenedores en la consola de Google Cloud . Para obtener más información sobre los permisos incluidos en este rol, consulta Roles de Kubernetes Engine en la documentación de gestión de identidades y accesos.

  • roles/gkehub.viewer. Este rol permite a los usuarios ver clústeres fuera de Google Cloud en la Google Cloud consola. Ten en cuenta que este es uno de los roles necesarios para acceder a kubectl. Si ya has asignado este rol a un usuario, no es necesario que lo vuelvas a hacer. Para obtener información sobre los permisos incluidos en este rol, consulta Roles de GKE Hub en la documentación de IAM.

    En los siguientes comandos, sustituye PROJECT_ID por el ID del proyecto host de la flota. Además, sustituye MEMBER por la dirección de correo o la cuenta de servicio del usuario con el formato user|serviceAccount:emailID. Por ejemplo:

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com
    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

Para obtener más información sobre cómo conceder roles de gestión de identidades y accesos, consulta el artículo Administra el acceso a proyectos, carpetas y organizaciones de la documentación de gestión de identidades y accesos.

Configurar la autorización RBAC

El servidor de la API de Kubernetes de cada clúster debe poder autorizar las solicitudes que procedan de la consola o de los comandos kubectl que se envíen a través de la pasarela Connect desde los usuarios y las cuentas de servicio que hayas especificado. Google Cloud Para ello, debes actualizar las políticas de control de acceso basado en roles (RBAC) en cada clúster al que quieras acceder a través de la puerta de enlace. Debe añadir o actualizar las siguientes políticas:

  • Una política de suplantación de identidad que autoriza al agente de Connect para enviar solicitudes al servidor de la API de Kubernetes en nombre de un usuario.
  • Una política de permisos que especifica los permisos que tiene el usuario en el clúster. Puede ser un rol a nivel de clúster, como clusterrole/cluster-admin o clusterrole/cloud-console-reader, o un rol a nivel de espacio de nombres, como role/default/pod-reader.

(Opcional) Crear un rol de cloud-console-reader

Los usuarios autenticados que quieran acceder a los recursos de un clúster en la Google Cloud consola deben tener los permisos de Kubernetes pertinentes. Si no quieres conceder a esos usuarios permisos más amplios, como los de un administrador del clúster, puedes crear un rol RBAC personalizado que incluya los permisos mínimos para ver los nodos, los volúmenes persistentes, los pods y las clases de almacenamiento del clúster. Puedes definir este conjunto de permisos creando un recurso ClusterRole RBACcloud-console-reader en el clúster.

cloud-console-reader concede a sus usuarios los permisos get, list y watch en los nodos, los volúmenes persistentes, los pods y las clases de almacenamiento del clúster, lo que les permite ver detalles sobre estos recursos.

kubectl

Para crear el cloud-console-reader ClusterRole y aplicarlo al clúster, ejecuta el siguiente comando:

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

A continuación, puede asignar este rol a los usuarios al configurar sus políticas de permisos, tal como se describe en la siguiente sección.

Crear y aplicar las políticas de RBAC necesarias

A continuación, se muestra cómo crear y aplicar las políticas de RBAC necesarias. La forma más sencilla de hacerlo es usar la CLI de gcloud para generar y aplicar las políticas adecuadas. Si lo prefieres, puedes crear un archivo de política de control de acceso basado en roles y aplicarlo con kubectl.

gcloud

Para generar y aplicar las políticas al clúster que elijas con gcloud CLI, ejecuta el siguiente comando:

gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply

Haz los cambios siguientes:

  • MEMBERSHIP_NAME: el nombre que se usa para representar de forma única el clúster en su flota. Puedes consultar cómo comprobar el nombre de la pertenencia de tu clúster en Obtener el estado de pertenencia a la flota.
  • ROLE: el rol de Kubernetes que quieres asignar a los usuarios del clúster. Por ejemplo, clusterrole/cluster-admin, clusterrole/cloud-console-reader o role/mynamespace/namespace-reader. Este rol ya debe existir antes de ejecutar el comando.
  • USERS: las direcciones de correo de los usuarios (cuentas de usuario o cuentas de servicio) a los que quieres conceder los permisos, en forma de lista separada por comas. Por ejemplo: --users=dana@example.com,test-acct@test-project.iam.gserviceaccount.com.
  • PROJECT_ID: el ID del proyecto en el que está registrado el clúster.
  • KUBECONFIG_PATH: la ruta de archivo local en la que está almacenado tu archivo kubeconfig, que contiene una entrada para el clúster. En la mayoría de los casos, es de $HOME/.kube/config.

  • KUBECONFIG_CONTEXT: el contexto del clúster tal y como aparece en el archivo kubeconfig. Puedes obtener el contexto actual desde la línea de comandos ejecutando kubectl config current-context. Tanto si usas el contexto actual como si no, asegúrate de que funciona para acceder al clúster ejecutando el siguiente comando:

    kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT

Después de ejecutar gcloud container fleet memberships generate-gateway-rbac, verá algo parecido a lo siguiente al final del resultado, que se ha truncado para que sea más fácil de leer

Validating input arguments.
Specified Cluster Role is: clusterrole/cluster-admin
Generated RBAC policy is:
--------------------------------------------
...
---
Applying the generate RBAC policy to cluster with kubeconfig: artifacts/kubeconfig, context: example-cluster-admin@example-cluster
Writing RBAC policy for user: 222larabrown@gmail.com to cluster.
Successfully applied the RBAC policy to cluster.

Es el contexto para acceder al clúster a través de la pasarela Connect.

Para obtener más información sobre el comando generate-gateway-rbac, consulta la guía de referencia de gcloud CLI.

kubectl

En el siguiente ejemplo se muestra cómo crear políticas adecuadas para un usuario (dana@example.com) y una cuenta de servicio (test@example-project.iam.gserviceaccount.com), dándoles a ambos permisos cluster-admin en el clúster y guardando el archivo de política como /tmp/gateway-rbac.yaml. Las políticas se aplican al clúster asociado al contexto actual:

cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gateway-impersonate
rules:
- apiGroups:
  - ""
  resourceNames:
  - dana@example.com
  - test@example-project.iam.gserviceaccount.com
  resources:
  - users
  verbs:
  - impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-impersonate
roleRef:
  kind: ClusterRole
  name: gateway-impersonate
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: connect-agent-sa
  namespace: gke-connect
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin
subjects:
- kind: User
  name: dana@example.com
- kind: User
  name: test@example-project.iam.gserviceaccount.com
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply policies to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH  -f /tmp/gateway-rbac.yaml

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

Compatible con los Controles de Servicio de VPC

Controles de Servicio de VPC proporciona una capa adicional de defensa de seguridad para los Google Cloud servicios que es independiente de Gestión de Identidades y Accesos (IAM). Mientras que Gestión de Identidades y Accesos permite un control de acceso granular basado en la identidad, Controles de Servicio de VPC ofrece una seguridad de perímetro basada en el contexto más amplia, incluido el control de la salida de datos a través del perímetro. Por ejemplo, puedes especificar que solo determinados proyectos puedan acceder a tus datos de BigQuery. Para obtener más información sobre cómo funciona Controles de Servicio de VPC para proteger tus datos, consulta la descripción general de Controles de Servicio de VPC.

Puedes usar Controles de Servicio de VPC con la pasarela Connect para aumentar la seguridad de los datos, una vez que te asegures de que se puede acceder a las APIs necesarias para usar la pasarela desde el perímetro de servicio especificado.

Siguientes pasos