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.
Para obtener más información de otras maneras de controlar el acceso en Cloud Storage, consulta Descripción general del control de acceso.
Para obtener un análisis más detallado de IAM y sus características en general, consulta Identity and Access Management.
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
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. 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 para personalizar el acceso a objetos específicos dentro del 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 usarresource.type
para otorgar acceso a objetos o buckets, pero esta acción es casi siempre redundante si usasresource.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
ysetIamPolicy
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ónresource.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?
- Obtén más información acerca de cómo usar la IAM con Cloud Storage.
- Revisa la tabla de referencia de la IAM para Cloud Storage.
- Obtén más información de las prácticas recomendadas para usar IAM.
- Administra las políticas de IAM para todos tus recursos de Google Cloud.