Identity and Access Management

Uso

En esta página, se proporciona una descripción general Identity and Access Management (IAM) y su uso para controlar el acceso a los recursos de buckets, carpetas administradas y objetos en Cloud Storage.

Descripción general

IAM te permite controlar quién tiene acceso a los recursos en tu proyecto de Google Cloud. En los recursos, se incluyen los buckets de Cloud Storage, las carpetas administradas dentro de los buckets y los objetos almacenados en ellos, además de otras entidades de Google Cloud, como las instancias de Compute Engine.

Los principales son “quienes” están en IAM. Los principales pueden ser usuarios individuales, grupos, dominios o incluso el público en general. A los principales se les otorgan roles, lo que les permite realizar acciones en Cloud Storage y en Google Cloud de manera más general. Cada rol es una colección de uno o más permisos. Los permisos son las unidades básicas de IAM: cada uno te permite realizar una acción determinada.

Por ejemplo, el permiso storage.objects.create te permite crear objetos. Este permiso se encuentra en roles, como el creador de objetos de almacenamiento (roles/storage.objectCreator), que otorga los permisos útiles para crear objetos en un bucket y, el administrador de objetos de almacenamiento (roles/storage.objectAdmin), que otorga una amplia gama de permisos para trabajar con objetos.

La colección de roles de IAM que configuras en un recurso se denomina política de IAM. El acceso otorgado por estos roles se aplica al recurso en el que se establece la política y a los recursos que contiene ese recurso. Por ejemplo, puedes establecer una política de IAM en un bucket que otorgue a un usuario control administrativo de ese bucket y sus objetos. También puedes establecer una política de IAM en el proyecto general que otorgue a otro usuario la capacidad de ver objetos en cualquier bucket dentro de ese proyecto.

Si tienes un recurso de la organización de Google Cloud, también puedes usar las políticas de denegación de IAM para denegar el acceso a los recursos. Cuando se adjunta una política de denegación a un recurso, la principal de la política no puede usar el permiso especificado para acceder al recurso ni a ningún subrecurso dentro de él, sin importar los roles que se le otorguen. Las políticas de denegación anulan cualquier política de permisos de IAM.

Permisos

Con los permisos, las principales pueden realizar acciones específicas en buckets, objetos o carpetas administradas en Cloud Storage. Por ejemplo, con el permiso storage.buckets.list, una principal puede enumerar los buckets de tu proyecto. No otorgas permisos a las principales de forma directa, sino roles, que incluyen uno o más permisos agrupados dentro de ellas.

Si deseas ver una lista de referencia de los permisos de IAM que se aplican a Cloud Storage, consulta Permisos de IAM para Cloud Storage.

Funciones

Las funciones son un paquete de uno o más permisos. Por ejemplo, el rol de visualizar de objetos de almacenamiento (roles/storage.objectViewer) contiene los permisos storage.objects.get y storage.objects.list. Otorgas roles a las principales, lo que les permite realizar acciones en los buckets, las carpetas administradas y los objetos de tu proyecto.

Si deseas ver una lista de referencia de las funciones de IAM que se aplican a Cloud Storage, consulta Funciones de IAM para Cloud Storage.

Otorga roles a nivel de proyecto, de bucket o de carpeta administrada

Puedes otorgar roles a las principales a nivel de proyecto, de bucket o de carpeta administrada. Los permisos otorgados por esos roles se aplican de forma aditiva en toda la jerarquía de recursos. Puedes otorgar roles en diferentes niveles de la jerarquía de recursos para obtener un mayor nivel de detalle en tu modelo de permisos.

Por ejemplo, supongamos que deseas otorgar a un usuario permiso para leer objetos en cualquier bucket dentro de un proyecto, pero crear objetos solo en el bucket A. Para lograrlo, puedes otorgar al usuario la función de visualizador de objetos de almacenamiento (roles/storage.objectViewer) del proyecto, que le permite leer cualquier objeto almacenado en cualquier bucket dentro del proyecto. La función de creador de objetos de Storage (roles/storage.objectCreator) para el bucket A, que permite al usuario crear objetos solo en ese bucket.

