Gestión de Identidades y Accesos

Uso

En esta página se ofrece una descripción general de Gestión de Identidades y Accesos (IAM) y de cómo se usa para controlar el acceso a los recursos de segmentos, carpetas gestionadas y objetos de Cloud Storage.

Información general

IAM te permite controlar quién tiene acceso a los recursos de tu Google Cloud proyecto. Los recursos incluyen los contenedores de Cloud Storage, las carpetas gestionadas de los contenedores y los objetos almacenados en los contenedores, así como otras entidades, como las instancias de Compute Engine. Google Cloud

Los principales son los "quién" de IAM. Las entidades principales pueden ser usuarios individuales, grupos, dominios o incluso el público en general. A las entidades se les asignan roles, que les permiten realizar acciones en Cloud Storage, así como Google Cloud de forma más general. Cada rol es un conjunto de uno o varios permisos. Los permisos son las unidades básicas de gestión de identidades y accesos: cada permiso 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 Creador de objetos de Storage (roles/storage.objectCreator), que concede los permisos útiles para crear objetos en un segmento, y Administrador de objetos de Storage (roles/storage.objectAdmin), que concede una amplia gama de permisos para trabajar con objetos.

El conjunto de roles de gestión de identidades y accesos que definas en un recurso se denomina política de gestión de identidades y accesos. El acceso concedido por estos roles se aplica tanto al recurso en el que se define la política como a los recursos que contiene. Por ejemplo, puedes definir una política de IAM en un segmento para dar a un usuario control administrativo sobre ese segmento y sus objetos. También puedes definir una política de gestión de identidades y accesos en todo el proyecto para que otro usuario pueda ver los objetos de cualquier segmento del proyecto.

Si tienes un Google Cloud recurso de organización, también puedes usar políticas de denegación de gestión de identidades y accesos (IAM) para denegar el acceso a los recursos. Cuando se asocia una política de denegación a un recurso, la entidad principal de la política no puede usar el permiso especificado para acceder al recurso ni a ningún subrecurso que contenga, independientemente de los roles que se le hayan concedido. Las políticas de denegación prevalecen sobre las políticas de gestión de identidades y accesos de permiso.

Permisos

Los permisos permiten que las entidades principales realicen acciones específicas en los segmentos, las carpetas gestionadas o los objetos de Cloud Storage. Por ejemplo, el permiso storage.buckets.list permite a una entidad principal mostrar los segmentos de tu proyecto. No se conceden permisos directamente a las entidades de seguridad, sino que se les asignan roles, que incluyen uno o varios permisos.

Para consultar una lista de referencia de los permisos de gestión de identidades y accesos que se aplican a Cloud Storage, consulta Permisos de gestión de identidades y accesos para Cloud Storage.

Roles

Las funciones son un paquete de uno o más permisos. Por ejemplo, el rol Visor de objetos de Storage (roles/storage.objectViewer) contiene los permisos storage.objects.get y storage.objects.list. Asignas roles a las entidades, lo que les permite realizar acciones en los segmentos, las carpetas gestionadas y los objetos de tu proyecto.

Para consultar una lista de referencia de los roles de gestión de identidades y accesos que se aplican a Cloud Storage, consulta Roles de gestión de identidades y accesos para Cloud Storage.

Asignar roles a nivel de proyecto, de segmento o de carpeta gestionada

Puedes asignar roles a principales a nivel de proyecto, de segmento o de carpeta gestionada. Los permisos concedidos por esos roles se aplican de forma acumulativa en toda la jerarquía de recursos. Puedes asignar roles en diferentes niveles de la jerarquía de recursos para que tu modelo de permisos sea más granular.

Por ejemplo, supongamos que quieres dar permiso a un usuario para que lea objetos de cualquier segmento de un proyecto, pero que solo pueda crear objetos en el segmento A. Para ello, puede asignar al usuario el rol Lector de objetos de almacenamiento (roles/storage.objectViewer) en el proyecto, lo que le permitirá leer cualquier objeto almacenado en cualquier segmento del proyecto, y el rol Creador de objetos de almacenamiento (roles/storage.objectCreator) en el segmento A, lo que le permitirá crear objetos solo en ese segmento.

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 segmentos, carpetas y objetos del proyecto. Cuando se usa a nivel de segmento, los permisos solo se aplican a un segmento específico y a las carpetas y los objetos que contiene. Algunos ejemplos de estos roles son el rol Administrador de almacenamiento (roles/storage.admin), el rol Visor de objetos de Storage (roles/storage.objectViewer) y el rol Creador de objetos de Storage (roles/storage.objectCreator).

