Descripción general

En esta página, se describen los conceptos básicos de Cloud Identity and Access Management.

Google Cloud Platform (GCP) ofrece Cloud IAM, que te permite definir quién (identidad) tiene qué acceso (función) para qué recurso a fin de administrar el control de acceso.

IAM

Con Cloud IAM, puedes otorgar acceso detallado a recursos de GCP específicos y evitar el acceso no deseado a otros recursos. Cloud IAM te permite adoptar el principio de seguridad de menor privilegio, de manera que solo otorgas el acceso necesario a tus recursos.

En Cloud IAM, debes otorgar acceso a los miembros. Los miembros se pueden clasificar en los siguientes tipos:

  • Cuenta de Google
  • Cuenta de servicio
  • Grupo de Google
  • Dominio de G Suite
  • Dominio de Cloud Identity

Cuenta de Google

Una Cuenta de Google representa a un desarrollador, un administrador o cualquier otra persona que interactúe con GCP. Cualquier dirección de correo electrónico asociada a una Cuenta de Google puede ser una identidad, esto incluye gmail.com y otros dominios. Los usuarios nuevos pueden registrarse en una Cuenta de Google mediante la página de registro de Cuentas de Google.

Cuenta de servicio

Una cuenta de servicio es una cuenta que pertenece a tu aplicación en lugar de un usuario final individual. Cuando ejecutas código alojado en GCP, debes especificar la cuenta con la que se ejecutará. 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 en tu aplicación, consulta Introducción a la autenticación.

Grupo de Google

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

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

Ten en cuenta que los Grupos de Google no tienen credenciales de acceso y que no puedes usarlos a fin de establecer la identidad para hacer una solicitud de acceso a un recurso.

Dominio de G Suite

Un dominio de G Suite representa un grupo virtual de todas las Cuentas de Google que se crearon en la cuenta de G Suite de una organización. Los dominios de G Suite representan el nombre de dominio de Internet de tu organización (como example.com) y, cuando agregas un usuario a tu dominio de G Suite, se crea una Cuenta de Google nueva para el usuario dentro de este grupo virtual (como username@example.com).

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

Dominio de Cloud Identity

Un dominio de Cloud Identity es como un dominio de G Suite 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 características de G Suite. Para obtener más información, consulta Acerca de Cloud Identity.

allAuthenticatedUsers

Este es un identificador especial que representa a todos los que se autentican con una Cuenta de Google o una cuenta de servicio. No se incluyen los usuarios que no están autenticados, como los visitantes anónimos.

allUsers

Este es un identificador especial que representa a cualquier persona que esté en Internet, incluidos los usuarios autenticados y no autenticados. Ten en cuenta que algunas API de GCP requieren la autenticación de cualquier usuario que acceda al servicio y, en esos casos, allUsers solo implica autorización para todos los usuarios autenticados.

Cuando un miembro autenticado intenta realizar una solicitud, Cloud IAM toma una decisión de autorización sobre el permiso del miembro para realizar la operación en un recurso.

En esta sección, se describen las entidades y conceptos involucrados en el proceso de autorización.

Recurso

Puedes otorgar acceso a los usuarios de un recurso de GCP. Algunos de estos recursos son los proyectos, las instancias de Compute Engine y los depósitos de Cloud Storage.

Algunos servicios, como Cloud Pub/Sub y Compute Engine, permiten otorgar permisos de Cloud IAM con un nivel de detalle mayor que el nivel de proyecto. Por ejemplo, puedes otorgar a un usuario la función pubsub.subscriber para un tema particular de Cloud Pub/Sub o la función compute.instanceAdmin para una instancia específica de Compute Engine.

En otros casos, puedes otorgar permisos de Cloud IAM a nivel de proyecto. Así, todos los recursos dentro de ese proyecto heredan los permisos. Por ejemplo, para otorgar acceso a un depósito de Cloud Storage, debes otorgar el acceso al proyecto que contiene el depósito. Para obtener información sobre qué funciones se pueden otorgar en qué recursos, consulta Descripción de las funciones.

Permisos

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

En general, los permisos se corresponden 1:1 con los métodos REST. Es decir, cada servicio de GCP tiene un conjunto asociado de permisos para cada método REST que expone. Quien llama a ese método necesita estos permisos para la llamada. Por ejemplo, quien llama a Publisher.Publish() necesita el permiso pubsub.topics.publish.

No se les asignan permisos a los usuarios de forma directa. En su lugar, se les asigna una Función que contiene uno o más permisos.

Funciones

Una función es un grupo de permisos. No puedes asignar un permiso al usuario de forma directa; en su lugar, debes otorgarle una función. Cuando otorgas una función a un usuario, le otorgas todos los permisos que contiene esa función.

Permiso para la asignación de Funciones

En Cloud IAM existen tres tipos de funciones:

  • Funciones básicas: las funciones que siempre estuvieron disponibles en Google Cloud Platform Console y continuarán funcionando. Estas funciones son Propietario, Editor y Lector.

  • Funciones predefinidas: las funciones predefinidas son las funciones de Cloud IAM que proporcionan un control de acceso más detallado que las funciones básicas. Por ejemplo, la función predefinida Publicador de Pub/Sub (roles/pubsub.publisher) proporciona acceso solo para publicar mensajes en un tema de Cloud Pub/Sub.

  • Funciones personalizadas: las funciones que creas para adaptar los permisos a las necesidades de tu organización cuando las funciones predefinidas no las satisfacen.

