Configura el acceso de usuario para GKE Identity Service

Este documento está dirigido a los administradores de clústeres que ya configuraron clústeres para GKE Identity Service a través de las instrucciones de Configura clústeres para GKE Identity Service a nivel de la flota o Configura clústeres para GKE Identity Service con OIDC. Te indica cómo configurar (y restringir) el acceso al clúster configurado para los desarrolladores de tu organización y otros usuarios del clúster.

Configura el acceso del usuario

Luego de configurar un clúster, debes generar un archivo de configuración de acceso y distribuirlo a los usuarios del clúster. Este archivo permite que los usuarios accedan al clúster desde la línea de comandos con el proveedor que elegiste, como se describe en Accede a los clústeres con GKE Identity Service.

Solo con proveedores de OIDC, los usuarios también pueden acceder al clúster desde la consola de Google Cloud sin un archivo de acceso, como se describe en Trabaja con clústeres desde la consola de Google Cloud.

Genera la configuración de acceso

Console

(Solo Configuración a nivel de la flota)

Copia el comando de gcloud que se muestra y ejecútalo para generar el archivo.

gcloud

Si configuraste el clúster con la CLI de gcloud o si necesitas volver a generar el archivo, ejecuta el siguiente comando para generar el archivo:

gcloud anthos create-login-config --kubeconfig=KUBECONFIG

En él, KUBECONFIG es la ruta de acceso del 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.

Puedes ver los detalles de referencia completos de este comando, incluidos los parámetros opcionales adicionales, en la guía de referencia de la CLI de Google Cloud.

El nombre predeterminado para el archivo de configuración de acceso es kubectl-anthos-config.yaml, que es el nombre que la CLI de Google Cloud espera cuando usa el archivo para acceder. Si deseas cambiar esto a un nombre no predeterminado, consulta la sección relevante en Distribuye la configuración de acceso a continuación.

Para obtener información sobre la solución de problemas relacionados con el acceso de los usuarios, consulta Soluciona problemas de acceso de los usuarios.

Distribuye la configuración de acceso

Los siguientes son algunos enfoques posibles para distribuir el archivo de configuración:

• Aloja el archivo en una URL a la que se pueda acceder. Los usuarios pueden especificar esta ubicación con la marca --login-config cuando se ejecuta gcloud anthos auth login, lo que permite que la CLI de Google Cloud obtenga el archivo.

  Considera alojar el archivo en un host seguro. Consulta la marca --login-config-cert de la CLI de gcloud si deseas obtener más información sobre el uso de certificados de PEM para el acceso HTTPS seguro.

• Proporciona de forma manual el archivo a cada usuario, con información sobre dónde guardarlo en su máquina local: la CLI de Google Cloud espera encontrar el archivo en una ubicación predeterminada específica del SO. Si el archivo tiene una ubicación o un nombre no predeterminados, tus usuarios deben usar la marca --login-config para especificar la ubicación del archivo de configuración cuando ejecutan comandos en el clúster. Las instrucciones para que los usuarios guarden el archivo se encuentran en Accede a los clústeres con GKE Identity Service.

• Usa las herramientas internas para enviar el archivo de configuración de autenticación a la máquina de cada usuario. La CLI de Google Cloud espera encontrar el archivo en las siguientes ubicaciones, según el SO del usuario:

  Linux

  $HOME/.config/google/anthos/kubectl-anthos-config.yaml

  macOS

  $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

  Windows

  %APPDATA%\google\anthos\kubectl-anthos-config.yaml

Configura el acceso de un usuario a través de un proceso de autenticación alternativo

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En lugar de distribuir el archivo de configuración a todos los usuarios, puedes configurar un acceso de usuario a través de un proceso de autenticación alternativo. Los usuarios pueden autenticarse directamente en el servidor de GKE Identity Service con un nombre de dominio completamente calificado (FQDN). Para los proveedores de SAML, el acceso del usuario solo es compatible a través de este proceso de autenticación alternativo.

Nota: Este proceso de autenticación alternativo es compatible con GKE en VMware y GKE on Bare Metal de la versión 1.28. La versión de la CLI de gcloud a la que debes actualizar es 456.0.0.

Comparte el FQDN con los usuarios

En lugar de un archivo de configuración, los administradores de clústeres pueden compartir el FQDN de su servidor de GKE Identity Service con los usuarios. Los usuarios pueden usar este FQDN para acceder al clúster. La URL del servidor de GKE Identity Service se proporciona en uno de los siguientes formatos:

• https://CLUSTER-SERVER-NAME.com
• CLUSTER-SERVER-NAME.com

Acceso del usuario a través de certificados SNI de confianza

Los certificados de SNI simplifican el acceso al clúster, ya que aprovechan los certificados de confianza que ya están presentes en los dispositivos corporativos. Los administradores usan este certificado cuando se crea el clúster. Como usuario, debes usar el FQDN que proporciona tu administrador para acceder al clúster. Como alternativa, puedes usar un archivo kubeconfig seguro en el que el token se almacene después de una autenticación correcta.

