En esta página, se describe cómo funciona el sistema de Identity and Access Management (IAM) de Google Cloudy cómo puedes usarlo para administrar el acceso en Google Cloud.
IAM es una herramienta para administrar la autorización detallada deGoogle Cloud. En otras palabras, te permite controlar quién puede hacer qué en qué recursos.
Acceso en Google Cloud
Cada acción en Google Cloud requiere ciertos permisos. Cuando alguien intenta realizar una acción en Google 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 Google 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 Google Cloud , controlas el acceso para las entidades principales. Las principales representan una o más identidades que se autenticaron en Google 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 deGoogle Cloud .
Los tipos de principales que representan usuarios humanos incluyen las Cuentas de Google, los Grupos de Google y las identidades federadas en los grupos de identidades de personal.
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 deGoogle 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 Google 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 deGoogle 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 Google 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 Google 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.
Google 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 a una principal acceso 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 Google Cloud.
En el siguiente diagrama, se muestra la estructura de una política de permisos:
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
Google 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 Google 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 Google 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:
Tipos de políticas adicionales: Además de las políticas de permisos, IAM ofrece los siguientes tipos de políticas:
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.
Políticas de límite de acceso de las principales (PAB): Las políticas de límite de acceso de las principales definen y aplican los recursos a los que una principal puede acceder. Las principales no pueden acceder a los recursos a los que no son aptas para acceder, incluso si se les otorgó un rol en el recurso.
Para obtener más información sobre estas políticas, consulta Tipos de políticas.
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.
Privileged Access Manager (PAM): Con Privileged Access Manager, puedes permitir que los principales soliciten y obtengan acceso temporal y auditable a los recursos. Por ejemplo, puedes exigir que las entidades principales soliciten acceso cada vez que quieran ver un recurso sensible en lugar de otorgarles un rol de IAM de forma permanente.
También puedes configurar si los principales deben proporcionar justificaciones o recibir aprobaciones cuando solicitan acceso.
Para obtener más información sobre Privileged Access Manager, consulta la descripción general de Privileged Access Manager.
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 Google Cloud, consulta Administración de identidades para Google 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.
Pruébalo tú mismo
Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
Comenzar gratis