Roles y permisos

En esta página, se describen los roles de Identity and Access Management (IAM), que son colecciones de permisos de IAM.

Un rol contiene un conjunto de permisos que te permite realizar acciones específicas en los recursos de Google Cloud. A fin de que los permisos estén disponibles para las principales, incluidos los usuarios, los grupos y las cuentas de servicio, debes otorgar roles para los principales.

Antes de comenzar

• Comprende los conceptos básicos de IAM.

Tipos de roles

Existen tres tipos de funciones en IAM:

• Funciones básicas, que incluyen las funciones de propietario, editor y visualizador que existían antes de la introducción de IAM.
• Funciones predefinidas, que proporcionan acceso detallado a un servicio específico y que Google Cloud administra.
• Funciones personalizadas, que proporcionan acceso detallado en función de una lista de permisos especificada por el usuario.

Para determinar si un permiso se incluye en un rol básico, predefinido o personalizado, puedes usar uno de estos métodos:

• Visualiza el rol en la consola de Google Cloud.

  Ir a Perfiles

• Ejecuta el comando gcloud iam roles describe.

• Obtén el rol con el método de API de REST adecuado:

  • Para los roles predefinidos, usa roles.get().
  • Para los roles personalizados a nivel de proyecto, usa projects.roles.get().
  • Para los roles personalizados a nivel de la organización, usa organizations.roles.get().

• Solo para roles básicos y predefinidos: Busca la referencia de permisos para ver si la función otorga el permiso.

• Solo para roles predefinidos: busca las descripciones predefinidas de los roles a fin de ver qué permisos incluye el rol.

Componentes de roles

Cada rol tiene los siguientes componentes:

• Título: Un nombre legible para el rol. El nombre del rol se usa para identificar el rol en la consola de Google Cloud.

• Nombre: un identificador para el 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 la organización: organizations/ORG_ID/roles/IDENTIFIER

  El nombre del rol se usa para identificar el rol en permitir políticas.

• ID: Es un identificador único para el rol. Para los roles básicos y predefinidos, el ID es el mismo que el nombre del rol. Para los roles personalizados, el ID es todo lo que se encuentra después de roles/ en el nombre del rol.

• Descripción: Una descripción legible del rol.

• Etapa: La etapa del rol en el ciclo de vida de lanzamiento, como ALPHA, BETA o GA. Para obtener más información sobre las etapas de lanzamiento, consulta Implementa y prueba.

• Permisos: Los permisos incluidos en el rol. Los permisos se usan para permitir a los principales realizar acciones específicas en los recursos de Google Cloud. Cuando otorgas un rol a un 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 que un usuario enumere las instancias de Compute Engine que posee y compute.instances.stop permite que un usuario detenga una VM.

  En general, aunque no siempre es así, los permisos se corresponden 1:1 con los métodos REST. Es decir, cada servicio de Google Cloud cuenta con un permiso asociado a cada método de REST que tenga. Para llamar a un método, el emisor necesita el permiso asociado. Por ejemplo, para llamar al método projects.topics.publish de la API de Pub/Sub, necesitas el permiso pubsub.topics.publish.

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

Roles básicos

Los roles básicos son roles muy permisivos que existían antes de la introducción de IAM. En un principio, se conocían como roles primitivos. Puedes usar roles básicos para otorgar a las principales acceso amplio a los recursos de Google Cloud.

Precaución: Los roles básicos incluyen miles de permisos en todos los servicios de Google Cloud. No otorgues roles básicos en entornos de producción a menos que no haya alternativa. En su lugar, otorga los roles predefinidos más limitados o los roles personalizados que satisfagan tus necesidades.

Cuando otorgas un rol básico a un principal, esta obtiene todos los permisos del rol básico. También obtienen cualquier permiso que los servicios proporcionan a las principales con roles básicos, por ejemplo, los permisos obtenidos a través de valores de conveniencia de Cloud Storage y la membresía al grupo especial de BigQuery.

En la siguiente tabla, se resumen los permisos que otorgan los roles básicos a los usuarios en todos los servicios de Google Cloud:

Roles básicos	Permisos
Visualizador (roles/viewer)	Permisos para acciones de solo lectura que no afectan el estado, como visualizar (pero no modificar) los recursos o datos existentes. Para obtener una lista de los permisos en el rol de Visualizador, consulta los detalles del rol en la consola de Google Cloud: Ir al rol de Visualizador
Editor (roles/editor)	Todos los permisos de lectura y permisos adicionales para acciones que modifican el estado, como cambiar recursos existentes. Los permisos del rol de Editor te permiten crear y borrar recursos para la mayoría de los servicios de Google Cloud. Sin embargo, el rol de Editor no contiene permisos para realizar todas las acciones de todos los servicios. Para obtener más información sobre cómo verificar si un rol tiene los permisos que necesitas, consulta Tipos de roles en esta página. Para obtener una lista de los permisos en el rol de Editor, consulta los detalles del rol en la consola de Google Cloud: Ir al rol de Editor
Propietario (roles/owner)	Todos los permisos del rol Editor, además de los permisos para acciones como las siguientes: Completar tareas sensibles, como crear aplicaciones de App Engine Administrar roles y permisos de un proyecto y todos los recursos dentro de este Configurar la facturación de un proyecto Para obtener una lista de los permisos en el rol de Propietario, consulta los detalles del rol en la consola de Google Cloud: Ir al rol de Propietario

Puedes otorgar roles básicoss con la consola de Google Cloud, la API y la CLI de gcloud. Sin embargo, para otorgar el rol de propietario en un proyecto a un usuario fuera de tu organización, debes usar la consola de Google Cloud, no la CLI de gcloud. Si el proyecto no forma parte de una organización, debes usar la consola de Google Cloud para otorgar el rol de Propietario.

Para obtener instrucciones, consulta Otorga, cambia y revoca el acceso.

Funciones predefinidas

Además de los básicos, IAM proporciona roles predefinidos adicionales que brindan acceso detallado a recursos específicos de Google Cloud. Google crea y mantiene estos roles. Google actualiza sus permisos automáticamente, según sea necesario, como cuando Google Cloud agrega roles o servicios nuevos.

Puedes otorgar varios roles al mismo usuario en cualquier nivel de la jerarquía de recursos. Por ejemplo, el mismo usuario puede tener las funciones de administrador de red de Compute y visor de registros en un proyecto, y también tener la función de publicador de Pub/Sub en un tema de Pub/Sub dentro de ese proyecto. Para enumerar los permisos que contiene una función, consulta Obtén los metadatos de la función.

Si deseas obtener ayuda para elegir los roles predefinidos más adecuados, consulta Elige roles predefinidos.

Para obtener una lista de los roles predefinidos, consulta la referencia de los roles.

Roles personalizados

IAM también te permite crear roles de IAM personalizados. Los roles personalizados te ayudan a aplicar el principio de privilegio mínimo, ya que ayudan a garantizar que los principales de tu organización solo tengan los permisos que necesitan.

Los roles personalizados están definidas por el usuario y te permiten agrupar uno o más permisos compatibles para satisfacer tus necesidades específicas. Cuando creas un rol personalizado, debes elegir una organización o un proyecto en el cual crearlo. Luego, puedes otorgar el rol personalizado en la organización o el proyecto, así como cualquier recurso dentro de esa organización o proyecto.

Solo puedes otorgar un rol personalizado dentro del proyecto o la organización en la que la creaste. No puedes otorgar roles personalizados en otros proyectos ni organizaciones o en recursos dentro de organizaciones o proyectos diferentes.

Nota: No puedes definir roles personalizados a nivel de la carpeta. Si necesitas usar un rol personalizado dentro de una carpeta, define el rol a nivel de organización.

Puedes crear un rol personalizado si combinas uno o más permisos de IAM admitidos.

Precaución: Solo debes permitir que una pequeña cantidad de principales de confianza editen roles personalizados. Si una principal puede editar los roles personalizados de un proyecto o de una organización, puede agregar cualquier permiso a cualquier rol personalizado en esa organización o proyecto. Como resultado, si otorgas cualquier rol personalizado al principal, puede usar el rol personalizado para obtener acceso ilimitado.

Permisos compatibles

Puedes incluir muchos permisos de IAM, pero no todos, en los roles personalizados. Cada permiso tiene uno de los siguientes niveles de asistencia para su uso en roles personalizados:

Nivel de compatibilidad	Descripción
SUPPORTED	El permiso es totalmente compatible en roles personalizados.
TESTING	Google prueba el permiso para verificar su compatibilidad con los roles personalizados. Puedes incluir el permiso en olesr personalizados, pero es posible que notes comportamientos inesperados. No se recomienda para su uso en producción.
NOT_SUPPORTED	El permiso no es compatible con roles personalizados.

Un rol personalizado a nivel de la organización puede incluir cualquiera de los permisos de IAM compatibles con los roles personalizados. Un rol personalizado a nivel del proyecto puede contener cualquier permiso admitido, excepto los permisos que solo se pueden usar a nivel de la organización o carpeta.

El motivo por el que no puedes incluir permisos específicos de la carpeta y específicos de la organización en las roles a nivel de proyecto es que no realizan ninguna acción cuando se otorgan a nivel de proyecto. Esto se debe a que los recursos de Google Cloud están organizados de manera jerárquica. Los permisos se heredan a través de la jerarquía de recursos, lo que significa que son efectivos para el recurso y para todos los secundarios de ese recurso. Sin embargo, las organizaciones y las carpetas siempre están por encima de los proyectos en la jerarquía de recursos de Google Cloud. Como resultado, nunca podrás usar un permiso que se te otorgó a nivel de proyecto para acceder a organizaciones o carpetas. Por lo tanto, los permisos específicos de carpeta y de organización (por ejemplo, resourcemanager.folders.list) son ineficaces para los roles personalizados a nivel de proyecto.

Cuándo usar roles personalizados

En la mayoría de los casos, deberías poder usar roles predefinidos en lugar de roles personalizados. Google mantiene los roles predefinidos, que se actualizan de forma automática cuando se agregan permisos, funciones o servicios nuevos a Google Cloud. En cambio, Google no mantiene los roles personalizados; cuando Google Cloud agregue permisos, funciones o servicios nuevos, los roles personalizados no se actualizarán de forma automática.

Sin embargo, puedes crear un rol personalizado en las siguientes situaciones:

• Un principal necesita un permiso, pero cada rol predefinido que incluye ese permiso también incluye permisos que el principal no necesita y no debería tener.
• Usa las recomendaciones de roles para reemplazar las asignaciones de roles demasiado permisivos con roles más adecuados. En algunos casos, es posible que recibas una recomendación para crear un rol personalizado.

También ten en cuenta los siguientes límites:

• Los roles personalizados pueden contener hasta 3,000 permisos. Además, el tamaño total máximo del título, la descripción y los nombres de permisos para un rol personalizado es de 64 KB.

• Existen límites para la cantidad de roles personalizados que puedes crear:

  • Puedes crear hasta 300 roles personalizados a nivel de la organización en tu organización
  • Puedes crear hasta 300 roles personalizados a nivel de proyecto en cada proyecto de tu organización.

Dependencias de permisos

Algunos permisos son efectivos solo si se combinan. Por ejemplo, para actualizar una política de permisos, debes leer la política antes de modificarla y escribirla. Como resultado, a fin de actualizar una política de permisos, 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 crear roles personalizados basados en roles predefinidos con permisos similares. Los roles predefinidos se diseñan teniendo en cuenta tareas específicas y contienen todos los permisos que necesitas para realizar esas tareas. Revisar estos roles puede ayudarte a ver qué permisos se suelen otorgar juntos. Luego, puedes usar esa información para diseñar roles personalizados eficaces.

Para aprender a crear un rol personalizado basado en un rol predefinido, consulta Crea y administra roles personalizados.

Ciclo de vida de los roles personalizados

En las siguientes secciones, se describen las consideraciones clave para cada fase del ciclo de vida de un rol personalizado. Puedes usar esta información para informar cómo creas y administras tus roles personalizados.

Creación

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

• ID del rol: El ID del rol es un identificador único para el rol. Puede tener hasta 64 bytes y contener caracteres alfanuméricos en mayúscula y minúscula, guiones bajos y puntos. No puedes volver a usar un ID de rol dentro de una organización o proyecto.

  No puedes cambiar los IDs de los roles, por lo que debes elegirlos con cuidado. Puedes borrar un rol personalizado, pero no puedes crear un rol personalizado nuevo con el mismo ID en la misma organización o proyecto hasta que se complete el proceso de eliminación de 44 días. Para obtener más información sobre el proceso de eliminación, consulta Borra un rol personalizado.

