En esta página, se describe cómo funciona el sistema de Identity and Access Management (IAM) de Trusted Cloud by S3NSy cómo puedes usarlo para administrar el acceso en Trusted Cloud.
IAM es una herramienta para administrar la autorización detallada deTrusted Cloud. En otras palabras, te permite controlar quién puede hacer qué en qué recursos.
Acceso en Trusted Cloud
Cada acción en Trusted Cloud requiere ciertos permisos. Cuando alguien intenta realizar una acción en Trusted Cloud, por ejemplo, crear una instancia de VM o ver un conjunto de datos, IAM primero verifica si tiene los permisos necesarios. Si no es así, IAM impedirá que realice la acción.
Otorgar permisos a alguien en IAM implica los siguientes tres componentes:
- Principal: Es la identidad de la persona o el sistema al que deseas otorgar permisos.
- Rol: Es la colección de permisos que deseas otorgar al principal.
- Recurso: Es el recurso Trusted Cloud al que deseas permitir que acceda la principal.
Para otorgarle permiso a la principal para acceder al recurso, debes otorgarle el rol en el recurso. Otorgas estos roles con una política de permiso.
En las siguientes secciones, se describen estos conceptos con más detalle.
Principales
En Trusted Cloud , controlas el acceso para las entidades principales. Las principales representan una o más identidades que se autenticaron en Trusted Cloud.
En el pasado, a las principales se las conocía como miembros. Algunas APIs aún usan ese término.
En IAM, existen varios tipos de principales, pero se pueden dividir en dos categorías generales:
Usuarios humanos: Algunos tipos de principales de IAM representan a usuarios humanos. Usas estos tipos de principales para administrar el acceso de tus empleados a los recursos deTrusted Cloud .
Por ejemplo, las identidades federadas en los grupos de identidades de personal representan a usuarios humanos.
Cargas de trabajo: Algunos tipos de principales de IAM representan cargas de trabajo. Usas estos tipos de principales cuando administras el acceso de tus cargas de trabajo a los recursos deTrusted Cloud .
Los tipos de principales que representan cargas de trabajo incluyen cuentas de servicio e identidades federadas en un grupo de identidades para cargas de trabajo.
Para obtener más información sobre las principales, consulta Principales de IAM.
Permisos y funciones
Los permisos determinan qué operaciones están permitidas en un recurso. En IAM, los permisos suelen representarse con el formato service.resource.verb. A menudo, los permisos se corresponden uno a uno con los métodos de la API de REST. Por ejemplo, el permiso resourcemanager.projects.list te permite enumerar los proyectos de Resource Manager.
No puedes otorgar permisos directamente a una principal. En su lugar, les otorgas permisos a los principales a través de roles.
Los roles son conjuntos de permisos. Cuando otorgas un rol a una principal, le otorgas todos los permisos de ese rol.
Existen tres tipos de roles:
Roles predefinidos: Roles que administran los servicios de Trusted Cloud . Estos roles contienen los permisos necesarios para realizar tareas comunes en cada servicio determinado. Por ejemplo, el rol de publicador de Pub/Sub (
roles/pubsub.publisher) proporciona acceso para publicar mensajes en un tema de Pub/Sub.Roles personalizados: Son roles que creas y que contienen solo los permisos que especificas. Tienes control total sobre los permisos de estos roles. Sin embargo, requieren más mantenimiento que los roles predefinidos y hay un límite para la cantidad de roles personalizados que puedes tener en tu proyecto y en tu organización.
Roles básicos: Son roles muy permisivos que brindan acceso amplio a los servicios deTrusted Cloud . Estos roles pueden ser útiles para realizar pruebas, pero no deben usarse en entornos de producción.
Para obtener más información sobre los roles y los permisos, consulta Roles y permisos.
Recursos
La mayoría de los servicios de Trusted Cloud tienen sus propios recursos. Por ejemplo, Compute Engine tiene recursos como instancias, discos y subredes.
En IAM, otorgas roles en un recurso. Otorgar un rol a un principal en un recurso significa que el principal puede usar los permisos de ese rol para acceder al recurso.
Puedes otorgar roles en un subconjunto de recursos de Trusted Cloud . Para obtener una lista completa de los recursos en los que puedes otorgar roles, consulta Tipos de recursos que aceptan políticas de permisos.
Trusted Cloud también tiene varios recursos de contenedor, incluidos proyectos, carpetas y organizaciones. Otorgar un rol a un principal en un recurso de contenedor le da acceso al recurso de contenedor y a los recursos de ese contenedor. Esta función te permite usar un solo otorgamiento de rol para dar acceso a una principal a varios recursos, incluidos aquellos en los que no puedes otorgar roles directamente. Para obtener más información, consulta Herencia de políticas en esta página.
Políticas de permiso
Puedes otorgar roles a las principales con políticas de permisos. En el pasado, estas políticas se conocían como políticas de IAM.
Una política de permisos es un objeto YAML o JSON que se adjunta a un recurso Trusted Cloud.
Cada política de permisos contiene una lista de vinculaciones de roles que asocian roles de IAM con los principales a los que se otorgan esos roles.
Cuando una principal autenticada intenta acceder a un recurso, IAM verifica la política de permisos del recurso para determinar si la principal tiene los permisos necesarios. Si la principal se encuentra en una vinculación de rol que incluye un rol con los permisos necesarios, se le permite acceder al recurso.
Para ver ejemplos de políticas de permisos y obtener información sobre su estructura, consulta Comprende las políticas de permisos.
Herencia de políticas
Trusted Cloud tiene recursos de contenedor, como proyectos, carpetas y organizaciones, que te permiten organizar tus recursos en una jerarquía principal-secundaria. Esta jerarquía se denomina jerarquía de recursos.
La jerarquía de recursos Trusted Cloud tiene la siguiente estructura:
- La organización es el nodo raíz de la jerarquía.
- Las carpetas son elementos secundarios de la organización o de otra carpeta.
- Los proyectos son elementos secundarios de la organización o de una carpeta.
- Los recursos de cada servicio son descendientes de proyectos.
El siguiente diagrama es un ejemplo de una Trusted Cloud jerarquía de recursos:
Si estableces una política de permisos en un recurso de contenedor, esta también se aplica a todos los recursos de ese contenedor. Este concepto se denomina herencia de políticas, ya que los recursos descendientes heredan de manera efectiva las políticas de permisos de sus recursos principales.
La herencia de políticas tiene las siguientes implicaciones:
Puedes usar una sola vinculación de rol para otorgar acceso a varios recursos. Si quieres otorgar acceso a una principal a todos los recursos de un contenedor, otórgale un rol en el contenedor en lugar de en los recursos del contenedor.
Por ejemplo, si quieres permitir que tu administrador de seguridad administre las políticas de permisos para todos los recursos de tu organización, puedes otorgarle el rol de administrador de seguridad (
roles/iam.securityAdmin) en la organización.Puedes otorgar acceso a recursos que no tienen sus propias políticas de permisos. No todos los recursos aceptan políticas de permisos, pero todos los recursos heredan políticas de permisos de sus principales. Para otorgar acceso a una principal a un recurso que no puede tener su propia política de permisos, otórgale un rol en uno de los recursos superiores.
Por ejemplo, imagina que quieres otorgarle a alguien permiso para escribir registros en un bucket de registros. Los buckets de registros no tienen sus propias políticas de permisos, por lo que, para otorgarle a alguien este permiso, puedes otorgarle el rol de escritor de buckets de registros (
roles/logging.bucketWriter) en el proyecto que contiene el bucket de registros.Para comprender quién puede acceder a un recurso, también debes ver todas las políticas de permisos que afectan al recurso. Para obtener una lista completa de las entidades principales que tienen acceso al recurso, debes ver la política de permisos del recurso y las políticas de permisos de los recursos superiores. La unión de todas estas políticas se denomina política de permisos efectiva.
Para obtener más información sobre la herencia de políticas de permiso, consulta Usa la jerarquía de recursos para el control de acceso.
Control de acceso avanzado
Además de las políticas de permiso, IAM proporciona los siguientes mecanismos de control de acceso para ayudarte a definir con mayor precisión quién tiene acceso a qué recursos:
- Políticas de denegación: Las políticas de denegación impiden que las principales usen ciertos permisos, incluso si se les otorga un rol con el permiso. Para obtener más información sobre las políticas de denegación, consulta Políticas de denegación.
Condiciones de IAM: Las condiciones de IAM te permiten definir y aplicar el control de acceso condicional basado en atributos. Puedes usar condiciones en varios tipos de políticas. Por ejemplo, puedes agregar una condición a una vinculación de rol en una política de permisos para garantizar que el rol solo se otorgue si se cumple la condición.
Puedes escribir condiciones basadas en atributos como el recurso de la solicitud y la hora de la solicitud.
Para obtener más información sobre las Condiciones de IAM, consulta Descripción general de las Condiciones de IAM.
Modelo de coherencia para la API de IAM
La API de IAM tiene coherencia eventual. En otras palabras, si escribes datos con la API de IAM y luego los lees de inmediato, la operación de lectura podría mostrar una versión anterior de los datos. Además, los cambios que realices pueden tardar en afectar las verificaciones de acceso.
Este modelo de coherencia afecta el funcionamiento de la API de IAM. Por ejemplo, si creas una cuenta de servicio y, luego, haces referencia a ella de inmediato en otra solicitud, la API de IAM podría decir que no se pudo encontrar la cuenta. Este comportamiento sucede porque las operaciones tienen coherencia eventual. Es posible que la nueva cuenta de servicio demore en leer las solicitudes de lectura.
¿Qué sigue?
- Para obtener información sobre cómo configurar identidades para Trusted Cloud, consulta Administración de identidades para Trusted Cloud.
- Si quieres obtener instrucciones para otorgar, cambiar y revocar roles de IAM a las principales, consulta Administra el acceso a proyectos, carpetas y organizaciones.
- Para obtener una lista de los roles disponibles de IAM, consulta Roles predefinidos.
- Para obtener ayuda con la elección de los roles predefinidos más adecuados, consulta Cómo encontrar los roles predefinidos adecuados.
- Para obtener más información sobre los tipos de políticas disponibles en IAM, consulta Tipos de políticas.