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 y cómo puedes usarlo para administrar el acceso en Google Cloud.

IAM te permite otorgar acceso detallado a recursos específicos de Google Cloud y ayuda a evitar el acceso a otros recursos. IAM te permite adoptar el principio de seguridad de privilegio mínimo, que indica que nadie debe tener más permisos que los que realmente necesita.

Cómo funciona IAM

Para administrar el control de acceso con la IAM, define quién (identidad) tiene qué acceso (rol) a qué recurso. Por ejemplo, las instancias de máquinas virtuales de Compute Engine, los clústeres de Google Kubernetes Engine (GKE) y los depósitos de Cloud Storage son recursos de Google Cloud. Las organizaciones, las carpetas y los proyectos que usas para organizar tus recursos también son recursos.

En IAM, el permiso para acceder a un recurso no se otorga directamente al usuario final. En su lugar, los permisos se agrupan en roles, y los roles se otorgan a las principales autenticadas. (Antes, IAM se refería a las principales como miembros. Algunas API aún usan este término).

Una política de permisos, también conocida como política de IAM, define y aplica qué roles se otorgan a qué principales. Cada política de permisos se adjunta a un recurso. Cuando una principal autenticada intenta acceder a un recurso, IAM verifica la política de permisos del recurso para determinar si la acción está permitida.

En el siguiente diagrama, se proporciona un ejemplo de la administración de permisos en IAM.

Una política de permisos con dos vinculaciones de roles. Las vinculaciones de roles asocian a principales específicos con roles específicos.

Este modelo de administración de acceso tiene tres partes principales:

  • Principal Un principal representa una identidad que puede acceder a un recurso. Cada principal tiene su propio identificador.
  • Función. Un rol es un grupo de permisos. Los permisos determinan qué operaciones están permitidas en un recurso. Cuando otorgas un rol a un miembro, otorgas todos los permisos que el rol contiene.
  • Política. La política de permisos es un conjunto de vinculaciones de roles que se asignan a una o más principales con roles individuales. Cuando desees definir quién (principal) tiene qué tipo de acceso (rol) en un recurso, debes crear una política de permisos y vincularla al recurso.

En el diagrama anterior, por ejemplo, la política de permisos vincula a las principales, como user@example.com, con roles, como App Engine Admin (roles/appengine.appAdmin). Si la política de permisos se vincula con un proyecto, las principales obtienen los roles especificados dentro del proyecto.

En el resto de esta página, se describen estos conceptos con más detalle.

En IAM, otorgas acceso a las principales, que representan una identidad que puede acceder a un recurso. En el contexto de la administración de acceso, los principales pueden ser uno de los siguientes tipos:

Para obtener detalles sobre los formatos de identificador de cada tipo de principal, consulta Identificadores de principal.

Cuentas de Google

Una Cuenta de Google representa a un desarrollador, un administrador o cualquier otra persona que interactúe con Google Cloud a través de una cuenta que creó con Google. Cualquier dirección de correo electrónico asociada a una Cuenta de Google se puede usar como dirección principal, incluidas las direcciones de correo electrónico de gmail.com o con otros dominios. Los usuarios nuevos pueden registrarse para obtener una Cuenta de Google en la página de registro de Cuentas de Google.

Cuentas de servicio

Una cuenta de servicio es una cuenta para una aplicación o una carga de trabajo de procesamiento en lugar de un usuario final individual. Cuando ejecutas código alojado en Google Cloud, debes especificar una cuenta de servicio para usarla como identidad de tu aplicación. Puedes crear tantas cuentas de servicio como sea necesario para representar los diferentes componentes lógicos de tu aplicación. Para obtener más información sobre el uso de una cuenta de servicio para autenticar tu aplicación, consulta Cuentas de servicio.

Grupos de Google

Un Grupo de Google es una colección de Cuentas de Google y cuentas de servicio que posee un nombre. Cada Grupo de Google tiene una dirección de correo electrónico única asociada con el grupo. Para encontrar la dirección de correo electrónico asociada con un Grupo de Google, haz clic en Acerca de en la página principal de cualquier Grupo de Google. Para obtener más información sobre los Grupos de Google, consulta la página principal de Grupos de Google.