Algunos roles se pueden usar en todos los niveles de la jerarquía de recursos. Cuando se usan a nivel de proyecto, los permisos que contienen se aplican a todos los depósitos y objetos del proyecto. Cuando se usan a nivel de bucket, los permisos solo se aplican a un bucket específico y a los objetos que contenga. Algunos ejemplos de estos roles son los roles de administrador de almacenamiento (roles/storage.admin), visualizador de objetos de almacenamiento (roles/storage.objectViewer) y creador de objetos de almacenamiento (roles/storage.objectCreator).

Algunas funciones solo se pueden aplicar a un nivel. Por ejemplo, solo puedes aplicar el rol de propietario de objetos heredados de almacenamiento (roles/storage.legacyObjectOwner) a nivel del bucket o de la carpeta administrada. Los roles de IAM que te permiten controlar las políticas de denegación de IAM solo se pueden aplicar a nivel de organización.

Relación con las LCA

Además de IAM, tus buckets y objetos pueden usar un sistema de control de acceso heredado llamado listas de control de acceso (LCA) si la función de acceso uniforme a nivel del bucket no está habilitada para tu bucket. Por lo general, debes evitar usar LCA y habilitar el acceso uniforme a nivel de bucket para tu bucket. En esta sección, se explica lo que debes tener en cuenta si permites el uso de LCA para un bucket y los objetos que contiene.

Los roles de IAM del bucket heredado funcionan en conjunto con las LCA del bucket . Cuando agregas o quitas un rol del bucket heredado, tus cambios se reflejan en las LCA asociadas con el bucket. De manera similar, cambiar una LCA específica del bucket hace que se actualice el rol de IAM del bucket heredado correspondiente para el bucket.

Función del bucket heredado LCA equivalente
Lector de buckets heredados de almacenamiento (roles/storage.legacyBucketReader) Lector del bucket
Escritor de buckets heredados de almacenamiento (roles/storage.legacyBucketWriter) Escritor del bucket
Propietario de buckets heredados de almacenamiento (roles/storage.legacyBucketOwner) Propietario del bucket

Todos los demás roles de IAM a nivel de bucket, incluidos los roles de IAM de objeto heredado, funcionan de forma independiente de las LCA. Del mismo modo, todos los roles de IAM a nivel de proyecto funcionan de forma independiente de las LCA. Por ejemplo, si le asignas a un usuario el rol de visualizador de objetos de almacenamiento (roles/storage.objectViewer), las LCA no se modificarán.

Debido a que las LCA de objetos funcionan de forma independiente de los roles de IAM, no aparecen en la jerarquía de las políticas de IAM. Cuando evalúes quién tiene acceso a uno de tus objetos, asegúrate de verificar las LCA del objeto, además de revisar tus políticas de IAM a nivel de proyecto y de bucket.

Políticas de denegación de IAM frente a LCA

Las políticas de denegación de IAM se aplican al acceso otorgado por las LCA. Por ejemplo, si creas una política de denegación que niega un principal el permiso storage.objects.get en un proyecto, el principal no puede ver los objetos en ese proyecto, incluso si se le otorgó el permiso READER para objetos individuales.

Permiso de IAM para cambiar las LCA

Puedes usar IAM para otorgar a los principales el permiso necesario para cambiar las LCA en los objetos. En conjunto, los siguientes permisos storage.buckets permiten a los usuarios trabajar con las LCA del bucket y las LCA de los objetos predeterminados: .get, .getIamPolicy, .setIamPolicy y .update.

De forma similar, los siguientes permisos storage.objects en conjunto autorizan a los usuarios a trabajar con las LCA de los objetos: .get, .getIamPolicy, .setIamPolicy y .update.

Funciones personalizadas

Si bien IAM tiene varios roles predefinidos que abarcan casos de uso comunes, es posible que quieras definir tus propios roles que contengan los paquetes de permisos que especifiques. Para ello, IAM ofrece funciones personalizadas.

Tipos principales

Hay varios tipos de principales. Por ejemplo, las Cuentas de Google y los Grupos de Google representan dos tipos generales, mientras que allAuthenticatedUsers y allUsers son dos tipos especializados. Para ver una lista de los tipos de principales en IAM, consulta Identificadores de principal. Para obtener más información de las principales en general, consulta Conceptos relacionados con la identidad.

