Access control
Diese Seite ist noch nicht in deiner Sprache verfügbar. Englische Seite aufrufen
Controlling who can access resources is key to cloud security. You can manage access through IAM Role Bindings, which set permissions for users, groups and service accounts. While resource manager roles help manage the resource hierarchy, they don’t grant access to the cloud resources within a project.
For more information, see our Access Management documentation.
Resource Manager roles and permissions
Section titled “Resource Manager roles and permissions”Roles are made up of permissions, which are needed to perform specific actions. While permissions can’t be assigned directly, they are granted through roles. You might find the same role available at different levels of the hierarchy, but with varying permissions, because not all permissions apply to every scope.
For example, the Resource Manager Reader role at the project level only includes the resource-manager.project.get permission. This is because permissions like resource-manager.folder.get aren’t applicable at the project level, as there are no child folder resources below a project.
| Lowest Scope | Name | Description | Permissions |
|---|---|---|---|
| Project | Resource Manager Reader | Users with this role can view the details of child elements like projects and folders, but not the resources within those projects. |
|
| Project | Resource Manager Project Mover | Users with this role can move projects within the same organization to a different parent. |
|
| Project | Resource Manager Project Deleter | This role allows users to delete projects within a given scope. |
|
| Project | Resource Manager Admin | This role is a combination of every resource manager permission. |
|
| Folder | Resource Manager Project Creator | This role allows users to create projects within a given scope. |
|
| Folder | Resource Manager Folder Creator | This role allows users to create folders within a given scope. |
|
| Folder | Resource Manager Folder Editor | This role allows users to browse the resource hierarchy and edit folders. |
|
| Folder | Resource Manager Folder Mover | Users with this role can movefolderswithin the same organization to a different parent. |
|
| Folder | Resource Manager Folder Deleter | This role allows users to delete folders within a given scope. |
|
Legacy permissions
Section titled “Legacy permissions”Throughout the evolution of our access management system, we’ve introduced few permission changes. Occasionally, you may still encounter some of these deprecated legacy permissions in the system. They remain for now to ensure a safe transition until we can permanently remove them.
The following is a list of these permissions and their descriptions:
| Permission Name | Description |
|---|---|
| project.read | Alias for resource-manager.project.get |
| resource-manager.project.direct.get | Deprecated permission. Alias for resource-manager.project.get |
| resource-manager.organization.direct.get | Deprecated permission. Alias for resource-manager.organization.get |
| resource-manager.resource.project.edit | Deprecated permission. It will be removed in future releases. |
Legacy roles
Section titled “Legacy roles”| Lowest Scope | Name | Description | Permissions |
|---|---|---|---|
| Organization | organization.member | This role grants access to the organization level only (e.g., creating projects, reading organization details). It’s marked as legacy because its permissions do not inherit down to any child objects, like folders or projects. You’ll need to assign specific access to those items. |
|
| Organization | organization.auditor | The Organization Auditor role exists at the organization level only. It doesn’t grant access to any child objects, like folders or projects. Use this role to give users read-only access to the organization itself. This is a legacy role because its permissions don’t inherit to child items. |
|