Para saber cómo asignar una función a un usuario, consulta Otorga, cambia y revoca el acceso. Para obtener información sobre las funciones predefinidas detalladas de Cloud IAM disponibles, consulta Descripción de las funciones. Para obtener información sobre las funciones personalizadas, consulta Descripción de las funciones personalizadas y Crea y administra funciones personalizadas.

Política de IAM

Puedes otorgar funciones a los usuarios mediante una política de Cloud IAM, que es una colección de declaraciones que definen quién tiene qué tipo de acceso. Una política 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 Cloud IAM se representa con el objeto Policy de IAM. Un objeto Policy de IAM consiste en una lista de vinculaciones. Cada Binding vincula una lista de members a una role.

role es la función que deseas asignar al miembro. La role se especifica en la forma roles/<name of the role>. Por ejemplo, roles/storage.objectAdmin, roles/storage.objectCreator y roles/storage.objectViewer.

members contiene una lista de una o más identidades como se describe en la sección anterior de Conceptos relacionados con la identidad. Cada tipo de miembro se identifica con un prefijo, como una Cuenta de Google (user:), una cuenta de servicio (serviceAccount:), un Grupo de Google (group:) o un dominio de G Suite o Cloud Identity (domain:). En el fragmento de ejemplo siguiente, la función storage.objectAdmin se asigna a los siguientes miembros con el prefijo apropiado: user:alice@example.com, serviceAccount:my-other-app@appspot.gserviceaccount.com, group:admins@example.com y domain:google.com. La función objectViewer se asigna a user:bob@example.com.

El siguiente fragmento de código muestra la estructura de una política de Cloud IAM.

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

API de Política y de Cloud IAM

Cloud IAM proporciona un conjunto de métodos que puedes usar para crear y administrar políticas de control de acceso en recursos de GCP. A estos métodos los exponen los servicios que admiten Cloud IAM. Por ejemplo, a los métodos de Cloud IAM los exponen las API de Resource Manager, Cloud Pub/Sub y Cloud Genomics, entre otras.

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

  • setIamPolicy(): Te permite establecer políticas en tus recursos.
  • getIamPolicy(): Te permite obtener una política que se estableció antes.
  • testIamPermissions(): Te permite probar si quien llama 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 Cloud IAM.

Jerarquía de políticas

Los recursos de GCP se organizan de forma jerárquica: el nodo de la organización es el nodo raíz en la jerarquía, los proyectos son los secundarios de la organización y los otros recursos son los descendientes de los proyectos. Cada recurso tiene exactamente un elemento superior. Consulta el tema Jerarquía de recursos de Resource Manager para obtener más información.

El diagrama siguiente es un ejemplo de una jerarquía de recursos de GCP:

Jerarquía de recursos

Puedes establecer una política de Cloud IAM 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 del recurso superior. Si estableces una política en el nivel de organización, todos los proyectos secundarios la heredan de forma automática, y si estableces una política en el nivel de proyecto, la heredan todos sus recursos secundarios. La política vigente para un recurso es la unión de la política establecida en ese recurso y la política heredada de una jerarquía superior.

Esta herencia de políticas es transitiva; en otras palabras, los recursos heredan políticas de los proyectos, que heredan políticas de las carpetas, que heredan políticas de la organización. Por lo tanto, las políticas 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 Cloud Pub/Sub que reside en el proyecto example-prod. Si otorgas la función de Editor a micah@gmail.com para example-prod y la de Publicador a song@gmail.com para topic_a, en efecto le otorgas la función de Editor para topic_a a micah@gmail.com y la función de Publicador a song@gmail.com.

La jerarquía de políticas de Cloud IAM sigue la misma ruta de acceso que la jerarquía de recursos de GCP. Si cambias la jerarquía de recursos, también cambia la jerarquía de políticas. Por ejemplo, mover un proyecto a una organización actualizará su política de Cloud IAM para heredar la de la organización.

Las políticas secundarias no pueden restringir el acceso otorgado en un nivel superior. Por ejemplo, si otorgas a un usuario la función de Editor para un proyecto y la de Lector para un recurso secundario, el usuario tendrá la función de Editor para ese recurso.

Compatibilidad de Cloud IAM con servicios de GCP

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

Antes de Cloud IAM, solo se podían otorgar las funciones de Propietario, Editor o Lector. Estas funciones brindan un acceso muy amplio en un proyecto y no permiten una separación de tareas muy detallada. Los servicios de GCP ahora ofrecen funciones predefinidas adicionales que brindan un control de acceso más detallado que las funciones de Propietario, Editor y Lector. Por ejemplo, Compute Engine ofrece funciones como Administrador de la instancia y Administrador de la red, mientras que App Engine ofrece funciones como Administrador de la app y Administrador del servicio. Estas funciones predefinidas están disponibles además de las funciones heredadas de Propietario, Editor y Lector.

Si necesitas aún más control sobre los permisos, considera crear una Función personalizada.

Los siguientes productos ofrecen funciones predefinidas de Cloud IAM:

Para acceder a una lista completa de las funciones predefinidas, consulta Descripción de las funciones.

Puedes otorgar a los usuarios ciertas funciones para acceder a los recursos con un nivel de detalle mayor que el nivel de proyecto. Por ejemplo, puedes crear una política de control de acceso de Cloud IAM que otorgue a un usuario la función de Suscriptor para un tema de Cloud Pub/Sub en particular. Para obtener información sobre qué funciones se pueden otorgar en qué recursos, consulta Descripción de las funciones.

Próximos pasos

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Documentación de Cloud Identity and Access Management