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 Google Cloud recurso al que deseas permitir que acceda el principal.
Para otorgarle permiso a la principal para acceder al recurso, debes otorgarle el rol en el recurso. Puedes otorgar 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 de las principales. Los principales representan una o más identidades que se autenticaron en Google Cloud.
En el pasado, las principales se denominaban miembros. Algunas APIs aún usan ese término.
Existen varios tipos de principales en IAM, pero se pueden divir en dos categorías amplias:
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 a usuarios humanos incluyen Cuentas de Google, Grupos de Google y identidades federadas en 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 los recursos deGoogle Cloud de acceso de tus cargas de trabajo.
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 en el formato service.resource.verb. A menudo, los permisos coinciden 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 un principal. En su lugar, les otorgas roles a los principales.
Los roles son conjuntos de permisos. Cuando otorgas un rol a un miembro, le otorgas todos los permisos de ese rol.
Existen tres tipos de roles:
Roles predefinidos: Son roles que administran los Google Cloud servicios. Estos roles contienen los permisos necesarios para realizar tareas comunes para 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 especifiques. Tienes control total sobre los permisos de estos roles. Sin embargo, tienen una carga de mantenimiento mayor 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 proporcionan acceso amplio a los servicios deGoogle Cloud . Estos roles pueden ser útiles para pruebas, pero no deben usarse en entornos de producción.
Para obtener más información sobre los roles y permisos, consulta Roles y permisos.
Recursos
La mayoría de los Google Cloud servicios 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 Google Cloud recursos. 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 otorga acceso al recurso del contenedor y a los recursos de ese contenedor. Esta función te permite usar una sola concesión de roles para otorgar acceso a un principal a varios recursos, incluidos los recursos 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 las políticas de permisos. En el pasado, estas políticas se denominaban 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 cómo se estructura 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 les 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 el principal está en una vinculación de roles que incluye un rol con los permisos necesarios, puede 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 superior-subordinada. 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 jerarquía de recursos de Google Cloud :
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 secundarios heredan de manera efectiva las políticas de permisos de sus recursos superiores.
La herencia de políticas tiene las siguientes implicaciones:
Puedes usar una sola vinculación de roles para otorgar acceso a varios recursos. Si quieres otorgarle a una principal acceso 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 deseas 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 heredan las políticas de permisos de sus elementos superiores. Para otorgar acceso principal a un recurso que no puede tener su propia política de permisos, bríndale un rol en uno de los antecesores del recurso.
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 los principales que tienen acceso al recurso, debes ver la política de permisos del recurso y las políticas de permisos de sus ancestros. 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 para las 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 mejor quién tiene acceso a qué recursos:
Tipos de políticas adicionales: IAM ofrece los siguientes tipos de políticas, además de las políticas de permisos:
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 puede acceder una principal. Las principales no pueden acceder a 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 roles en una política de permisos para garantizar que el rol solo se otorgue si se cumple la condición.
Puedes escribir condiciones en función de atributos, como el recurso en 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.
Administrador de acceso con privilegios (PAM): Con el Administrador de acceso con privilegios, puedes permitir que las principales soliciten y obtengan acceso temporal y auditable a los recursos. Por ejemplo, puedes exigir que las 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 obtener aprobaciones cuando soliciten 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.
- Para obtener instrucciones sobre cómo 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 de IAM disponibles, consulta Roles predefinidos.
- Para obtener ayuda con la elección de los roles predefinidos más adecuados, consulta Elige los roles predefinidos.
- 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