Configurar la puerta de enlace de conexión

Esta guía está dirigida a los administradores de la plataforma que necesitan configurar la puerta de enlace de Connect para que la usen los usuarios y las cuentas de servicio de su proyecto. Esta configuración permite a los usuarios:

• Usa la consola de Google Cloud para acceder a clústeres registrados fuera de Google Cloud con su identidad de Google Cloud.

• Usa kubectl para acceder a los clústeres a través de la puerta de enlace de Connect.

Esta configuración solo permite la autenticación de usuarios y servicios en función de sus ID individuales, no de su pertenencia a Grupos de Google. Para configurar la asistencia de grupo adicional, consulta Configura la puerta de enlace de Connect mediante Grupos de Google.

Si no estás familiarizado con la puerta de enlace de Connect, consulta nuestra descripción general para obtener una explicación de los conceptos básicos y cómo funciona.

Antes de comenzar

1. Asegúrate de tener instaladas las siguientes herramientas de línea de comandos:

   • La versión más reciente de Google Cloud CLI, 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 instructions

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

2. initialize la CLI de gcloud para usar con tu proyecto o ejecuta los siguientes comandos a fin de autorizar la CLI de gcloud y configurar tu proyecto como el predeterminado:

   gcloud auth login
   gcloud config set project PROJECT_ID
   

Roles de IAM necesarias para la configuración

En esta guía, se supone que tienes el permiso roles/owner en tu proyecto. Si no eres propietario del proyecto, pídele a un propietario que te otorgue permisos adicionales en el proyecto para que puedas realizar las siguientes tareas:

• Para habilitar las API, necesitas el permiso serviceusage.services.enable, que se incluye en la función de administrador de Service Usage (roles/serviceusage.serviceUsageAdmin). El propietario de un proyecto puede crear un rol personalizado con el permiso serviceusage.services.enable habilitado o otorgarte roles/serviceusage.serviceUsageAdmin, de la siguiente manera:

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

• Para otorgar permisos de IAM a usuarios y cuentas de servicio a fin de que puedan usar la puerta de enlace de Connect, necesitas el rol Administrador de IAM del proyecto (roles/resourcemanager.projectIamAdmin), que el propietario del proyecto puede otorgar el siguiente comando:

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

Habilita la API

Para agregar la puerta de enlace al proyecto, habilita la API de puerta de enlace de Connect y las API de dependencia requeridas. Si tus usuarios solo desean autenticarse en los clústeres mediante la consola de Google Cloud, no necesitas habilitar connectgateway.googleapis.com, pero sí debes habilitar las API restantes.

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

Verifica los clústeres registrados

Solo se puede acceder a los clústeres registrados en la flota de tu proyecto a través de la puerta de enlace de Connect. Los clústeres de GKE locales 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 en 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 puerta de enlace.

Para verificar que se hayan registrado los clústeres, ejecuta el siguiente comando:

gcloud container fleet memberships list

Deberías ver una lista de todos tus clústeres registrados, como en este resultado de ejemplo:

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

Otorga roles de IAM a los usuarios.

El acceso a los clústeres se controla mediante Identity and Access Management (IAM). Los roles de IAM necesarios para acceder a clústeres mediante kubectl difieren de los roles para acceder a los clústeres en la consola de Google Cloud, como se explica en las siguientes secciones.

Otorga roles para acceder a través de kubectl

Como mínimo, los usuarios y las cuentas de servicio necesitan los siguientes roles de IAM para usar kubectl a fin de interactuar con los clústeres a través de la puerta de enlace de Connect, a menos que el usuario tenga roles/owner en el proyecto:

• roles/gkehub.gatewayAdmin: Este rol permite que un usuario acceda a la API de la puerta de enlace de Connect para usar kubectl a fin de administrar el clúster.

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

  • Si un usuario necesita acceso de lectura/escritura a clústeres conectados, puedes otorgar roles/gkehub.gatewayEditor.