Algunas funciones solo se pueden aplicar en un nivel. Por ejemplo, solo puedes aplicar el rol Propietario de objeto antiguo de Storage (roles/storage.legacyObjectOwner) a nivel de segmento o de carpeta gestionada. Los roles de gestión de identidades y accesos que te permiten controlar las políticas de denegación de gestión de identidades y accesos solo se pueden aplicar a nivel de organización.

Relación con las LCA

Además de la gestión de identidades y accesos, tus segmentos y objetos pueden usar un sistema de control de acceso antiguo llamado listas de control de acceso (LCAs) si la función control de acceso uniforme a nivel de segmento no está habilitada en tu segmento. Por lo general, no deberías usar LCA y deberías habilitar el acceso uniforme a nivel de segmento en tu segmento. En esta sección se explica lo que debe tener en cuenta si permite el uso de las listas de control de acceso en un cubo y en los objetos que contiene.

Los roles de gestión de identidades y accesos de Legacy Bucket funcionan conjuntamente con las ACLs de los segmentos: cuando añades o quitas un rol de Legacy Bucket, las ACLs asociadas al segmento reflejan los cambios. Del mismo modo, si se cambia una LCA específica de un segmento, se actualiza el rol de gestión de identidades y accesos de segmento antiguo correspondiente.

Función de segmento heredado LCA equivalente
Lector de segmentos heredados de Storage (roles/storage.legacyBucketReader) Lector de segmentos
Escritor de segmentos heredados de Storage (roles/storage.legacyBucketWriter) Escritor de segmentos
Propietario de segmentos heredados de Storage (roles/storage.legacyBucketOwner) Propietario del segmento

Todos los demás roles de gestión de identidades y accesos a nivel de segmento, incluidos los roles de gestión de identidades y accesos de objeto antiguo, funcionan de forma independiente de las listas de control de acceso. Del mismo modo, todos los roles de gestión de identidades y accesos a nivel de proyecto funcionan de forma independiente de las listas de control de acceso. Por ejemplo, si asignas a un usuario el rol Lector de objetos de almacenamiento (roles/storage.objectViewer), las LCA no cambian.

Como las LCA de objetos funcionan de forma independiente de los roles de gestión de identidades y accesos, no aparecen en la jerarquía de políticas de gestión de identidades y accesos. Cuando evalúes quién tiene acceso a uno de tus objetos, asegúrate de consultar las listas de control de acceso del objeto, además de las políticas de gestión de identidades y accesos a nivel de proyecto y de segmento.

Políticas de gestión de identidades y accesos de denegación frente a listas de control de acceso

Las políticas de gestión de identidades y accesos de denegación se aplican al acceso concedido por las LCAs. Por ejemplo, si creas una política de denegación que deniega a una entidad principal el permiso storage.objects.get en un proyecto, la entidad principal no podrá ver los objetos de ese proyecto, aunque se le haya concedido el permiso READER para objetos concretos.

Permiso de gestión de identidades y accesos para cambiar las LCA

Puedes usar la gestión de identidades y accesos para dar a los principales el permiso necesario para cambiar las listas de control de acceso de los objetos. Los siguientes permisos de storage.buckets permiten a los usuarios trabajar con LCAs de segmentos y LCAs de objetos predeterminados: .get, .getIamPolicy, .setIamPolicy y .update.

Del mismo modo, los siguientes permisos de storage.objects permiten a los usuarios trabajar con LCAs de objetos: .get, .getIamPolicy, .setIamPolicy y .update.

Roles personalizados

Aunque Gestión de Identidades y Accesos tiene muchos roles predefinidos que abarcan casos prácticos habituales, puede que quieras definir tus propios roles, que contengan conjuntos de permisos que especifiques. Para hacer esto posible, la gestión de identidades y accesos ofrece funciones personalizadas.

Tipos principales

