Roles y permisos

En esta página se describen los roles de Gestión de Identidades y Accesos (IAM), que son colecciones de permisos de IAM.

Un rol contiene un conjunto de permisos que te permiten realizar acciones específicas en los recursos deTrusted Cloud . Para que los principales, como usuarios, grupos y cuentas de servicio, tengan permisos, debes asignarles roles.

Antes de empezar

Tipos de roles

Hay tres tipos de roles en IAM:

  • Los roles básicos, que proporcionan un acceso amplio a los recursos de Trusted Cloud .
  • Roles predefinidos: proporcionan acceso granular a un servicio específico y los gestiona Trusted Cloud.
  • Roles personalizados: proporcionan acceso granular según una lista de permisos especificada por el usuario.

Para determinar si un permiso está incluido en un rol básico, predefinido o personalizado, puedes usar uno de los siguientes métodos:

Para obtener información sobre cuándo usar tipos de roles específicos, consulta Elegir el tipo de rol que se va a usar.

Componentes de los roles

Cada rol tiene los siguientes componentes:

  • Título: nombre del rol legible por personas. El título del rol se usa para identificar el rol en la Trusted Cloud consola.

  • Nombre: identificador del rol en uno de los siguientes formatos:

    • Roles predefinidos: roles/SERVICE.IDENTIFIER
    • Roles personalizados a nivel de proyecto: projects/PROJECT_ID/roles/IDENTIFIER
    • Roles personalizados a nivel de organización: organizations/ORG_ID/roles/IDENTIFIER

    El nombre del rol se usa para identificar el rol en las políticas de permiso.

  • ID: identificador único del rol. En el caso de los roles básicos y predefinidos, el ID es el mismo que el nombre del rol. En el caso de los roles personalizados, el ID es todo lo que hay después de roles/ en el nombre del rol.

  • Descripción: descripción del rol legible por humanos.

  • Fase: la fase del rol en el ciclo de vida del lanzamiento, como ALPHA, BETA o GA. Para obtener más información sobre las fases de lanzamiento, consulta Pruebas y despliegue.

  • Permisos: los permisos incluidos en el rol. Los permisos permiten que las entidades de seguridad realicen acciones específicas en los recursos de Trusted Cloud by S3NS . Cuando asignas un rol a una entidad principal, esta obtiene todos los permisos del rol.

    Los permisos tienen el siguiente formato:

    SERVICE.RESOURCE.VERB

    Por ejemplo, el permiso compute.instances.list permite a un usuario mostrar las instancias de Compute Engine de su propiedad, mientras que compute.instances.stop permite a un usuario detener una VM.

    Los permisos suelen corresponderse con los métodos REST, aunque no siempre. Es decir, cada servicio tiene un permiso asociado a cada método REST que tiene. Trusted Cloud Para llamar a un método, el llamante necesita el permiso asociado. Por ejemplo, para llamar al método projects.topics.publish de la API Pub/Sub, necesitas el permiso pubsub.topics.publish.

  • ETag: identificador de la versión del rol para evitar que las actualizaciones simultáneas se sobrescriban entre sí. Los roles básicos y predefinidos siempre tienen el ETag AA==. Los ETags de los roles personalizados cambian cada vez que modificas los roles.

Roles básicos

Los roles básicos son roles muy permisivos que dan acceso general a losTrusted Cloud recursos.

Los roles básicos de gestión de identidades y accesos son Administrador (roles/admin), Escritor (roles/writer) y Lector (roles/reader). Gestión de identidades y accesos también tiene tres roles básicos antiguos que existían antes de que se introdujera Gestión de identidades y accesos: Propietario (roles/owner), Editor (roles/editor) y Lector (roles/viewer). Para obtener más información sobre estos roles, consulta la sección Roles básicos antiguos de esta página.

En la siguiente tabla se resumen los permisos que conceden los roles Administrador, Escritor y Lector a las principales en todos los servicios de Trusted Cloud :

Rol básico Permisos
Lector (roles/reader)

Permisos para acciones de solo lectura que no afectan al estado, como ver (pero no modificar) recursos o datos.

Para ver una lista de los permisos del rol Lector, consulta los detalles del rol en la consola de Trusted Cloud :

Ir al rol de lector

Editor (roles/writer)

Todos los permisos del rol Lector más permisos para realizar acciones con las que se puedan modificar los estados, como cambiar recursos.

Los permisos del rol Escritor te permiten crear y eliminar recursos de la mayoría de los servicios de Trusted Cloud . Sin embargo, el rol Escritor no contiene permisos para realizar todas las acciones de todos los servicios. Para obtener más información sobre cómo comprobar si un rol tiene los permisos que necesitas, consulta Tipos de roles en esta página.

