En esta página se describe cómo funciona el sistema de gestión de identidades y accesos (IAM) de Trusted Cloud by S3NSy cómo puedes usarlo para gestionar el acceso en Trusted Cloud.
IAM es una herramienta para gestionar la autorización pormenorizada deTrusted Cloud. Es decir, te permite controlar quién puede hacer qué en qué recursos.
Acceso en Trusted Cloud
Cada acción de Trusted Cloud requiere determinados 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 comprueba si tiene los permisos necesarios. Si no lo hacen, IAM les impedirá llevar a cabo la acción.
Para dar permisos a alguien en IAM, se necesitan los tres componentes siguientes:
- Principal: la identidad de la persona o el sistema al que quieres dar permisos.
- Rol: el conjunto de permisos que quieres conceder a la cuenta principal.
- Recurso: el Trusted Cloud recurso al que quieres que acceda la entidad principal.
Para dar permiso a la entidad principal para acceder al recurso, debes asignarle el rol en el recurso. Estos roles se conceden mediante una política de permiso.
En las secciones siguientes se describen estos conceptos con más detalle.
Directores
En Trusted Cloud , tú controlas el acceso de los principales. Las entidades representan una o varias identidades que se han autenticado en Trusted Cloud.
Antes, los principales se denominaban miembros. Algunas APIs siguen usando ese término.
Hay varios tipos de principales en IAM, pero se pueden dividir en dos categorías generales:
Usuarios humanos: algunos tipos de principales de IAM representan a usuarios humanos. Estos tipos de principales se usan para gestionar el acceso de tus empleados a los recursos deTrusted Cloud .
Por ejemplo, las identidades federadas de los grupos de identidades de Workforce representan a usuarios humanos.
Cargas de trabajo: algunos tipos de principales de IAM representan cargas de trabajo. Estos tipos principales se usan para gestionar el acceso a los recursos de tus cargas de trabajo. Trusted Cloud
Entre los tipos de principales que representan cargas de trabajo se incluyen las cuentas de servicio y las identidades federadas de un grupo de identidades de carga de trabajo.
Para obtener más información sobre las entidades, consulta Entidades de IAM.
Permisos y roles
Los permisos determinan qué operaciones se pueden realizar en un recurso. En IAM, los permisos suelen representarse en la forma service.resource.verb. A menudo, los permisos se corresponden con los métodos de la API REST. Por ejemplo, el permiso resourcemanager.projects.list te permite enumerar proyectos de Resource Manager.
No puedes conceder permisos directamente a una entidad principal. En su lugar, asignas permisos a las entidades concediéndoles roles.
Los roles son conjuntos de permisos. Cuando asignas un rol a una entidad principal, le das todos los permisos de ese rol.
Hay tres tipos de roles:
Roles predefinidos: roles gestionados por los servicios de Trusted Cloud . Estos roles contienen los permisos necesarios para realizar tareas habituales en cada servicio. Por ejemplo, el rol Editor de Pub/Sub (
roles/pubsub.publisher) proporciona acceso para publicar mensajes en un tema de Pub/Sub.Roles personalizados: son los roles que creas y que solo contienen 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 en el número de roles personalizados que puedes tener en tu proyecto y en tu organización.
Roles básicos: roles muy permisivos que proporcionan un amplio acceso a los servicios deTrusted Cloud . Estos roles pueden ser útiles para hacer pruebas, pero no deben usarse en entornos de producción.
Para obtener más información sobre los roles y los permisos, consulta el artículo Roles y permisos.
Recursos
La mayoría de los Trusted Cloud servicios tienen sus propios recursos. Por ejemplo, Compute Engine tiene recursos como instancias, discos y subredes.
En Gestión de identidades y accesos, se conceden roles en un recurso. Si se asigna un rol a una entidad principal en un recurso, significa que la entidad principal puede usar los permisos de ese rol para acceder al recurso.
Puedes conceder roles en un subconjunto de Trusted Cloud recursos. Para ver una lista completa de los recursos en los que puedes asignar roles, consulta Tipos de recursos que aceptan políticas de permiso.
Trusted Cloud también tiene varios recursos de contenedor, como proyectos, carpetas y organizaciones. Si se asigna un rol a una cuenta principal en un recurso de contenedor, esta tendrá acceso tanto al recurso de contenedor como a los recursos de ese contenedor. Esta función le permite usar una sola concesión de rol para dar acceso a un principal a varios recursos, incluidos los recursos a los que no puede conceder roles directamente. Para obtener más información, consulta la sección Herencia de políticas de esta página.
Permitir políticas
Puedes conceder roles a los principales mediante políticas de permiso. Antes, estas políticas se denominaban políticas de gestión de identidades y accesos.
Una política de permiso es un objeto YAML o JSON que se adjunta a un recurso Trusted Cloud.
Cada política de permiso contiene una lista de enlaces de rol que asocian roles de gestión de identidades y accesos con las entidades a las que se les han concedido esos roles.
Cuando una entidad autenticada intenta acceder a un recurso, Gestión de Identidades y Accesos comprueba la política de permiso del recurso para determinar si la entidad tiene los permisos necesarios. Si la entidad principal tiene un enlace de rol que incluye un rol con los permisos necesarios, podrá acceder al recurso.
Para ver ejemplos de políticas de permiso y obtener información sobre su estructura, consulta el artículo Información sobre las políticas de permiso.
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 de elementos principales y secundarios. 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 los proyectos.
El siguiente diagrama es un ejemplo de una jerarquía de recursos Trusted Cloud :
Si define una política de permiso en un recurso de contenedor, esta política 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 forma efectiva las políticas de permiso de sus recursos antecesores.
La herencia de políticas tiene las siguientes implicaciones:
Puedes usar un solo enlace de rol para conceder acceso a varios recursos. Si quieres dar acceso a una entidad principal a todos los recursos de un contenedor, concédele un rol en el contenedor en lugar de en los recursos del contenedor.
Por ejemplo, si quieres que tu administrador de seguridad gestione las políticas de permisos de todos los recursos de tu organización, puedes asignarle el rol Administrador de seguridad (
roles/iam.securityAdmin) en la organización.Puedes conceder acceso a recursos que no tengan sus propias políticas de permisos. No todos los recursos aceptan políticas de permiso, pero todos los recursos heredan las políticas de permiso de sus antecesores. Para dar acceso a una entidad principal a un recurso que no puede tener su propia política de permiso, asígnale un rol en uno de los ancestros del recurso.
Por ejemplo, supongamos que quieres dar permiso a un usuario para que escriba registros en un contenedor de registros. Los segmentos de registro no tienen sus propias políticas de permiso, por lo que, para conceder este permiso a alguien, puedes asignarle el rol Escritor de segmentos de registro (
roles/logging.bucketWriter) en el proyecto que contiene el segmento de registro.Para saber quién puede acceder a un recurso, también debes ver todas las políticas de permiso que afectan al recurso. Para obtener una lista completa de las entidades que tienen acceso al recurso, debes consultar la política de permisos del recurso y las políticas de permisos de los ancestros del recurso. La unión de todas estas políticas se denomina política de permiso efectiva.
Para obtener más información sobre la herencia de políticas de permiso, consulta Usar 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 quién tiene acceso a qué recursos:
- Políticas de denegación: las políticas de denegación impiden que las entidades usen determinados permisos, aunque se les haya asignado 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: te permiten definir y aplicar un control de acceso condicional basado en atributos. Puedes usar condiciones en varios tipos de políticas. Por ejemplo, puedes añadir una condición a una vinculación de rol en una política de permiso para asegurarte de que el rol solo se conceda 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 gestión de identidades y accesos, consulta Información general sobre las condiciones de gestión de identidades y accesos.
Modelo de coherencia de la API IAM
La API IAM tiene una coherencia final. En otras palabras, si escribes datos con la API IAM y, a continuación, lees esos datos inmediatamente, es posible que la operación de lectura devuelva una versión anterior de los datos. Además, los cambios que hagas pueden tardar en afectar a las comprobaciones de acceso.
Este modelo de coherencia afecta al funcionamiento de la API IAM. Por ejemplo, si creas una cuenta de servicio y, a continuación, haces referencia a ella en otra solicitud, la API IAM podría indicar que no se ha encontrado la cuenta de servicio. Este comportamiento se produce porque las operaciones son coherentes con el tiempo. La nueva cuenta de servicio puede tardar en aparecer en las solicitudes de lectura.
Siguientes pasos
- Para saber cómo configurar identidades para Trusted Cloud, consulta Gestión de identidades para Trusted Cloud.
- Para obtener instrucciones sobre cómo conceder, cambiar y revocar roles de gestión de identidades y accesos a principales, consulta el artículo Gestionar acceso a proyectos, carpetas y organizaciones.
- Para ver una lista de los roles de IAM disponibles, consulta Roles predefinidos.
- Para obtener ayuda a la hora de elegir los roles predefinidos más adecuados, consulta el artículo Elegir los roles predefinidos adecuados.
- Para obtener más información sobre los tipos de políticas disponibles en Gestión de Identidades y Accesos, consulta Tipos de políticas.