• Nombre del rol: El nombre del rol aparece en la lista de roles en la consola de Google Cloud. El nombre no tiene que ser único, pero te recomendamos que uses nombres únicos y descriptivos para distinguir mejor tus roles. Además, considera indicar en el nombre del rol si el rol se creó a nivel de la organización o a nivel del proyecto.

  Los nombres de los roles pueden tener hasta 100 bytes, y contener símbolos y caracteres alfanuméricos en mayúscula y minúscula. Puedes cambiar los nombres de los roles en cualquier momento.

• Descripción del rol: La descripción del rol es un campo opcional en el que puedes proporcionar información adicional sobre un rol. Por ejemplo, podrías incluir el propósito del rol, la fecha en la que se creó o modificó un rol y cualquier rol predefinido en la que se base el rol personalizado. Las descripciones pueden tener hasta 300 bytes y pueden contener símbolos y caracteres alfanuméricos en mayúsculas y minúsculas.

También ten en cuenta las dependencias de permisos cuando crees roles personalizados.

Para aprender a crear un rol personalizado basado en un rol predefinido, consulta Crea y administra roles personalizados.

Lanzamiento

Los roles personalizados incluyen una etapa de lanzamiento como parte de los metadatos del rol. Las etapas de lanzamiento más comunes para los roles personalizados activos son ALPHA, BETA y GA. Estas etapas del lanzamiento son informativas, te ayudan a hacer un seguimiento de si cada rol está listo para un uso generalizado. Otra etapa de lanzamiento común es DISABLED. Esta etapa de lanzamiento te permite inhabilitar un rol personalizado.

Te recomendamos usar etapas de lanzamiento para transmitir la siguiente información sobre el rol:

• EAP o ALPHA: El rol aún se está desarrollando o probando, o incluye permisos para servicios o características de Google Cloud que aún no son públicos. No está listo para su uso generalizado.
• BETA: La función se probó de forma limitada o incluye permisos para servicios o funciones de Google Cloud que no están disponibles de forma general.
• GA: El rol se probó extensamente y todos sus permisos son para servicios o características de Google Cloud que están disponibles de forma general.
• DEPRECATED: El rol ya no está en uso.

Para aprender a cambiar la etapa de lanzamiento de un rol, consulta Edita un rol personalizado existente.

Mantenimiento

Eres responsable de mantener los roles personalizados. Esto incluye la actualización de los roles a medida que cambian las responsabilidades de los usuarios, así como la actualización de los roles para que los usuarios puedan acceder a roles nuevos que requieren permisos adicionales.

Si basas tu rol personalizado en roles predefinidos, te recomendamos que verifiques de forma rutinaria esos roles predefinidos para detectar cambios en los permisos. El seguimiento de estos cambios puede ayudarte a decidir cuándo y cómo actualizar tu rol personalizado. Por ejemplo, es posible que notes que un rol predefinida se actualizó con permisos para usar un rol de vista previa nueva y quizás también agregues esos permisos a tu rol personalizado.

Para facilitar la visualización de los roles predefinidos que se supervisan, te recomendamos enumerar todos los roles predefinidos en los que se basa tu rol personalizado en el campo de descripción del rol personalizado. La consola de Google Cloud lo hace de forma automática cuando usas la consola de Google Cloud para crear un rol personalizado basado en roles predefinidos.

Para obtener más información sobre cómo actualizar los permisos y la descripción de un rol personalizado, consulta Edita un rol personalizado existente.

Consulta el registro de cambios de los permisos para determinar qué roles y permisos tienen cambios recientes.

Inhabilitando

Si ya no deseas que las personas de tu organización usen un rol personalizado, puedes inhabilitarlo. Para inhabilitarlo, cambia su etapa de lanzamiento a DISABLED.

Los roles inhabilitados aún aparecen en tus políticas de IAM y se pueden otorgar a las principales, pero no tienen ningún efecto.

Consulta Inhabilita un rol personalizado para saber cómo inhabilitarla.

¿Qué sigue?

• Aprende a otorgar roles de IAM a usuarios.
• Descubre cómo elegir los roles predefinidos más adecuados.
• Aprende cómo crear roles personalizados.
• Usa el solucionador de problemas de políticas a fin de comprender por qué un usuario tiene o no tiene acceso a un recurso o por qué tiene permiso para llamar a una API.