Autorización y control de acceso

Identity and Access Management (IAM) en Google Distributed Cloud (GDC) aislado te permite controlar quién tiene acceso a qué recursos y qué acciones puede realizar en ellos.

Comprender cómo funciona IAM en GDC te ayuda a administrar el acceso de manera eficaz, lo que garantiza que los miembros tengan los permisos que necesitan para desempeñar sus funciones y, al mismo tiempo, mantener la seguridad de tu entorno aislado.

Este documento está dirigido a públicos dentro de los grupos de administradores de plataformas y operadores de aplicaciones (como administradores de TI, ingenieros de seguridad o desarrolladores de aplicaciones) que desean comprender la autorización y el control de acceso en GDC aislado. Este documento también ayuda a los operadores de infraestructura a desarrollar una comprensión básica de los conceptos de control de acceso. Para obtener más información, consulta Públicos de la documentación de Google Distributed Cloud aislado.

El modelo de control de acceso

GDC estructura el acceso en torno a tres componentes principales: miembros (quién), roles (qué) y alcance del recurso (dónde).

El modelo de control de acceso

El control de acceso consta de dos etapas distintas: demostrar quién eres (autenticación) y determinar qué puedes hacer (autorización):

  • Autenticación: GDC no almacena cuentas ni contraseñas de usuario. GDC se conecta al proveedor de identidad (IdP) de tu organización para que puedas acceder con tus credenciales corporativas.
  • Autorización: Después de la autenticación, GDC IAM verifica los roles asignados para determinar a qué recursos puedes acceder y qué acciones puedes realizar.

Miembros

Un miembro es una identidad a la que puedes otorgar acceso a los recursos. GDC agrupa a los miembros en dos categorías principales según dónde los administres: identidades humanas y no humanas.

Identidades humanas

Las identidades humanas son los usuarios y grupos que acceden a GDC. En lugar de almacenar cuentas o contraseñas de usuario, GDC se conecta a los sistemas de acceso existentes de tu organización o IdPs (como Active Directory, LDAP o Okta) mediante protocolos de federación de identidad estándar como OpenID Connect (OIDC) o SAML 2.0.

Existen dos tipos de identidades humanas:

  • Usuarios: Usuarios humanos individuales que acceden al sistema con sus credenciales corporativas.
  • Grupos: Colecciones de usuarios humanos administrados dentro del IdP de tu organización. Si otorgas un rol a un grupo, se otorga automáticamente a todos los miembros de ese grupo.

GDC usa IdPs para identificar de forma única las identidades humanas. Debido a que tu entorno puede conectarse a varios IdPs (por ejemplo, si diferentes departamentos usan diferentes sistemas de acceso), GDC distingue entre los IdPs para garantizar que otorgues acceso a la persona correcta.

Cuando administras el acceso, GDC antepone automáticamente un prefijo de IdP único a todos los nombres de usuario y grupos externos:

  • Formato: idpprefix-username@domain.com (o idpprefix-group-name para grupos).
  • Ejemplo: Si el IdP de tu organización está configurado con el prefijo agency-a, y accedes como alice@example.com, GDC IAM te reconoce como agency-a-alice@example.com.

Identidades no humanas

Las identidades no humanas se denominan identidades de servicio (o cuentas de servicio). Puedes crearlas y administrarlas directamente en GDC (como recursos ProjectServiceAccount) para permitir que las aplicaciones, las secuencias de comandos o las cargas de trabajo automatizadas interactúen con las APIs de forma segura.

Debido a que GDC administra las cuentas de servicio de forma interna, no usan prefijos de IdP. En cambio, se identifican por su proyecto y nombre (por ejemplo, serviceAccount:projectName:serviceAccountName cuando se usa la CLI de gdcloud).

Para obtener más información, consulta Claves de cuentas de servicio seguras.

Permisos y roles

Un permiso es la autoridad para realizar una acción específica en un recurso (por ejemplo, crear una VM o borrar una base de datos). No otorgas permisos a los miembros directamente. En cambio, GDC agrupa los permisos en roles.

GDC ofrece dos tipos de roles:

  • Roles predefinidos: Son paquetes integrados de permisos creados y administrados por GDC. GDC proporciona una biblioteca completa de roles predefinidos adaptados a funciones y servicios específicos (desde roles amplios como Visualizador de proyectos hasta roles de servicio detallados como Administrador de proyectos de buckets o Visualizador de KMS).
  • Roles personalizados: Son paquetes de permisos definidos por el usuario que puedes crear cuando los roles predefinidos existentes no satisfacen las necesidades de tu organización.

Los permisos otorgados a través de los roles de IAM son puramente aditivos; otorgan acceso, pero no incluyen reglas de denegación. Cuando otorgas varios roles a un miembro, este recibe la unión de todos los permisos en esos roles. Para restringir o denegar el acceso a servicios específicos en tu organización, puedes configurar políticas de la organización.

Permiso del recurso

Siempre otorgas acceso en un nivel específico de la jerarquía de recursos de GDC. El alcance determina a qué recursos puede acceder el miembro. En los entornos multizona, los roles asignados en cualquier alcance se aplican automáticamente en todas las zonas de forma predeterminada.

Puedes otorgar roles en los siguientes alcances de recursos:

  • Organización: Es el contenedor de nivel superior de tu entorno. Los roles otorgados a nivel de la organización se aplican en toda la organización y se heredan automáticamente en todos los proyectos y recursos que contiene.
  • Proyecto: Es un contenedor dentro de la organización que se usa para agrupar recursos para equipos o aplicaciones específicos. Los proyectos sirven como límites de seguridad estrictos: los roles otorgados a nivel del proyecto se aplican solo a ese proyecto específico y a sus recursos (como máquinas virtuales, bases de datos y clústeres de Kubernetes).