Los Grupos de Google son una forma conveniente de aplicar controles de acceso a un grupo de usuarios. Puedes otorgar y cambiar los controles de acceso para un grupo completo de una sola vez, en lugar de hacerlo para usuarios individuales o cuentas de servicio uno por uno. También puedes agregar o quitar principales de un Grupo de Google en lugar de actualizar una política de permisos para agregar o quitar usuarios.

Los Grupos de Google no tienen credenciales de acceso y no puedes usarlos para establecer la identidad a fin de solicitar acceso a un recurso.

Cuentas de Google Workspace

Una cuenta de Google Workspace representa un grupo virtual de todas las Cuentas de Google que contiene. Las cuentas de Google Workspace se asocian al nombre de dominio de Internet de tu organización, como example.com. Cuando creas una Cuenta de Google para un usuario nuevo, como username@example.com, esa Cuenta de Google se agrega al grupo virtual de tu cuenta de Google Workspace.

Al igual que los Grupos de Google, no se pueden usar las cuentas de Google Workspace para establecer la identidad, pero permiten la administración conveniente de permisos.

Dominios de Cloud Identity:

Un dominio de Cloud Identity es como una cuenta de Google Workspace porque representa un grupo virtual de todas las Cuentas de Google en una organización. Sin embargo, los usuarios del dominio de Cloud Identity no tienen acceso a las aplicaciones y las funciones de Google Workspace. Para obtener más información, consulta Acerca de Cloud Identity.

allAuthenticatedUsers

El valor allAuthenticatedUsers es un identificador especial que representa a todas las cuentas de servicio y a todos los usuarios de Internet que se autenticaron con una Cuenta de Google. Este identificador incluye cuentas que no están conectadas a una cuenta de Google Workspace o a un dominio de Cloud Identity, como Cuentas de Gmail personales. Los usuarios que no están autenticados, como los visitantes anónimos, no están incluidos.

Este tipo de principal no incluye las identidades federadas, que administran los proveedores de identidad externos (IdP). Si usas la federación de identidades de personal o la federación de identidades para cargas de trabajo, no uses allAuthenticatedUsers. En su lugar, usa una de las siguientes opciones:

Algunos tipos de recursos no admiten este tipo de principal.

allUsers

El valor allUsers es un identificador especial que representa a cualquier persona que esté en Internet, incluidos los usuarios autenticados y no autenticados.

Algunos tipos de recursos no admiten este tipo de principal.

Identidades federadas en un grupo de identidad de personal.

Una identidad federada en un grupo de identidades de personal es una identidad de usuario que administra un IdP externo y se federa con la federación de identidades de personal. Puedes usar una identidad específica en un grupo de identidades del personal, o bien puedes usar ciertos atributos para especificar un grupo de identidades de usuario en un grupo de identidades del personal. Para obtener información sobre los identificadores principales de identidades federadas, consulta Identificadores principales.

Identidades federadas en un grupo de identidades para cargas de trabajo

Una identidad federada en un grupo de identidades para cargas de trabajo es una identidad de carga de trabajo que administra un IdP externo y se federa con la federación de identidades para cargas de trabajo. Puedes usar una identidad de carga de trabajo específica en un grupo de identidades para cargas de trabajo, o bien puedes usar ciertos atributos para especificar un grupo de identidades de carga de trabajo en un grupo de identidades para cargas de trabajo. Para obtener información sobre los identificadores principales de las identidades federadas, consulta Identificadores principales.

Pods de GKE

Las cargas de trabajo que se ejecutan en GKE usan la Workload Identity Federation for GKE para acceder a los servicios de Google Cloud. Para obtener más información sobre los identificadores principales de los pods de GKE, consulta Consulta los recursos de Kubernetes en las políticas de IAM.

Recurso

Si un usuario necesita acceder a un recurso específico de Google Cloud, puedes otorgar al usuario un rol para ese recurso. Algunos de estos recursos son los proyectos, las instancias de Compute Engine y los depósitos de Cloud Storage.

