Access management in Object Storage

In this section, you'll learn:

• Which resources you can assign roles to.
• Which roles exist in the service.

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

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.