Identity and Access Management

Ir a ejemplos

En esta página, se proporciona una descripción general de Identity and Access Management (IAM) y su uso para controlar el acceso a los recursos, como los buckets 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 depósitos de Cloud Storage 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 Storage Object Creator, que otorga los permisos útiles para crear objetos en un bucket, y en Storage Object Admin, 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.

Permisos

Con los permisos, los principales pueden realizar acciones específicas en objetos o buckets en Cloud Storage. Por ejemplo, con el permiso storage.buckets.list, un miembro puede enumerar los buckets de tu proyecto. No otorgas permisos a los principales de forma directam, sino roles, que incluyen uno o más permisos.

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, la función visualizador de objetos de almacenamiento contiene los permisos storage.objects.get y storage.objects.list. Otorgas roles a los principales, lo que les permite realizar acciones en los buckets y 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.

Funciones a nivel de proyecto frente a funciones a nivel de bucket

La asignación de funciones a nivel de bucket no afecta a las funciones existentes que otorgaste a nivel de proyecto y viceversa. Por lo tanto, puedes usar estos dos niveles de detalle para personalizar tus permisos. Por ejemplo, supongamos que deseas otorgar a un usuario permiso para leer objetos en cualquier bucket, pero crearlos solo en un bucket específico. Para lograrlo, otorga al usuario la función visualizador de objetos de almacenamiento a nivel de proyecto, lo que le permitirá leer cualquier objeto almacenado en cualquier depósito de tu proyecto, y la función creador de objetos de almacenamiento a nivel de depósito para un depósito específico, lo que le permitirá crear objetos solo en ese depósito.

Algunas funciones se pueden usar a nivel de proyecto y de bucket. 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 estas funciones son administrador de almacenamiento, visualizador de objetos de almacenamiento y creador de objetos de almacenamiento.

Algunas funciones solo se pueden aplicar a un nivel. Por ejemplo, solo puedes aplicar la función Propietario de objetos heredados de almacenamiento a nivel de bucket.

Relación con las LCA

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 depósitos heredados de almacenamiento Lector de depósitos
Escritor de depósitos heredados de almacenamiento Escritor de depósitos
Propietario de depósitos heredados de almacenamiento Propietario de depósitos

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 Storage Object Viewer, las LCA no se modificarán. Esto significa que puedes usar los roles de IAM a nivel de bucket para otorgar acceso amplio a todos los objetos de un bucket y usar las LCA de objetos detalladas a fin de personalizar el acceso a objetos específicos dentro del bucket.

Permiso de IAM para cambiar las LCA

Puedes usar IAM a fin de 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 la IAM tiene varias funciones predefinidas que abarcan casos de uso comunes, es posible que desees definir tus propias funciones 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 comunes en la IAM, 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 la función básica de visualizador en un proyecto llamado my-example-project, y supongamos que tienes un bucket en ese proyecto llamado my-bucket. Si otorgas la función creador de objetos de almacenamiento 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 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 a fin de obtener más información.

Condiciones

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

  • resource.name: Otorga acceso a los depósitos y objetos según el nombre del depósito o del objeto. También puedes usar resource.type para otorgar acceso a objetos o depósitos, 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.
  • El comando gsutil iam ch no funciona con las políticas que contienen condiciones. Si deseas modificar una política que tiene condiciones, usa gsutil iam get a fin de recuperar la política para el depósito relevante y editarla localmente y, luego, usa gsutil iam set de modo que vuelvas a aplicarla al depósito.
  • Para poder usar las condiciones, gsutil debe estar actualizado a la versión 4.38 o a una versión superior.
  • 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. Los usuarios sin el permiso storage.objects.list a nivel de depósito pueden experimentar una funcionalidad degradada de Console y gsutil.
  • 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.

Para obtener referencias sobre qué permisos de IAM permiten a los usuarios realizar acciones con diferentes herramientas de Cloud Storage, consulta IAM con Cloud Console, IAM con gsutil, IAM con JSON y, también, IAM con XML.

¿Qué sigue?