Para obtener más información, consulta Jerarquía de recursos y Control de permisos para un universo multizona.

Cómo se autoriza el acceso

GDC administra y autoriza el acceso principalmente con un modelo de control de acceso basado en roles (RBAC). En un modelo RBAC, no asignas permisos directamente a usuarios o cargas de trabajo individuales. En cambio, asignas roles a los miembros en un alcance de recursos específico para determinar el acceso.

GDC implementa RBAC con los siguientes recursos personalizados de Kubernetes:

  • IAMRole: Define un paquete específico de permisos.
  • IAMRoleBinding: Vincula un miembro (un usuario humano, un grupo o una cuenta de servicio) a un IAMRole en un alcance de organización o proyecto.

Para otorgar acceso a recursos de la organización o del proyecto, puedes crear un IAMRoleBinding con la consola de GDC, la CLI de gdcloud o aplicando manifiestos de recursos personalizados (archivos YAML) con la CLI de kubectl.

Por ejemplo, para permitir que un miembro del equipo vea máquinas virtuales dentro de un proyecto, puedes crear un IAMRoleBinding en el alcance de ese proyecto que vincule la identidad del miembro a un rol de visualizador. Cuando el miembro intenta ver una máquina virtual, GDC verifica sus vinculaciones de roles activos, confirma que el rol asignado contenga el permiso requerido y autoriza la solicitud.

Si bien la consola de GDC y la CLI de gdcloud se conectan automáticamente a tus recursos, el acceso directo a la API con la CLI de kubectl requiere la autenticación en el clúster de Kubernetes o el servidor de la API específicos que alojan ese recurso mediante la generación de un archivo kubeconfig. Para obtener más detalles, consulta Accede y genera un archivo kubeconfig.

Para obtener más información sobre cómo administrar las vinculaciones de roles, consulta Otorga y revoca el acceso.

Diferencias entre IAM de GDC aislado y Google Cloud

Si tienes experiencia en la administración del acceso en Google Cloud, GDC usa conceptos similares, pero los implementa de manera diferente para operar dentro de una infraestructura aislada basada en Kubernetes.

En la siguiente tabla, se compara IAM en GDC con Google Cloud:

Función Descripción GDC aislado Google Cloud
Identidad del usuario (autenticación) Sistema de identidad que se usa para autenticar a los usuarios humanos. Federado con tu IdP externo con los prefijos de IdP requeridos (por ejemplo, idpprefix-user@domain.com). Cuentas de Google (como Gmail) o identidades corporativas federadas a través de Cloud Identity o Google Workspace.
Motor de autorización El sistema subyacente que evalúa y aplica los permisos. Principalmente, el control de acceso basado en roles (RBAC) de Kubernetes, en el que el servidor de la API evalúa las solicitudes de acceso de forma local en función de las vinculaciones de roles. Puedes usar políticas de la organización para establecer restricciones de recursos. El servicio global de Cloud IAM de Google. Evalúa las solicitudes de la API de forma centralizada en función de las políticas de acceso adjuntas en cualquier nivel de la jerarquía de recursos.
Vinculaciones de roles Cómo se asignan los miembros a los roles en recursos específicos. Recursos personalizados IAMRoleBinding individuales. Cada vinculación es un objeto que vincula a los miembros a un rol. Los permisos de roles de IAM son puramente aditivos (las reglas de denegación se pueden configurar por separado a través de políticas de la organización). Una sola política de acceso de IAM adjunta a cada recurso, carpeta u organización. Contiene varias vinculaciones que asignan miembros a roles y admite reglas condicionales o de denegación.
Cuentas de servicio Identidades no humanas que usan las aplicaciones y las cargas de trabajo automatizadas. Cuentas de servicio locales creadas dentro de un proyecto específico (ProjectServiceAccount). Las claves públicas se almacenan en el clúster, mientras que el cliente administra y protege las claves privadas de forma local. Identidades globales administradas de forma centralizada por Google. Google puede administrar las credenciales automáticamente o descargarlas como archivos de claves para autenticarse desde cualquier lugar.
Jerarquía de recursos Estructura de contenedor que se usa para organizar recursos y heredar permisos. Jerarquía de dos niveles: organización > proyectos Jerarquía de varios niveles: organización > carpetas > proyectos
Alcance de permisos multizona Cómo se evalúan y propagan los permisos en las zonas de disponibilidad o regiones. Usa RBAC de Kubernetes administrado por un servidor de la API global, que coordina y replica las vinculaciones de roles en los servidores de la API zonales para que el acceso se aplique en todas las zonas de forma predeterminada. Emplea un servicio de IAM global completamente administrado. Los permisos asignados en cualquier nivel de recursos son inherentemente globales y se aplican automáticamente en todas las regiones y zonas.
Herramientas cliente Interfaces principales, herramientas de CLI y APIs que se usan para administrar el acceso. Consola de GDC, CLI de gdcloud y APIs de KRM. Google Cloud Consola, gcloud CLI y APIs de REST o gRPC.
Acceso directo a la API Cómo se autentican las herramientas y las secuencias de comandos para administrar los recursos directamente con las APIs. El acceso directo a la API con la CLI de kubectl requiere la autenticación en el clúster de Kubernetes o el servidor de la API específicos que alojan ese recurso mediante la generación de un archivo kubeconfig. (La consola de GDC y la CLI de gdcloud se conectan automáticamente a los recursos). El acceso directo a la API con gcloud o los extremos de REST/gRPC usa credenciales centralizadas (gcloud auth login) que se aplican de forma global en todos los servicios sin necesidad de accesos específicos del clúster.

¿Qué sigue?