Jerarquía de recursos

En esta página se describe la jerarquía de recursos de Google Cloud y los recursos que se pueden gestionar con Resource Manager.

La jerarquía de recursos Google Cloud tiene dos objetivos:

  • Ofrece una jerarquía de propiedad que vincula el ciclo de vida de los recursos a los niveles inmediatamente superiores.
  • Proporcionar herencias y puntos de montaje para los controles de acceso y las políticas de organización.

En sentido figurado, la Google Cloud jerarquía de recursos se parece al sistema de archivos de los sistemas operativos tradicionales, que permite organizar y gestionar entidades de forma jerárquica. Por lo general, cada recurso tiene exactamente un elemento superior. Esta organización jerárquica de los recursos te permite definir políticas de control de acceso y ajustes de configuración en un recurso superior. Los recursos secundarios heredan las políticas y los ajustes de Gestión de Identidades y Accesos (IAM).

.

Google Cloud jerarquía de recursos en detalle

LosGoogle Cloud recursos se organizan jerárquicamente. Todos los recursos, excepto el de nivel más alto de una jerarquía, tienen exactamente un elemento superior. En el nivel más bajo, los recursos de servicio son los componentes fundamentales que forman todos los servicios de Google Cloud . Entre los ejemplos de recursos de servicio se incluyen las máquinas virtuales de Compute Engine, los temas de Pub/Sub, los segmentos de Cloud Storage y las instancias de App Engine. Todos estos recursos de nivel inferior tienen recursos de proyecto como elementos superiores, que representan el primer mecanismo de agrupación de la jerarquía de recursos de Google Cloud .

Todos los usuarios, incluidos los de la prueba gratuita, los del nivel gratuito y los clientes de Google Workspace y Cloud Identity, pueden crear recursos de proyectos. Los usuarios del Google Cloud Programa gratuito solo pueden crear recursos de proyecto y recursos de servicio en proyectos. Los recursos de proyecto pueden estar en la parte superior de su jerarquía, pero solo si los crea un usuario de la prueba gratuita o del nivel gratuito. Los clientes de Google Workspace y Cloud Identity tienen acceso a funciones adicionales de la Google Cloud jerarquía de recursos Google Cloud , como los recursos de organización y de carpeta. Consulta más información en la descripción general de Cloud Identity. Los recursos de proyectos que se encuentran en la parte superior de su jerarquía no tienen recursos parent, pero se pueden migrar a un recurso de organización una vez que se haya creado para el dominio. Para obtener más información sobre la migración de recursos de proyectos, consulta el artículo Migrar recursos de proyectos.

Los clientes de Google Workspace y Cloud Identity pueden crear recursos de organización. Cada cuenta de Google Workspace o Cloud Identity está asociada a un recurso de organización. Cuando existe un recurso de organización, se encuentra en la parte superior de la Google Cloud jerarquía de recursos y todos los recursos que pertenecen a una organización se agrupan en el recurso de organización. De esta forma, se ofrece una visibilidad y un control centralizados sobre todos los recursos que pertenecen a un recurso de organización.

Los recursos de carpeta son un mecanismo de agrupación adicional y opcional entre los recursos de organización y los recursos de proyecto. Se necesita un recurso de organización como requisito previo para usar carpetas. Los recursos de carpeta y sus recursos de proyecto secundarios se asignan al recurso de organización.

La Google Cloud jerarquía de recursos, especialmente en su forma más completa, que incluye un recurso de organización y recursos de carpetas, permite a las empresas asignar su recurso de organización a Google Cloud y proporciona puntos de montaje lógicos para las políticas de gestión de accesos (IAM) y las políticas de organización. Las políticas de permitir, denegar y de la organización se heredan a través de la jerarquía. La política efectiva de cada recurso de la jerarquía es el resultado de las políticas aplicadas directamente al recurso y de las políticas heredadas de sus antecesores.

En el siguiente diagrama se muestra un ejemplo de jerarquía de recursos Google Cloud en su forma completa:

El recurso de organización