• roles/gkehub.viewer: Este rol permite que un usuario recupere kubeconfigs del clúster.

Para obtener más información sobre los permisos incluidos en estas funciones, consulta funciones de GKE Hub en la documentación de IAM.

Puedes usar los siguientes comandos para otorgar estas funciones:

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 servicio o usuario que tiene el formato user|serviceAccount:emailID, por ejemplo:

  • user:[e-mail]
  • serviceAccount:[e-mail]

• GATEWAY_ROLE es roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o roles/gkehub.gatewayEditor.

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.

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

Los usuarios que deseen interactuar con clústeres fuera de Google Cloud mediante la consola de Google Cloud necesitan las siguientes funciones de IAM como mínimo para ver los clústeres:

• roles/container.viewer. Este rol permite que los usuarios vean la página de 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 IAM.

• roles/gkehub.viewer Este rol permite que los usuarios vean clústeres fuera de Google Cloud en la consola de Google Cloud. Ten en cuenta que este es uno de los roles necesarios para acceder a kubectl. Si ya otorgaste este rol a un usuario, no necesitas volver a otorgarlo. Para obtener detalles sobre los permisos incluidos en este rol, consulta Roles de GKE Hub en la documentación de IAM.

  En el siguiente comando, reemplaza PROJECT_ID por el ID del proyecto host de la flota. Además, reemplaza MEMBER por la dirección de correo electrónico o la cuenta de servicio del usuario mediante el formato user|serviceAccount:emailID, por ejemplo:

  • user:[e-mail]
  • serviceAccount:[e-mail]

  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 asignar los roles de IAM, consulta Administra el acceso a los proyectos, las carpetas y las organizaciones en la documentación de IAM.

Configura la autorización de RBAC

Cada servidor de la API de Kubernetes de cada clúster debe poder autorizar las solicitudes que provienen de la consola de Google Cloud o de los comandos de kubectl que provienen de la puerta de enlace de Connect de los usuarios y las cuentas de servicio especificados. Para garantizar esto, necesitas actualizar las políticas de control de acceso basado en roles (RBAC) en cada clúster que desees que sea accesible a través de la puerta de enlace. Debes agregar o actualizar las siguientes políticas:

• Una política de robo de identidad que autorice al agente de Connect a enviar solicitudes al servidor de la API de Kubernetes en nombre de un usuario.
• Una política de permisos que especifique qué permisos tiene el usuario en el clúster. Puede ser una función a nivel de clúster, como clusterrole/cluster-admin o clusterrole/cloud-console-reader, o una a nivel de espacio de nombres, como role/default/pod-reader.

(Opcional) Crea un rol cloud-console-reader

Los usuarios autenticados que quieran acceder a los recursos de un clúster en la consola de Google Cloud deben tener los permisos relevantes de Kubernetes para hacerlo. Si no quieres otorgar a esos usuarios permisos más amplios, como los de un administrador de clústeres, puedes crear un rol de 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. Para definir este conjunto de permisos, crea un recurso ClusterRole RBAC, cloud-console-reader, en el clúster.

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

kubectl

Para crear el ClusterRole cloud-console-reader 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

Luego, puedes otorgar este rol a los usuarios cuando configuren tus políticas de permisos, como se describe en la siguiente sección.

Crea y aplica 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 para ti. Como alternativa, si lo prefieres, puedes crear un archivo de política de RBAC y aplicarlo con kubectl.

gcloud

Para generar y aplicar las políticas a tu clúster elegido con la CLI de gcloud, 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

Reemplaza lo siguiente:

