Descripción general de IAM

En esta página, se describe cómo funciona el sistema de Identity and Access Management (IAM) de Google Cloud cómo puedes usarlo para administrar el acceso en Google Cloud.

IAM es una herramienta para administrar la autorización detallada para Google 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 los tiene, IAM le impide realizar 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 el conjunto de permisos que deseas otorgar a la principal.
  • Recurso: Es el Google Cloud recurso al que deseas permitir que acceda la principal.

Para otorgar permiso a la principal para acceder al recurso, le otorgas un rol en el recurso. Otorgas estos roles con una política de permisos.

Las políticas de permisos se adjuntan directamente a algunos Google Cloud recursos, que se organizan de forma jerárquica. Por ejemplo, los proyectos contienen recursos específicos del servicio. Esto significa que puedes otorgar acceso a un solo recurso o a un contenedor de recursos.

En las siguientes secciones, se describen estos conceptos con más detalle.

Principales

En Google Cloud controlas el acceso para las principales. Las principales representan una o más identidades que se autenticaron en Google Cloud.

En el pasado, las principales se conocían como miembros. Algunas APIs aún usan ese término.

Existen varios tipos de principales en IAM, pero se pueden dividir 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 Google Cloud recursos.

    Por ejemplo, las identidades federadas en grupos de identidad 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 Google Cloud los recursos.

    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 las principales otorgándoles roles.

Los roles son conjuntos de permisos. Cuando le otorgas un rol a una principal, le otorgas todos los permisos que contiene 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 especificas. Tienes control total sobre los permisos de estos roles. Sin embargo, tienen una carga de mantenimiento más alta 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 un acceso amplio a Google Cloud los servicios. 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 and permissions.

Recursos

La mayoríade 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 una principal en un recurso significa que la 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 recursos de contenedor, incluidos proyectos, carpetas y organizaciones. Estos recursos de contenedor se organizan de forma jerárquica, lo que permite que los recursos secundarios hereden las políticas de sus recursos superiores. Esto significa que otorgar un rol a una principal en un recurso de contenedor le da acceso a la principal tanto al recurso de contenedor como a los recursos de ese contenedor. Esta función te permite usar una sola concesión de rol para administrar el acceso 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 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 Google Cloud recurso.

Cada política de permisos contiene una lista de vinculaciones de roles que asocian roles de IAM con las principales a las 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 la principal está en una vinculación de roles 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 superior-inferior. Esta jerarquía se denomina jerarquía de recursos.

La Google Cloud jerarquía de recursos 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:

Jerarquía para los recursos de IAM.

Si estableces una política de permisos en un recurso de contenedor, la política de permisos 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 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 deseas 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 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 los recursos heredan las políticas de permisos de sus superiores. 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 superiores del recurso.

    Por ejemplo, supongamos que deseas otorgar permiso a alguien para escribir registros en un bucket de registros. Los buckets de registros no tienen sus propias políticas de permisos, por lo que, para otorgar este permiso a alguien, 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 principales que tienen acceso al recurso, debes ver la política de permisos del recurso y las políticas de permisos de los superiores del recurso. 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 permisos, consulta Usa la jerarquía de recursos para el control de acceso.

Control de acceso avanzado

Además de las políticas de permisos, 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 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 roles en una política de permisos para asegurarte de 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. Los cambios que realices también 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?