[Yandex Cloud documentation](../../index.md) > [Yandex Resource Manager](../index.md) > Concepts > Yandex Cloud resource hierarchy # Yandex Cloud resource hierarchy The Resource Manager resource model is shown in the chart. Most Yandex Cloud services are based on this model. ![image](../../_assets/YC-resource-model-en.svg) All Yandex Cloud resources, such as [VMs](../../compute/concepts/vm.md), [disks](../../compute/concepts/disk.md), or [networks](../../vpc/concepts/network.md#network), are placed in [folders](#folder). You specify a folder when creating a resource. Each folder belongs to a single [cloud](#cloud). There are no folders outside a cloud. You cannot create a folder inside another folder. A [cloud](#cloud) belongs to an organization. Organizations do not interact with each other. The resources of an organization cannot interact with the resources of another organization using Yandex Cloud tools. Organizations are managed with [Yandex Identity Hub](../../organization/index.md). Within your organization, you can configure access permissions for a resource at the following [levels](#access-rights-inheritance): * Organization. * Cloud. * Folder. * Individual resource if the relevant service supports such granular access management. By default, a new user (organization member) has no access to the resources residing in the organization's clouds. Access permissions must be granted explicitly by assigning a role specifically for a resource or its folder, cloud, or organization. ## Resource Manager Resources {#rm-resources} ### Cloud {#cloud} A _cloud_ is an isolated space where folders are created. By default, clouds are isolated from each other. You cannot move resources from one cloud to another. For resources that support cross-cloud interaction, you can configure it separately. #### Cloud owner {#owner} A newly created cloud gets an owner assigned. A _cloud owner_ is a user with the `resource-manager.clouds.owner` role assigned for the cloud. An owner can perform any operation with the cloud and the resources within it. An owner can grant access to the cloud to other users: assign and revoke various [roles](../../iam/concepts/access-control/roles.md). Only a cloud owner can assign and revoke the `resource-manager.clouds.owner` role. Cloud owners can also revoke this role from themselves. A cloud must have at least one owner. The user creating a cloud becomes its owner automatically. Sole cloud owners cannot revoke the `resource-manager.clouds.owner` role from themselves. #### Cloud member {#member} The `resource-manager.clouds.member` role does not grant any rights to handle resources. This role is used in combination with other roles. The role is useful if the user needs access to Yandex Cloud resources not only via the CLI, API, and Terraform, but also via the management console. `resource-manager.clouds.member` is one of the roles that gives users access to the management console. Any role from the list can also be used for this purpose: * For an organization or cloud: * `resource-manager.admin`. * `resource-manager.editor`. * `resource-manager.viewer`. * `resource-manager.auditor`. * `admin`. * `editor`. * `viewer`. * `auditor`. * For a cloud: * `resource-manager.clouds.owner`. Each role from the list will give the user access to the console and permissions for cloud resources or an organization. Depending on the role, this can be either for reading information about all the resources in the cloud or creating and deleting any resource. To avoid giving the user additional rights, use `resource-manager.clouds.member`. The role will provide access to the management console while giving minimum additional rights. The user will only see general information about the cloud which they have been assigned the role to, but will not be able to view the resources and access rights to the cloud. > Example: > > Let's assume the administrator needs to manage the network connectivity of resources in all organization clouds, while other team members are in charge of non-network resources. In this case, you can use the following access matrix: > > | Role | For a resource | Allows | > --- | --- | --- > | `vpc.admin` | Organization | To manage networks, routes, IP addresses, and other Virtual Private Cloud resources via the CLI, API, and Terraform in all the organization's clouds | > | `resource-manager.clouds.member` | All clouds of the organization | To work with Virtual Private Cloud resources in the management console and view general information about the clouds | > {% note info %} If there are multiple clouds in the organization and they are created and deleted frequently, it might not be handy to assign `resource-manager.clouds.member` to a cloud every time. In this case, you can replace the `resource-manager.clouds.member` role with the `resource-manager.viewer` one: if you assign it once to an organization, the administrator will be able to work in the management console with Virtual Private Cloud resources of all clouds, including those you create moving forward. This role will also enable you to view information about all clouds and folders, including access rights lists. {% endnote %} ### Folder {#folder} A _folder_ is a space where Yandex Cloud resources are created and grouped. Just like folders in your file system, Yandex Cloud folders make resource management simpler. You can group your resources into folders by the resource type, project, or department that uses those resources, or any other criteria of your choice. ## Inheriting access permissions {#access-rights-inheritance} When a user ([subject](../../iam/concepts/access-control/index.md#subject)) performs an operation with a resource, Identity and Access Management check the user's access permissions for the resource. Resource access permissions are inherited as follows: * Organization access permissions apply to the [organization's](../../organization/concepts/organization.md) resources: * [Federations](../../iam/concepts/federations.md). * [User groups](../../organization/concepts/groups.md). * Organization [clouds](resources-hierarchy.md#cloud). * Permissions to access the cloud apply to all [folders](resources-hierarchy.md#folder) within the cloud. * Folder access permissions apply to all resources in the folder. >Example for an organization named `myorganization` with the following hierarchy: >* `mycloud` cloud: > * `robots` folder: > * `Alice` service account > * `Bob` service account > > A user with the `resource-manager.viewer` role for an organization will see a list of all its clouds, folders, and resources but will not be able to manage them. > > An additional `editor` role for a cloud named `mycloud` will enable the user to manage all the cloud's resources, including the `Alice` and `Bob` service accounts, but not to grant another user access to them. > > The `admin` role for the `robots` folder will allow the user to manage all the folder's resources, including `Alice` and `Bob`. For some resources, you cannot assign a role directly, in which case a role should be assigned for a folder, cloud, or organization. If the folder access permissions are missing, Identity and Access Management checks the cloud and organization access permissions. {% note info %} Even if an [operation](../../api-design-guide/concepts/about-async.md) with resources pertaining to Yandex Cloud [services](../../overview/concepts/services.md) is allowed by a [role](../../iam/concepts/access-control/roles.md), it may still be blocked if the [organization](../../organization/concepts/organization.md), [cloud](resources-hierarchy.md#cloud), or [folder](resources-hierarchy.md#folder) is subject to an [access policy](../../iam/concepts/access-control/access-policies.md) prohibiting this operation. {% endnote %} ## Deleting Resource Manager resources {#deleting-resources} You can delete a [cloud](../operations/cloud/delete.md) or [folder](../operations/folder/delete.md). When deleting one, you can specify whether to delete it immediately or after a certain delay. The default deletion delay is seven days. Throughout this period, the resources will be stopped, and the cloud/folder status will change to `PENDING_DELETION`. Once the delay period ends, the cloud/folder status will change to `DELETING`. This status means it is being permanently deleted, which can take up to 72 hours. As a result, all resources created in the cloud/folder will be deleted together with it. ### Reasons why a folder cannot be deleted {#inability-to-delete} The deletion of a folder in the `DELETING` status can be canceled by the system. The possible causes might include the following: * The folder contains a Yandex Virtual Private Cloud [IP address](../../vpc/concepts/address.md) currently used by a [VM](../../compute/concepts/vm.md) in another folder. * The folder contains deletion protected managed database clusters. In which case the deletion will be stopped, the folder will regain its `ACTIVE` status, and the user will get a message stating why the folder could not be deleted. Yet some folder resources may still be deleted: these will not be restored after the deletion is canceled. Other resources may end up intact: these will remain billable. #### See also {#see-also} * [Setting up cloud access permissions](../operations/cloud/set-access-bindings.md) * [Creating a folder](../operations/folder/create.md) * [Setting up folder access permissions](../operations/folder/set-access-bindings.md) * [Resources that roles can be assigned for](../../iam/concepts/access-control/resources-with-access-control.md)