Para ver una lista de los permisos del rol Escritor, consulta los detalles del rol en la consola: Trusted Cloud

Rol Escritor

Administrador (roles/admin)

Todos los permisos del rol Escritor, más permisos para acciones como las siguientes:

  • Completar tareas sensibles, como gestionar las vinculaciones de etiquetas de recursos de Compute Engine
  • Gestionar roles y permisos de un proyecto y de todos los recursos del proyecto
  • Configurar la facturación de un proyecto

El rol Administrador no incluye todos los permisos de todos los recursos de Trusted Cloud . Por ejemplo, no contiene permisos para modificar tu información de pago de Facturación de Cloud ni para crear políticas de denegación de IAM.

Para ver una lista de los permisos del rol de administrador, consulta los detalles del rol en la Trusted Cloud consola:

Ir al rol de administrador

No puedes usar la consola para asignar los roles Lector, Escritor o Administrador. Trusted Cloud En su lugar, usa la API o la CLI de gcloud. También puedes crear derechos para estos roles con Gestor de acceso privilegiado.

Para obtener instrucciones, consulta Conceder, cambiar y revocar el acceso.

Roles básicos antiguos

Los roles básicos antiguos existían antes de la introducción de la gestión de identidades y accesos. Originalmente, se conocían como roles primitivos. A diferencia de otros roles básicos, no puedes añadir condiciones a las vinculaciones de roles básicos antiguos.

Los roles básicos antiguos son Propietario (roles/owner), Editor (roles/editor) y Lector (roles/viewer).

Cuando asignas un rol básico antiguo a una cuenta principal, esta obtiene todos los permisos del rol. La entidad de seguridad también obtiene los permisos que los servicios proporcionan a las entidades de seguridad con roles básicos antiguos, como los permisos obtenidos a través de los valores de conveniencia de Cloud Storage y la pertenencia a grupos especiales de BigQuery.

En la siguiente tabla se resumen los permisos que otorgan los roles básicos antiguos a los principales en todos los Trusted Cloud servicios:

Rol básico antiguo Permisos
Lector (roles/viewer)

Permisos para acciones de solo lectura que no afectan al estado, como ver (pero no modificar) recursos o datos.

Para ver una lista de los permisos del rol Lector, consulta los detalles del rol en la consola de Trusted Cloud Google Cloud:

Ir al rol de lector

Editor (roles/editor)

Todos los permisos de la función de lector más los permisos para realizar acciones con las que se puedan modificar los estados, como cambiar los recursos.

Los permisos del rol Editor te permiten crear y eliminar recursos de la mayoría de los servicios de Trusted Cloud . Sin embargo, el rol Editor no incluye permisos para realizar todas las acciones de todos los servicios. Para obtener más información sobre cómo comprobar si un rol tiene los permisos que necesitas, consulta Tipos de roles en esta página.

Para ver una lista de los permisos del rol Editor, consulta los detalles del rol en la consola Trusted Cloud :

Ir al rol Editor

Propietario (roles/owner)

Todos los permisos de editor, más los permisos para realizar acciones como las siguientes:

  • Completar tareas sensibles, como gestionar las vinculaciones de etiquetas de recursos de Compute Engine
  • Gestionar roles y permisos de un proyecto y de todos los recursos del proyecto
  • Configurar la facturación de un proyecto

El rol Propietario no incluye todos los permisos de todos los recursos Trusted Cloud . Por ejemplo, no contiene permisos para modificar tu información de pago de Facturación de Cloud ni para crear políticas de denegación de IAM.

Para ver una lista de los permisos del rol Propietario, consulta los detalles del rol en la Trusted Cloud consola:

Ir al rol de propietario

Por lo general, puedes asignar roles básicos antiguos mediante la Trusted Cloud consola, la API o la CLI de gcloud. Sin embargo, debes usar la consolaTrusted Cloud para asignar el rol de propietario en las siguientes situaciones:

  • El usuario al que vas a asignar el rol de propietario no forma parte de tu organización.
  • El proyecto en el que vas a asignar el rol de propietario no forma parte de ninguna organización.

Además, solo puedes conceder el rol de propietario a los siguientes tipos de principales:

  • Cuentas de Google
  • Cuentas de servicio de tu organización
  • Grupos de Google de tu organización

Para saber cómo conceder roles, consulta Conceder, cambiar y revocar el acceso.

Funciones predefinidas

Además de los roles básicos, IAM ofrece otros roles predefinidos que proporcionan acceso granular a recursos específicos. Trusted Cloud Google crea y mantiene estos roles. Google actualiza automáticamente sus permisos según sea necesario, por ejemplo, cuandoTrusted Cloud añade nuevas funciones o servicios.

