Access management in Object Storage
In this section, you'll learn:
About access management
All transactions in Yandex Cloud are checked by the Yandex Identity and Access Management service. If a subject doesn't have the required permission, the service returns an error.
To grant permission for a resource, assign roles for this resource to the subject that will perform operations. Roles can be assigned to a Yandex account, a service account, federated users, a user group, or a system group. For more information, see How access management works in Yandex Cloud.
Only users with the admin
or resource-manager.clouds.owner
role for a resource can assign roles for this resource.
What resources you can assign roles to
Using the Yandex Cloud console or the YC CLI, you can assign a role to a cloud or folder. These assigned roles will also apply to nested resources.
For information about managing access to buckets and objects, see Access control lists (ACLs).
What roles exist in the service
The diagram shows which roles are available in the service and how they inherit each other's permissions. For example, the editor
role includes all viewer
role permissions. A description of each role is given under the diagram.
storage.admin
The storage.admin
role is intended for managing Object Storage. Users with this role can:
- Create buckets.
- Delete buckets.
- Assign an access control list (ACL).
- Manage any bucket object.
- Manage any bucket website.
- Configure other bucket parameters and objects in the bucket.
This role can grant other users access to a bucket or a specific object in it.
This role can be assigned by the administrator of the cloud (the admin
role).
storage.configViewer
Users with the storage.configViewer
role can view the security settings of buckets and their objects, but can't access data stored in buckets.
storage.configurer
Users with the storage.configurer
role can manage the settings of object lifecycles, static website hosting, access policy, and CORS.
They do not have permission to manage access control list (ACL) or public access settings. They do not have access to bucket data.
storage.editor
Users with the storage.editor
role can perform any operation with buckets and objects in the folder: create (including a publicly accessible bucket), delete, and edit them.
This role doesn't let you manage access control list (ACL) settings.
storage.uploader
Users with the storage.uploader
role can upload objects to a bucket and overwrite previously uploaded ones.
This role doesn't let you delete objects or configure buckets.
storage.viewer
The storage.viewer
role gives you read access to the list of buckets, settings, and data.
resource-manager.clouds.member
This role alone doesn't give you the right to perform any operations and is only used in combination with other roles.
How the role can be combined with other roles depends on whether a cloud belongs to an organization or not.
For a cloud in an organization
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
admin
editor
viewer
-
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:
The administrator must manage the network connectivity of resources in all clouds of the organization. Other team members are responsible for non-network resources. In this case, the following access matrix can be used:
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 clouds of the organization resource-manager.clouds.member
All clouds of the organization To work with Virtual Private Cloud in the management console, view general information about the clouds
Note
If there are multiple clouds in the organization and they are created and deleted frequently, it is inconvenient to assign resource-manager.clouds.member
to a cloud every time. In this case, you can replace resource-manager.clouds.member
with the resource-manager.viewer
role: assign it once to an organization and the administrator will be able to work in the management console with Virtual Private Cloud resources of all clouds, including future clouds. The role will enable you to view information about all clouds and folders, including access rights lists.
For a cloud without an organization
A role everyone requires to access cloud resources, except for cloud owners and service accounts.
Without this role, no other roles will work for the user.
The role is assigned automatically when you add a new user to a cloud without an organization.
resource-manager.clouds.owner
The resource-manager.clouds.owner
role is assigned for a cloud and makes the user a cloud owner. The owner can perform any operation with the cloud and its resources.
Only a cloud owner can assign and revoke a user's resource-manager.clouds.owner
role.
A cloud must have at least one owner. A user that created a cloud automatically becomes its owner. The sole owner of a cloud may not give up this role.
viewer
The viewer
role grants permission to read resources.
For example, the viewer
role lets you perform the following operations:
- View information about a resource.
- Get a list of nested resources, such as a list of VMs in a folder.
- View a list of operations with a resource.
editor
The editor
role grants permissions to perform any operation related to resource management, except assigning roles to other users. The editor
role includes all permissions granted by the viewer
role.
For example, the editor
role lets you perform the following operations:
- Create a resource.
- Update a resource.
- Delete a resource.
admin
The admin
role grants all permissions to manage the resource, including assigning roles to other users. You can assign any role except resource-manager.clouds.owner
.
The admin
role includes all permissions granted by the editor
role.
For example, the admin
role lets you perform the following operations:
- Set permissions to the resource.
- Change permissions to the resource.