Hay varios tipos de principales. Por ejemplo, las Google Cloud cuentas representan un tipo general, mientras que allAuthenticatedUsers y allUsers son dos tipos especializados. Para ver una lista de los tipos de principales de gestión de identidades y accesos, consulta Identificadores de principales. Para obtener más información sobre las entidades de seguridad en general, consulta Entidades de seguridad de gestión de identidades y accesos.

Valores de conveniencia

Cloud Storage admite valores de conveniencia, que son un conjunto especial de principales que se pueden aplicar específicamente a tus políticas de IAM de un bucket. En general, debe evitar el uso de valores de conveniencia en entornos de producción, ya que requieren que se concedan roles básicos, una práctica que no se recomienda en entornos de producción.

Un valor de conveniencia es un identificador de dos partes que consta de un rol básico y un ID de proyecto:

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

Un valor de conveniencia actúa como puente entre las entidades a las que se les ha concedido el rol básico y un rol de gestión de identidades y accesos: el rol de gestión de identidades y accesos concedido al valor de conveniencia también se concede a todas las entidades del rol básico especificado para el ID de proyecto especificado.

Por ejemplo, supongamos que los usuarios jane@example.com y john@example.com tienen el rol básico Lector (roles/viewer) en un proyecto llamado my-example-project y que tú tienes un contenedor en ese proyecto llamado my-bucket. Si asignas el rol Creador de objetos de Storage (roles/storage.objectCreator) a my-bucket con el valor de conveniencia projectViewer:my-example-project, tanto jane@example.com como john@example.com obtendrán los permisos asociados al rol Creador de objetos de Storage para my-bucket.

Puedes conceder y revocar el acceso a los valores de conveniencia de tus segmentos, pero ten en cuenta que Cloud Storage los aplica automáticamente en determinadas circunstancias. Para obtener más información, consulta Comportamiento modificable de los roles básicos en Cloud Storage.

Condiciones

Las condiciones de gestión de identidades y accesos te permiten definir condiciones que controlan cómo se conceden o se deniegan los permisos a las entidades. Cloud Storage admite los siguientes tipos de atributos de condición:

  • resource.name: concede o deniega el acceso a segmentos y objetos en función del nombre del segmento o del objeto. También puede usar resource.type para conceder acceso a segmentos u objetos, pero esto es redundante en la mayoría de los casos con el uso de resource.name. La siguiente condición de ejemplo aplica un ajuste de IAM a todos los objetos que tengan el mismo prefijo: 

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

  • Fecha y hora: define una fecha de vencimiento para el permiso. 

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

Estas expresiones condicionales son instrucciones lógicas que usan un subconjunto del lenguaje de expresión común (CEL). Puedes especificar condiciones en las vinculaciones de roles de la política de gestión de identidades y accesos de un segmento.

Ten en cuenta estas restricciones:

  • Debes habilitar el acceso uniforme a nivel de segmento en un segmento antes de añadir condiciones a nivel de segmento. Aunque se permiten condiciones a nivel de proyecto, debes migrar todos los segmentos del proyecto al acceso uniforme a nivel de segmento para evitar que las LCA de Cloud Storage anulen las condiciones de gestión de identidades y accesos a nivel de proyecto. Puedes aplicar una restricción de acceso uniforme a nivel de segmento para habilitar el acceso uniforme a nivel de segmento en todos los segmentos nuevos de tu proyecto.
  • Cuando se usa la API JSON para llamar a getIamPolicy y setIamPolicy en los contenedores con condiciones, debe definir la versión de la política de IAM en 3.
  • Como el permiso storage.objects.list se concede a nivel de segmento, no puedes usar el atributo de condición resource.name para restringir el acceso a la lista de objetos a un subconjunto de objetos del segmento.
  • Las condiciones caducadas permanecen en tu política de IAM hasta que las elimines.

Uso con herramientas de Cloud Storage

Aunque los permisos de IAM no se pueden definir a través de la API XML, los usuarios a los que se les hayan concedido permisos de IAM pueden seguir usando la API XML, así como cualquier otra herramienta para acceder a Cloud Storage.

Para consultar referencias sobre qué permisos de gestión de identidades y accesos permiten a los usuarios realizar acciones con diferentes herramientas de Cloud Storage, consulta Referencias de gestión de identidades y accesos para Cloud Storage.

Siguientes pasos