Antes de ejecutar el siguiente comando, asegúrate de que el certificado que usa el servidor de GKE Identity Service sea de confianza para el dispositivo en el que se realiza la actividad de acceso del usuario.

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE

Reemplaza lo siguiente:

• APISERVER_URL: FQDN del servidor de GKE Identity Service.
• OUTPUT_FILE: usa esta marca si tu archivo kubeconfig se encuentra en una ubicación que no sea la predeterminada. Si se omite esta marca, los tokens de autenticación se agregan al archivo kubeconfig en la ubicación predeterminada. Por ejemplo: --kubeconfig /path/to/custom.kubeconfig

Acceso del usuario a través de certificados emitidos por la AC del clúster

Como usuario, si no usas un certificado SNI de confianza a nivel de clúster, la autoridad certificadora (AC) del clúster emite el certificado que usa el servicio de identidad. Los administradores distribuyen este certificado de la AC a los usuarios. Ejecuta el siguiente comando con el certificado de la AC del clúster para acceder a tu clúster:

gcloud anthos auth login --server APISERVER_URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE

Nota: Como recomendación, los usuarios pueden confiar en el certificado de la AC de sus dispositivos y navegadores si siguen las instrucciones específicas del dispositivo. Esta es una actividad que se realiza una sola vez. Una vez que el certificado de la AC sea de confianza, puedes acceder al clúster sin especificar el argumento --login-config-cert en el comando.

Configure el control de acceso basado en roles (RBAC)

La autenticación se suele combinar con el control de acceso basado en funciones (RBAC) de Kubernetes para proporcionar un control de acceso más preciso a clústeres para usuarios autenticados y cuentas de servicio. Siempre que sea posible, se recomienda crear políticas de RBAC que usen nombres de grupo en lugar de identificadores de usuario. Si vinculas las políticas de RBAC de forma explícita a grupos, puedes administrar los privilegios de acceso de los usuarios por completo con tu proveedor de identidad, por lo que el clúster no necesita actualizarse cada vez que cambian los privilegios de los usuarios. Ten en cuenta que, para configurar el control de acceso en función de la membresía de los grupos de seguridad con OIDC, debes asegurarte de que GKE Identity Service esté configurado para admitir la obtención de información de membresía de grupo de tu proveedor de identidad.

Por ejemplo, si deseas que ciertos usuarios autenticados tengan acceso a los pods del clúster, crea una ClusterRole que otorgue acceso a estos recursos, como se muestra en el siguiente ejemplo:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["pods"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

Luego, crea una ClusterRoleBinding correspondiente para otorgar los permisos en ClusterRole a los usuarios relevantes; en este caso, los miembros del grupo de seguridad us-east1-cluster-admins y el usuario con el ID u98523-4509823:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-admins
subjects:
  # Grants anyone in the "us-east1-cluster-admins" group
  # read access to Pods in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case-sensitive
  apiGroup: rbac.authorization.k8s.io
  # Grants this specific user read access to Pods in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Nota: Si el proveedor de identidad muestra un nombre de grupo que contiene caracteres de barra inversa dobles, uno de los caracteres de barra inversa debe omitirse cuando haces referencia al nombre del grupo en el recurso ClusterRoleBinding. Por ejemplo, si creaste un grupo llamado corp\\my-group, haz referencia a él en el recurso ClusterRoleBinding como corp\my-group. Esto se debe a que el primer carácter de barra inversa se trata como un carácter de escape.

En el siguiente ejemplo, este ClusterRoleBinding otorga permisos en ClusterRole al grupo relevante con el ID 12345678-BBBb-cCCCC-0000-123456789012. Ten en cuenta que esta configuración es relevante solo para los proveedores de Azure AD y está disponible para Google Distributed Cloud Virtual para clústeres de Bare Metal.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-reader-binding
subjects:
  # Retrieves group information for the group ID mentioned
- kind: Group
  name: 12345678-BBBb-cCCCC-0000-123456789012
  apiGroup: rbac.authorization.k8s.io

Para obtener más información sobre el uso del RBAC, consulta Configura el control de acceso basado en roles y Usa la autorización de RBAC.

Crea un rol de RBAC para el acceso a la consola de Google Cloud

Los usuarios autenticados a través de proveedores de OIDC pueden acceder a los clústeres desde la consola de Google Cloud y desde la línea de comandos.

Los usuarios autenticados que desean 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 deseas otorgar a esos usuarios permisos más extensos, 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. Puedes definir este conjunto de permisos si creas un recurso RBAC ClusterRole , 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 de 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 ClusterRole a los usuarios cuando configures tus políticas de permisos, como se describe en la sección anterior. Ten en cuenta que los usuarios también necesitan permisos de IAM para ver clústeres en la consola de Google Cloud.