El recurso de organización representa a una organización (por ejemplo, una empresa) y es el nodo raíz de la jerarquía de recursosGoogle Cloud cuando está presente. El recurso de organización es el ancestro jerárquico de los recursos de carpeta y proyecto. Las políticas de permitir y denegar aplicadas al recurso de organización se aplican en toda la jerarquía de todos los recursos de la organización.

Google Cloud Los usuarios no tienen que tener un recurso de organización, pero algunas funciones de Resource Manager no se podrán usar sin él. El recurso de organización está estrechamente asociado a una cuenta de Google Workspace o Cloud Identity. Cuando un usuario con una cuenta de Google Workspace o Cloud Identity crea un recurso de proyecto, se le proporciona automáticamente un recurso de organización. Google Cloud

Una cuenta de Google Workspace o Cloud Identity solo puede tener un recurso de organización aprovisionado. Una vez que se crea un recurso de organización para un dominio, todos los recursos de proyecto que creen los miembros del dominio de la cuenta pertenecerán de forma predeterminada al recurso de organización. Google Cloud Cuando un usuario gestionado crea un recurso de proyecto, debe estar en algún recurso de organización. Si un usuario especifica un recurso de organización y tiene los permisos adecuados, el proyecto se asigna a esa organización. De lo contrario, se usará de forma predeterminada la organización o el recurso con el que esté asociado el usuario. Las cuentas asociadas a un recurso de organización no pueden crear recursos de proyecto que no estén asociados a un recurso de organización.

Para simplificar, nos referiremos a Google Workspace para referirnos tanto a los usuarios de Google Workspace como a los de Cloud Identity.

La cuenta de Google Workspace o Cloud Identity representa a una empresa y es un requisito previo para acceder al recurso de organización. En este Google Cloud contexto, proporciona gestión de identidades, mecanismo de recuperación, propiedad y gestión del ciclo de vida. La imagen de abajo muestra la relación entre la cuenta de Google Workspace, Cloud Identity y laGoogle Cloud jerarquía de recursos.


El superadministrador de Google Workspace es la persona responsable de verificar la propiedad del dominio y el contacto en caso de recuperación. Por este motivo, el superadministrador de Google Workspace tiene la capacidad de asignar roles de gestión de identidades y accesos de forma predeterminada. La tarea principal del superadministrador de Google Workspace en relación con Google Cloud es asignar el rol de gestión de identidades y accesos de administrador de la organización a los usuarios adecuados de su dominio. De esta forma, se separarán las responsabilidades de Google Workspace y de administración que suelen buscar los usuarios. Google Cloud

Ventajas del recurso de organización

Con un recurso de organización, los recursos de proyecto pertenecen a tu organización en lugar de al empleado que creó el proyecto. Esto significa que los recursos del proyecto ya no se eliminan cuando un empleado deja la empresa, sino que siguen el ciclo de vida del recurso de la organización en Google Cloud.

Además, los administradores de la organización tienen un control centralizado de todos los recursos. Pueden ver y gestionar todos los recursos de los proyectos de tu empresa. Esta medida implica que ya no puede haber proyectos ocultos ni administradores no autorizados.

También puedes asignar roles a nivel de organización, que heredarán todos los recursos de proyecto y carpeta de la organización. Por ejemplo, puedes asignar el rol Administrador de red a tu equipo de redes a nivel de organización, lo que le permitirá gestionar todas las redes de todos los recursos del proyecto de tu empresa, en lugar de asignarle el rol a todos los recursos del proyecto individual.

Un recurso de organización expuesto por la API de Cloud Resource Manager consta de lo siguiente:

  • Es el ID de un recurso de organización, que es un identificador único de una organización.
  • Un nombre visible, que se genera a partir del nombre de dominio principal en Google Workspace o Cloud Identity.
  • Hora de creación del recurso de organización.
  • Hora de la última modificación del recurso de organización.
  • El propietario del recurso de organización. El propietario se especifica al crear el recurso de organización. No se puede cambiar una vez que se ha configurado. Es el ID de cliente de Google Workspace que se especifica en la API Directory.

El siguiente fragmento de código muestra la estructura de un recurso de organización:

{
  "creationTime": "2020-01-07T21:59:43.314Z",
  "displayName": "my-organization",
  "lifecycleState": "ACTIVE",
  "name": "organizations/34739118321",
  "owner": {
    "directoryCustomerId": "C012ba234"
  }
}

La política de permisos inicial de un recurso de organización recién creado otorga los roles Creador de proyectos y Creador de cuentas de facturación a todo el dominio de Google Workspace. Esto significa que los usuarios podrán seguir creando recursos de proyectos y cuentas de facturación como lo hacían antes de que existiera el recurso de organización. No se crea ningún otro recurso cuando se crea un recurso de organización.

El recurso de carpeta

Los recursos de carpeta ofrecen de forma opcional un mecanismo de agrupación adicional y límites de aislamiento entre proyectos. Se pueden considerar como suborganizaciones dentro del recurso de la organización. Los recursos de carpetas se pueden usar para modelar diferentes entidades jurídicas, departamentos y equipos de una empresa. Por ejemplo, se podría usar un primer nivel de recursos de carpeta para representar los departamentos principales de tu recurso de organización. Como los recursos de carpetas pueden contener recursos de proyectos y otras carpetas, cada recurso de carpeta puede incluir otras subcarpetas para representar a diferentes equipos. Cada carpeta de equipo puede contener subcarpetas adicionales para representar diferentes aplicaciones. Para obtener más información sobre cómo usar los recursos de carpetas, consulta el artículo Crear y gestionar recursos de carpetas.

Si hay recursos de carpetas en tu recurso de organización y tienes los permisos de visualización adecuados, puedes verlos desde la Google Cloud consola. Para obtener instrucciones más detalladas, consulta Ver o enumerar recursos de carpetas y proyectos.

Los recursos de carpetas permiten delegar derechos de administración. Por ejemplo, se puede conceder la propiedad total de todos los recursos Google Cloud que pertenezcan a un departamento a su jefe. Del mismo modo, el acceso a los recursos se puede limitar por recurso de carpeta, de modo que los usuarios de un departamento solo puedan acceder y crear recursos dentro de ese recurso de carpeta. Google Cloud

El siguiente fragmento de código muestra la estructura de un recurso de carpeta:

{
  "createTime": "2030-01-07T21:59:43.314Z",
  "displayName": "Engineering",
  "lifecycleState": "ACTIVE",
  "name": "folders/634792535758",
  "parent": "organizations/34739118321"
}

Al igual que los recursos de organización y de proyecto, los recursos de carpeta actúan como punto de herencia de políticas para las políticas de permitir, denegar y de organización. Los roles de gestión de identidades y accesos concedidos en un recurso de carpeta se heredan automáticamente en todos los recursos de proyecto y de carpeta incluidos en esa carpeta.

El recurso de proyecto

El recurso de proyecto es la entidad organizativa de nivel básico. Los recursos de organización y de carpeta pueden contener varios proyectos. Se necesita un recurso de proyecto para usar Google Cloudy constituye la base para crear, habilitar y usar todos losGoogle Cloud servicios, gestionar APIs, habilitar la facturación, añadir y quitar colaboradores, y gestionar permisos.

Todos los recursos de un proyecto se componen de lo siguiente:

  • Dos identificadores:
    1. ID de recurso de proyecto, que es un identificador único del recurso de proyecto.Todos los IDs de proyecto tienen automáticamente el prefijo
    2. Número de recurso del proyecto, que se asigna automáticamente al crear el proyecto. Es de solo lectura.
  • Un nombre visible mutable.
  • El estado del ciclo de vida del recurso del proyecto. Por ejemplo, ACTIVE o DELETE_REQUESTED.
  • Colección de etiquetas que se pueden usar para filtrar proyectos.
  • Hora en la que se creó el recurso del proyecto.

El siguiente fragmento de código muestra la estructura de un recurso de proyecto:

{
  "createTime": "2020-01-07T21:59:43.314Z",
  "lifecycleState": "ACTIVE",
  "name": "my-project",
  "parent": {
    "id": "634792535758",
    "type": "folder"
  },
  "projectId": "my-project",
  "labels": {
     "my-label": "prod"
  },
  "projectNumber": "464036093014"
}

