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

Comprender cómo funciona la 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 roles 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 la plataforma 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 GDC 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 de usuario ni contraseñas. 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 autenticarte, la IAM de GDC 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 de usuario o contraseñas, GDC se conecta a los sistemas de acceso existentes de tu organización o a los IdP (como Active Directory, LDAP u Okta) con protocolos estándar de federación de identidades, como OpenID Connect (OIDC) o SAML 2.0.

Existen dos tipos de identidades humanas:

  • Usuarios: Son usuarios humanos individuales que acceden al sistema con sus credenciales corporativas.
  • Grupos: Son colecciones de usuarios humanos que se administran dentro del IdP de tu organización. Otorgar un rol a un grupo lo otorga de forma automática a todos los miembros de ese grupo.

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

Cuando se administra 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, la IAM de GDC te reconoce como agency-a-alice@example.com.

Identidades no humanas

Las identidades no humanas se denominan identidades de servicio (o cuentas de servicio). Las creas y administras 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 su lugar, 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 Protege las claves de las cuentas de servicio.

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 su lugar, GDC agrupa los permisos en roles.

GDC ofrece dos tipos de roles:

  • Roles predefinidos: Son paquetes de permisos integrados que crea y administra GDC. GDC proporciona una biblioteca completa de roles predefinidos adaptados a funciones y servicios de trabajo específicos (que van 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 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 de esos roles. Para restringir o denegar el acceso a servicios específicos en toda 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 permiso determina a qué recursos puede acceder el miembro. En entornos de varias zonas, los roles asignados en cualquiera de los permisos se aplican de forma automática en todas las zonas de forma predeterminada.

Puedes otorgar roles en los siguientes permisos de recursos:

  • Organización: Es el contenedor de nivel superior de tu entorno. Los roles otorgados a nivel de la organización se aplican a 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 de equipos o aplicaciones específicos. Los proyectos funcionan como límites de seguridad estrictos: los roles otorgados a nivel de 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 de RBAC, no asignas permisos directamente a usuarios o cargas de trabajo individuales. En su lugar, asignas roles a los miembros en un permiso de recurso específico para determinar el acceso.

GDC implementa el 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 el permiso de una organización o un proyecto.

Para otorgar acceso a los 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 las máquinas virtuales dentro de un proyecto, puedes crear un IAMRoleBinding en el alcance de ese proyecto que vincule la identidad del miembro con un rol de visualizador. Cuando el miembro intenta ver una máquina virtual, GDC verifica sus vinculaciones de roles activas, confirma que el rol asignado contenga el permiso requerido y autoriza la solicitud.

Mientras que la consola de GDC y la CLI de gdcloud se conectan a tus recursos automáticamente, el acceso directo a la API con la CLI de kubectl requiere autenticarse 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 la 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 proporciona una comparación entre IAM en GDC y Google Cloud:

Función Descripción GDC aislado Google Cloud
Identidad del usuario (autenticación) Es el 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 Es 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 las políticas de la organización para establecer restricciones de recursos. El servicio global de Cloud IAM de Google Evalúa las solicitudes a 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 miembros a un rol. Los permisos de los roles de IAM son puramente aditivos (las reglas de denegación se pueden configurar por separado a través de las 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 reglas de denegación.
Cuentas de servicio Identidades no humanas que usan las aplicaciones y las cargas de trabajo automatizadas. Son 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 autenticarlas desde cualquier lugar.
Jerarquía de recursos Es la estructura de contenedores que se usa para organizar los recursos y heredar permisos. Jerarquía de dos niveles: organización > proyectos Jerarquía de varios niveles: organización > carpetas > proyectos
Alcance de los permisos de varias zonas Cómo se evalúan y propagan los permisos en las zonas o regiones de disponibilidad Usa el 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 y completamente administrado. Los permisos asignados en cualquier nivel de recurso son inherentemente globales y se aplican en todas las regiones y zonas de forma automática.
Herramientas para clientes Interfaces principales, herramientas de la CLI y APIs que se usan para administrar el acceso. Consola de GDC, gdcloud CLI y APIs de KRM. Consola de Google Cloud , 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 recursos directamente con las APIs El acceso directo a la API con la CLI de kubectl requiere autenticarse en el clúster de Kubernetes o el servidor de la API específicos que alojan ese recurso generando un archivo kubeconfig. (La consola de GDC y la CLI de gdcloud se conectan a los recursos automáticamente). El acceso directo a la API con gcloud o extremos de REST/gRPC usa credenciales centralizadas (gcloud auth login) que se aplican de forma global en todos los servicios sin necesidad de acceder a clústeres específicos.

¿Qué sigue?