Puede asignar varios roles al mismo usuario en cualquier nivel de la jerarquía de recursos. Por ejemplo, el mismo usuario puede tener los roles Administrador de red de Compute y Lector de registros en un proyecto, así como el rol Editor de Pub/Sub en un tema de Pub/Sub de ese proyecto. Para ver los permisos que contiene un rol, consulta Obtener los metadatos del rol.

Para obtener ayuda a la hora de elegir los roles predefinidos más adecuados, consulta el artículo Buscar los roles predefinidos adecuados.

Si quieres ver una lista de los roles predefinidos, consulta la referencia de roles.

Roles personalizados

Gestión de identidades y accesos también te permite crear roles personalizados de gestión de identidades y accesos. Los roles personalizados te ayudan a aplicar el principio de mínimos accesos, ya que te permiten asegurarte de que las entidades de tu organización solo tengan los permisos que necesitan.

Los roles personalizados los definen los usuarios y le permiten agrupar uno o varios permisos admitidos para satisfacer sus necesidades específicas. Cuando creas un rol personalizado, debes elegir una organización o un proyecto en el que crearlo. A continuación, puede asignar el rol personalizado a la organización o al proyecto, así como a cualquier recurso de esa organización o proyecto. Solo puedes crear 300 por organización y 300 por proyecto.

Solo puedes asignar un rol personalizado en el proyecto o la organización en los que lo hayas creado. No puedes asignar roles personalizados en otros proyectos u organizaciones, ni en recursos de otros proyectos u organizaciones.

Para crear un rol personalizado, debes combinar uno o varios de los permisos de gestión de identidades y accesos admitidos.

Permisos admitidos

Puedes incluir muchos permisos de gestión de identidades y accesos en roles personalizados, pero no todos. Cada permiso tiene uno de los siguientes niveles de asistencia para su uso en roles personalizados:

Nivel de asistencia Descripción
SUPPORTED El permiso es totalmente compatible con los roles personalizados.
TESTING Google está probando el permiso para comprobar su compatibilidad con los roles personalizados. Puedes incluir el permiso en roles personalizados, pero es posible que se produzcan comportamientos inesperados. No se recomienda su uso en producción.
NOT_SUPPORTED El permiso no se admite en los roles personalizados.

Un rol personalizado a nivel de organización puede incluir cualquiera de los permisos de gestión de identidades y accesos que se admiten en los roles personalizados. Un rol personalizado a nivel de proyecto puede contener cualquier permiso compatible excepto los permisos que solo se pueden usar a nivel de organización o de carpeta.

El motivo por el que no puedes incluir permisos específicos de carpetas y organizaciones en roles a nivel de proyecto es que no hacen nada cuando se conceden a nivel de proyecto. Esto se debe a que los recursos de Trusted Cloud se organizan jerárquicamente. Los permisos se heredan a través de la jerarquía de recursos, lo que significa que son efectivos para el recurso y todos sus descendientes. Sin embargo, las organizaciones y las carpetas siempre están por encima de los proyectos en laTrusted Cloud jerarquía de recursos. Por lo tanto, nunca podrás usar un permiso que se te haya concedido a nivel de proyecto para acceder a carpetas u organizaciones. Por lo tanto, los permisos específicos de carpetas y organizaciones (por ejemplo, resourcemanager.folders.list) no tienen efecto en los roles personalizados a nivel de proyecto.

Dependencias de permisos

Algunos permisos solo son efectivos si se conceden juntos. Por ejemplo, para actualizar una política de permiso, debe leerla antes de poder modificarla y escribirla. Por lo tanto, para actualizar una política de permiso, casi siempre necesitas el permiso getIamPolicy para ese servicio y tipo de recurso, además del permiso setIamPolicy.

Para asegurarte de que tus roles personalizados sean eficaces, puedes crearlos a partir de roles predefinidos con permisos similares. Los roles predefinidos se han diseñado para tareas específicas y contienen todos los permisos que necesitas para llevarlas a cabo. Revisar estos roles puede ayudarte a ver qué permisos se suelen conceder juntos. Después, puede usar esa información para diseñar roles personalizados eficaces.

Para saber cómo crear un rol personalizado a partir de un rol predefinido, consulta el artículo Crear y gestionar roles personalizados.

Ciclo de vida de los roles personalizados

En las siguientes secciones se describen las consideraciones clave en cada fase del ciclo de vida de un rol personalizado. Puedes usar esta información para saber cómo crear y gestionar tus roles personalizados.

Creación