Valores de conveniencia

Cloud Storage admite valores de conveniencia, que son un conjunto especial de principales que se pueden aplicar de forma específica a las políticas de tu bucket de IAM. Por lo general, debes evitar usar valores de conveniencia en entornos de producción, ya que requieren que se otorguen roles básicos, una práctica que no se recomienda en los entornos de producción.

Un valor de conveniencia es un identificador de dos partes que consta de una función básica y un ID del proyecto:

  • projectOwner:PROJECT_ID
  • projectEditor:PROJECT_ID
  • projectViewer:PROJECT_ID

Un valor de conveniencia actúa como un puente entre los principales a los que se les otorgó la función básica y una función de IAM: la función de IAM otorgada al valor de conveniencia se otorga, en efecto, también a todos los principales de la función básica especificada para el ID del proyecto especificado.

Por ejemplo, supongamos que jane@example.com y john@example.com tienen el rol básico de visualizador (roles/viewer) en un proyecto llamado my-example-project, y supongamos que tienes un bucket en ese proyecto llamado my-bucket. Si otorgas el rol de creador de objetos de almacenamiento (roles/storage.objectCreator) para my-bucket al valor de conveniencia projectViewer:my-example-project, tanto jane@example.com como john@example.com obtienen los permisos asociados con el rol de creador de objetos de almacenamiento para my-bucket.

Puedes otorgar y revocar el acceso a los valores de conveniencia de tus buckets, pero ten en cuenta que Cloud Storage los aplica de forma automática en ciertas circunstancias. Consulta comportamiento modificable para roles básicos en Cloud Storage para obtener más información.

Condiciones

Con las condiciones de IAM, puedes establecer las condiciones que controlan cómo se otorgan o rechazan los permisos a las principales. En Cloud Storage, se admiten los siguientes tipos de atributos de condición:

  • resource.name: otorga o niega el acceso a los buckets y objetos según el nombre del bucket o del objeto. También puedes usar resource.type para otorgar acceso a objetos o buckets, pero esta acción es casi siempre redundante si usas resource.name. En la siguiente condición de ejemplo, se aplica una configuración de IAM a todos los objetos con el mismo prefijo: 

    resource.name.startsWith('projects/_/buckets/BUCKET_NAME/objects/OBJECT_PREFIX')

  • Fecha/hora: configura una fecha de vencimiento para el permiso. 

    request.time < timestamp('2019-01-01T00:00:00Z')

Estas expresiones condicionales son declaraciones lógicas que usan un subconjunto de Common Expression Language (CEL). Debes especificar condiciones en las vinculaciones de funciones de la política de IAM de un depósito.

Ten en cuenta las siguientes restricciones:

  • Debes habilitar el acceso uniforme a nivel de depósito en un depósito antes de agregar condiciones a este nivel. Aunque las condiciones se permiten a nivel de proyecto, debes migrar todos los bucket s del proyecto a un acceso uniforme a nivel de bucket para evitar que las LCA de Cloud Storage anulen las condiciones de IAM a nivel de proyecto. Puedes aplicar una restricción de acceso uniforme a nivel de depósito para habilitar el acceso uniforme a este nivel en todos los depósitos nuevos de tu proyecto.
  • Cuando usas la API de JSON para llamar a getIamPolicy y setIamPolicy en depósitos con condiciones, debes configurar la versión de la política de IAM como 3.
  • Dado que el permiso storage.objects.list se otorga a nivel de depósito, no puedes usar el atributo de condición resource.name para restringir el acceso a la lista de objetos a un subconjunto de objetos en el depósito.
  • Las condiciones vencidas permanecen en tu política de IAM hasta que las quitas.

Uso con las herramientas de Cloud Storage

Aunque los permisos de IAM no se pueden configurar a través de la API de XML, los usuarios con permisos de IAM pueden usar esta API y cualquier otra herramienta para acceder a Cloud Storage.

Si deseas obtener referencias sobre qué permisos de IAM permiten a los usuarios realizar acciones con diferentes herramientas de Cloud Storage, consulta Referencias de IAM para Cloud Storage.

¿Qué sigue?