Algunos servicios permiten que se otorguen permisos de IAM con un nivel de detalle mayor que el nivel de proyecto. Por ejemplo, puedes otorgar el rol de administrador de almacenamiento (roles/storage.admin) a un usuario para un bucket de Cloud Storage específico o puedes otorgar el rol de administrador de instancias de Compute (roles/compute.instanceAdmin) a un usuario para una instancia específica de Compute Engine.

En otros casos, puedes otorgar permisos de IAM a nivel de proyecto. Así, todos los recursos dentro de ese proyecto heredan los permisos. Por ejemplo, para otorgar acceso a todos los bucket s de Cloud Storage en un proyecto, otorga acceso al proyecto en lugar de a cada bucket individual. Para otorgar acceso a todas las instancias de Compute Engine en un proyecto, otorga acceso al proyecto en lugar de a cada instancia individual.

Si quieres obtener información sobre qué roles se pueden otorgar en qué recursos, dirígete a Comprende los roles y consulta la columna Recurso más bajo para un rol determinado.

Permisos

Los permisos determinan qué operaciones están permitidas en un recurso. En el mundo de IAM, los permisos se representan en la forma de service.resource.verb, por ejemplo, pubsub.subscriptions.consume.

Los permisos suelen coincidir uno a uno con los métodos de la API de REST. Es decir, cada servicio de Google Cloud tiene un conjunto de permisos asociado para cada método de la API de REST que expone. El emisor de ese método necesita esos permisos para la llamada. Por ejemplo, si usas Pub/Sub y necesitas llamar al método topics.publish(), debes tener el permiso pubsub.topics.publish para ese tema.

No otorgas permisos a los usuarios directamente. En su lugar, identificas los roles que contienen los permisos adecuados y, luego, otorgas esos roles al usuario. Para obtener una lista de todos los permisos disponibles y los roles que los contienen, consulta la referencia de permisos.

Roles

Un rol es un grupo de permisos. No puedes otorgar un permiso directamente al usuario. En su lugar, les otorgas un rol. Cuando otorgas un rol a un usuario, le otorgas todos los permisos que contiene ese rol.

Permiso para la asignación de roles.

Existen varios tipos de roles en IAM:

  • Roles básicos: Son los roles que siempre estuvieron disponibles en la consola de Google Cloud. Son las funciones de propietario, editor y visualizador.

  • Roles predefinidos: Son los roles que brindan un control de acceso más detallado que los roles básicos. Por ejemplo, el rol predefinido de publicador de Pub/Sub (roles/pubsub.publisher) proporciona acceso solo para publicar mensajes en un tema de Pub/Sub.

  • Roles personalizados: Son roles que creas para adaptar los permisos a las necesidades de tu organización cuando los roles predefinidos no las satisfacen.

Si deseas obtener más información sobre los roles, consulta los siguientes recursos:

Política de permisos

Cuando una principal autenticada intenta acceder a un recurso, IAM verifica la política de permisos del recurso para determinar si la acción está permitida.

Puedes otorgar roles a los usuarios mediante la creación de una política de permisos, que es una colección de declaraciones que definen quién tiene qué tipo de acceso. Una política de permisos se adjunta a un recurso y se usa para aplicar el control de acceso cada vez que se accede a ese recurso.

Política de IAM.

Una política de permisos consiste en una lista de vinculaciones de roles. Una vinculación de rol une una lista de principales con un rol.

  • role: El rol que deseas otorgar a la principal. role se especifica con la forma roles/service.roleName. Por ejemplo, Cloud Storage proporciona las funciones roles/storage.objectAdmin, roles/storage.objectCreator y roles/storage.objectViewer, entre otras.

  • members: Es una lista de una o más principales, como se describe en la sección Conceptos relacionados con la identidad de este documento. Cada tipo de principal se identifica con un prefijo, como una Cuenta de Google (user:), una cuenta de servicio (serviceAccount:), un Grupo de Google (group:), una cuenta de Google Workspace o un dominio de Cloud Identity (domain:). En el siguiente fragmento de código de ejemplo, se otorga el rol storage.objectAdmin a los siguientes principales con el prefijo apropiado: user:my-user@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com y group:my-group@example.com. La función objectViewer se otorga a user:my-user@example.com.