Cuando crees un rol personalizado, elige un ID, un título y una descripción que te ayuden a identificarlo:

  • ID de rol: es el identificador único del rol. Puede tener una longitud máxima de 64 bytes y puede contener caracteres alfanuméricos en mayúsculas y minúsculas, guiones bajos y puntos. No puedes reutilizar un ID de rol en una organización o un proyecto.

    No puedes cambiar los IDs de rol, así que elígelos con cuidado. Puedes eliminar un rol personalizado, pero no puedes crear otro con el mismo ID en la misma organización o proyecto hasta que se haya completado el proceso de eliminación de 44 días. Para obtener más información sobre el proceso de eliminación, consulta el artículo Eliminar un rol personalizado.

  • Título del rol: el título del rol aparece en la lista de roles de laTrusted Cloud consola. El título no tiene que ser único, pero te recomendamos que uses títulos únicos y descriptivos para distinguir mejor tus roles. Además, te recomendamos que indiques en el título del rol si se ha creado a nivel de organización o de proyecto.

    Los títulos de los roles pueden tener una longitud máxima de 100 bytes y pueden contener caracteres alfanuméricos y símbolos en mayúsculas y minúsculas. Puedes cambiar los títulos de los roles en cualquier momento.

  • Descripción del rol: este campo es opcional y te permite proporcionar información adicional sobre un rol. Por ejemplo, puedes incluir el propósito del rol, la fecha en la que se creó o modificó y los roles predefinidos en los que se basa el rol personalizado. Las descripciones pueden tener hasta 300 bytes y contener caracteres alfanuméricos y símbolos en mayúsculas y minúsculas.

También debes tener en cuenta las dependencias de permisos al crear roles personalizados.

Para saber cómo crear un rol personalizado a partir de un rol predefinido, consulta el artículo Crear y gestionar roles personalizados.

Iniciar

Los roles personalizados incluyen una fase de lanzamiento como parte de los metadatos del rol. Las fases de lanzamiento más habituales de los roles personalizados son ALPHA, BETA y GA. Estas fases de lanzamiento son informativas y te ayudan a hacer un seguimiento de si cada rol está listo para un uso generalizado. Otra fase de lanzamiento habitual es la DISABLED. Esta fase de lanzamiento te permite inhabilitar un rol personalizado.

Te recomendamos que utilices las fases de lanzamiento para comunicar la siguiente información sobre el rol:

  • EAP o ALPHA: el rol aún está en fase de desarrollo o de prueba, o incluye permisos para Trusted Cloud servicios o funciones que aún no son públicos. No está listo para un uso generalizado.
  • BETA: el rol se ha probado de forma limitada o incluye permisos para servicios o funciones que no están disponibles de forma general. Trusted Cloud
  • GA: el rol se ha probado exhaustivamente y todos sus permisos son para Trusted Cloud servicios o funciones que están disponibles de forma general.
  • DEPRECATED: el rol ya no está en uso.

Para saber cómo cambiar la fase de lanzamiento de un rol, consulta Editar un rol personalizado.

Mantenimiento

Usted es responsable de mantener los roles personalizados. Esto incluye actualizar los roles a medida que cambian las responsabilidades de los usuarios, así como actualizar los roles para que los usuarios puedan acceder a nuevas funciones que requieran permisos adicionales.

Si basas tu rol personalizado en roles predefinidos, te recomendamos que compruebes periódicamente si se han producido cambios en los permisos de esos roles predefinidos. Hacer un seguimiento de estos cambios puede ayudarte a decidir cuándo y cómo actualizar tu rol personalizado. Por ejemplo, puede que observe que se ha actualizado un rol predefinido con permisos para usar una nueva función de vista previa y decida añadir esos permisos a su rol personalizado también.

Para que te resulte más fácil ver qué roles predefinidos debes monitorizar, te recomendamos que incluyas en el campo de descripción del rol personalizado los roles predefinidos en los que se basa. La consola lo hace automáticamente cuando la usas para crear un rol personalizado basado en roles predefinidos. Trusted Cloud Trusted Cloud

Para saber cómo actualizar los permisos y la descripción de un rol personalizado, consulta Editar un rol personalizado.

Consulta el registro de cambios de permisos para determinar qué roles y permisos han cambiado recientemente.

Inhabilitando

Si ya no quieres que ninguna de las entidades de tu organización use un rol personalizado, puedes inhabilitarlo. Para inhabilitar el rol, cambia su fase de lanzamiento a DISABLED.

Los roles inhabilitados siguen apareciendo en tus políticas de gestión de identidades y accesos y se pueden asignar a principales, pero no tienen ningún efecto.

Para saber cómo inhabilitar un rol personalizado, consulta el artículo sobre inhabilitar roles personalizados.

Siguientes pasos