Para interactuar con la mayoría de los recursos, debe proporcionar la información de identificación del recurso de proyecto en cada solicitud. Google Cloud Puedes identificar un recurso de proyecto de dos formas: mediante un ID de recurso de proyecto o mediante un número de recurso de proyecto (projectId y projectNumber en el fragmento de código).

Un ID de recurso de proyecto es el nombre personalizado que elegiste al crear el recurso de proyecto. Si activas una API que requiere un recurso de proyecto, se te pedirá que crees uno o que lo selecciones mediante su ID. Ten en cuenta que la cadena name, que se muestra en la interfaz de usuario, no es la misma que el ID de recurso del proyecto.

Google Cloudgenera automáticamente un número de recurso de proyecto. Tanto el ID del recurso del proyecto como el número del recurso del proyecto se pueden encontrar en el panel de control del recurso del proyecto en la consola de Google Cloud . Para obtener información sobre cómo obtener identificadores de proyectos y otras tareas de gestión de recursos de proyectos, consulta el artículo Crear y gestionar recursos de proyectos.

La política de gestión de identidades y accesos inicial del recurso de proyecto recién creado concede el rol de propietario al creador del proyecto.

Permitir y denegar la herencia de políticas

Google Cloud ofrece IAM, que te permite asignar acceso granular a recursos Google Cloud específicos e impide el acceso no deseado a otros recursos. La gestión de identidades y accesos te permite controlar quién (usuarios) tiene qué acceso (roles) a qué recursos. Para ello, debes definir políticas de permiso y denegación en los recursos.

Puedes definir políticas de permiso y denegación en recursos de la organización, recursos de carpetas y recursos de proyectos. También puedes definir políticas de permiso en algunos recursos de servicio.

Los recursos heredan las políticas del recurso superior. Si defines una política de permitir o denegar a nivel de organización, todos los recursos secundarios la heredarán. Si define una política de permiso a nivel de proyecto, todos sus recursos secundarios la heredarán.

La política de permitir o denegar efectiva de un recurso es la unión de la política de permitir o denegar definida en el recurso y la política de permitir o denegar heredada de sus antecesores. Esta herencia es transitiva. Para obtener más información, consulta Evaluación de políticas.

Por ejemplo, en el diagrama de jerarquía de recursos anterior, si define una política de permiso en la carpeta "Departamento Y" que asigna el rol Administrador de instancias de Compute Engine (roles/compute.instanceAdmin) a bob@example.com, Bob tendrá ese rol en "Proyecto de desarrollo", "Proyecto de prueba" y "Proyecto de producción". Si asignas a alice@example.com el rol Administrador de instancias de Compute Engine en "Proyecto de prueba", solo podrá gestionar las instancias de Compute Engine de ese proyecto.

Los roles siempre se heredan. Si le quitas el rol Administrador de instancias de Compute Engine (roles/compute.instanceAdmin) a Bob en el proyecto de prueba, heredará ese rol de la carpeta "Departamento Y". Puedes usar una política de denegación para impedir que las entidades principales usen permisos heredados.

Las políticas de permitir y denegar se heredan a través de la jerarquía de recursos Google Cloud . Si cambias la jerarquía de recursos, también cambia la jerarquía de las políticas de permitir y denegar. Por ejemplo, si mueves un proyecto a un recurso de organización, se actualizarán las políticas de permitir y denegar del proyecto para que hereden las políticas de permitir y denegar del recurso de organización. Del mismo modo, si mueves un recurso de proyecto de un recurso de carpeta a otro, cambiarán los permisos heredados. Los permisos que haya heredado el recurso de proyecto del recurso superior original se perderán cuando el recurso de proyecto se mueva a un nuevo recurso de carpeta. El recurso del proyecto heredará los permisos definidos en el recurso de la carpeta de destino cuando se mueva.

Pruébalo

Si es la primera vez que utilizas Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los nuevos clientes también reciben 300 USD en crédito gratuito para ejecutar, probar y desplegar cargas de trabajo.

Empezar gratis