En el siguiente fragmento de código, se muestra la estructura de una política de permisos.

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": [
        "user:my-user@example.com",
        "serviceAccount:my-other-app@appspot.gserviceaccount.com",
        "group:my-group@example.com"
      ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:my-user@example.com"
      ]
    }
  ]
}

API de IAM y de políticas

IAM proporciona un conjunto de métodos que puedes usar para crear y administrar políticas de permisos en los recursos de Google Cloud. Los servicios que son compatibles con IAM exponen estos métodos. Por ejemplo, Resource Manager, Pub/Sub y la API de Cloud Life Sciences exponen los métodos de IAM, por nombrar algunos.

A continuación, se describen los métodos de IAM:

  • setIamPolicy(): Configura políticas de permisos en tus recursos.
  • getIamPolicy(): Obtiene una política de permisos que se configuró con anterioridad.
  • testIamPermissions(): Comprueba si el emisor tiene los permisos especificados para un recurso.

Puedes encontrar los temas de referencia de la API para estos métodos en la documentación de cada servicio que admite IAM.

Jerarquía de recursos

Los recursos de Google Cloud están organizados de forma jerárquica de la siguiente manera:

  • 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.

Cada recurso tiene exactamente un elemento superior. Para obtener más información, consulta Jerarquía de recursos.

El siguiente diagrama es un ejemplo de una jerarquía de recursos de Google Cloud.

Jerarquía para los recursos de IAM.

Puedes establecer una política de permisos en cualquier nivel de la jerarquía de recursos: el nivel de organización, de carpeta, de proyecto o de recurso. Los recursos heredan las políticas de permisos de todos sus recursos superiores. La política de permiso efectiva para un recurso es la unión de la política de permisos establecida en ese recurso y las políticas de permisos heredadas desde una jerarquía superior.

Esta herencia de políticas es transitiva; en otras palabras, los recursos heredan las políticas de permisos del proyecto, que heredan políticas de permisos de las carpetas, que heredan políticas de permisos de la organización. Por lo tanto, las políticas de permisos del nivel de organización también se aplican al nivel de recursos.

Por ejemplo, en el diagrama anterior, topic_a es un recurso de Pub/Sub que reside en el proyecto example-prod. Como resultado, si otorgas el rol de editor a un usuario en example-prod, le otorgas el rol de editor de topic_a.

Las políticas de permisos para recursos secundarios se heredan de las políticas de permisos en sus recursos superiores. Por ejemplo, si otorgas a un usuario el rol de editor para un proyecto y el de visualizador para un recurso secundario, el usuario tendrá el rol de editor para ese recurso. Si cambias la jerarquía de recursos, también se cambia la herencia de políticas. Por ejemplo, mover un proyecto a una organización hace que este herede de la política de permisos de la organización.

Compatibilidad de IAM con los servicios de Google Cloud

Con IAM, se verifica cada método de API en todos los servicios de Google Cloud a fin de garantizar que la cuenta que realiza la solicitud a la API tenga el permiso adecuado para usar el recurso.

Los servicios de Google Cloud ofrecen roles predefinidos que proporcionan un control de acceso detallado. Por ejemplo, Compute Engine ofrece roles como administrador de instancias de Compute y administrador de red de Compute, mientras que Cloud Storage ofrece roles como administrador de carpetas de almacenamiento y usuario de objetos de almacenamiento.

Las funciones predefinidas están disponibles para la mayoría de los servicios de Google Cloud. Para obtener más información, consulta la lista de todas los roles predefinidos. Si necesitas aún más control sobre los permisos, considera crear un rol personalizado.

Puedes otorgar a los usuarios ciertos roles para acceder a los recursos con un nivel de detalle mayor que el nivel de proyecto. Por ejemplo, puedes crear una política de permisos que otorgue a un usuario el rol de suscriptor para un tema de Pub/Sub en particular. La lista de todos los roles predefinidos muestra el nivel más bajo, o el tipo más detallado, de recurso que acepta cada rol.

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?

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