• MEMBERSHIP_NAME: Es el nombre que se usa para representar de forma única el clúster en su flota. Puedes averiguar cómo verificar el nombre de la membresía de tu clúster en Obtén el estado de la membresía de la flota.
• ROLE: Es la función de Kubernetes que deseas otorgar a los usuarios en el clúster, por ejemplo, clusterrole/cluster-admin, clusterrole/cloud-console-reader o role/mynamespace/namespace-reader. Este rol ya debe existir antes de que ejecutes el comando.
• USERS: Son las direcciones de correo electrónico de los usuarios (cuentas de usuario o cuentas de servicio) a los que deseas otorgar los permisos, como una lista separada por comas. Por ejemplo: --users=[e-mail],[e-mail]
• PROJECT_ID es el ID del proyecto en el que se registra el clúster.
• KUBECONFIG_PATH: Es la ruta de acceso local del archivo en el que el kubeconfig que contiene una entrada para el clúster se almacena. En la mayoría de los casos, es $HOME/.kube/config.

• KUBECONFIG_CONTEXT: Es el contexto del clúster como aparece en el archivo kubeconfig. Puedes obtener el contexto actual de la línea de comandos ejecutando kubectl config current-context. Independientemente de si usas o no el contexto actual, asegúrate de que funcione para acceder al clúster mediante la ejecución de un comando simple, como el siguiente:

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

Después de ejecutar gcloud container fleet memberships generate-gateway-rbac, verás algo como lo siguiente al final del resultado:

connectgateway_example-project-12345_global_example-membership-name

Este es el contexto para acceder al clúster a través de la puerta de enlace de Connect.

Para conocer más detalles sobre el comando generate-gateway-rbac, consulta la guía de referencia de la CLI de gcloud.

Si ves un error como ERROR: (gcloud.container.hub.memberships) Invalid choice: 'generate-gateway-rbac' cuando ejecutas este comando, actualiza Google Cloud CLI siguiendo la guía de actualización.

kubectl

En el siguiente ejemplo, se muestra cómo crear políticas adecuadas para un usuario ([e-mail]) y una cuenta de servicio ([e-mail]), otorgarles permisos de cluster-admin en el clúster y guardar el archivo de la política como /tmp/gateway-rbac.yaml. Luego, las políticas se aplican al clúster asociado con el contexto actual:

cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gateway-impersonate
rules:
- apiGroups:
  - ""
  resourceNames:
  - [e-mail]
  - [e-mail]
  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: [e-mail]
- kind: User
  name: [e-mail]
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

Puedes obtener más información sobre cómo especificar permisos de RBAC en Usa la autorización de RBAC.

Nota: Si bien en nuestros ejemplos se muestra cómo aplicar actualizaciones de políticas directamente con kubectl, en la vida real, te recomendamos que uses el controlador de políticas para crear y administrar políticas con el Sincronizador de configuración a fin de sincronizar esas políticas y otros parámetros de configuración en tus clústeres. Si deseas usar el controlador de políticas mientras utilizas generate-gateway-rbac para generar las políticas, puedes ejecutar el comando en modo de “ejecución de prueba” para generar las políticas en lugar de aplicarlas. Luego, puedes usar el Sincronizador de configuración para sincronizar las políticas generadas con todos tus clústeres.

Compatibilidad con los Controles del servicio de VPC

Los Controles del servicio de VPC proporcionan una capa adicional de defensa de seguridad para los servicios de Google Cloud, que es independiente de la administración de identidades y accesos (IAM). Si bien IAM habilita un control de acceso basado en la identidad detallado, los Controles del servicio de VPC permiten una seguridad perimetral basada en el contexto más amplia, que incluye el control de salida de datos en todo el perímetro. Por ejemplo, puedes especificar que solo ciertos proyectos puedan acceder a tus datos de BigQuery. Puedes encontrar más información sobre cómo funcionan los Controles del servicio de VPC para proteger tus datos en la descripción general de los Controles del servicio de VPC.

Puedes usar los Controles del servicio de VPC con la puerta de enlace de Connect para obtener seguridad adicional de los datos, una vez que te asegures de que se puede acceder a las API necesarias para usar la puerta de enlace desde el perímetro de servicio especificado.

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.