User roles and their permissions

When a user is invited to a project, he or she is assigned with a role. The role defines the scope of permissions available to the user when working with the personal account and with the cloud services.

The same user can be a member of several projects and have different roles in each of them. The same user can be assigned with several roles in one project; in this case, the permissions of all assigned roles are summarized.

You can view the list of project members and their roles on the Manage access page of the personal account.

A user with the widest set of permissions.

A Project owner is a user who created the project or for whom it was created automatically by the platform during the account registration.

There can be only one Project owner in a project. This role cannot be assigned to an existing user or to a member that is being invited.

A user with the same permissions as the Project owner, including linking a card and making payments.

Superadministrator is the only role, besides the Project owner, who can activate services in the project.

A user who can create and edit objects in all services.

A Project administrator cannot:

• activate services;
• make payments (can only view the project balance);
• invite members to the project.

A role intended for working with project members on the access management page.

A User access administrator can invite, delete project members, and change the roles assigned to them.

This role has no access to services and to project balance information.

A role intended for project balance management.

A billing administrator can:

• link a card to the project, if not linked yet;
• make a payment or configure balance auto-completion.

This role has no access to services and to the list of project members.

A user who has read access to all project information, including the members list, services, project balance, and expenses details.

A viewer cannot create any objects or edit any settings, except the settings of their account.

Each of the roles below is intended for working with one of the platform services only. There roles have permissions:

• in their target service;
• in adjacent services, to an extent that is necessary for working with their target service.

All these roles have no access to the project members list and to project balance information.

For detailed information about the permissions of these roles, see section Roles and their permissions: the full matrix.

All operations available to specialized roles are also available to Project owner, Superadministrator, and Project administrator.

A user with this role can perform basic operations in the Cloud computing service.

However, this role has only read permissions for:

• backup plans;
• file storages.

This user can also create and edit rule groups (firewalls) in the Virtual networks service.

A user with this role can perform a full set of operations in the Virtual networks and DNS services.

A user with this role has read access to the Virtual networks and DNS services.

He can create and edit only rule groups (firewalls).

A user with this role:

• has read access to the Virtual networks and DNS services;
• can create and edit virtual networks and subnets, routers;
• can add floating IP addresses to the project.

For detailed information about the permissions of these roles, see section Roles for the Containers service and their permissions.

Permissions are the privileges for viewing (R in the table below) or editing ( RW ) of certain objects. An editing permission includes the privilege of creating and deleting an object, and also includes the permission for viewing. A dash ( — ) indicates no access to a service or functionality.

The following user roles are intended for working with the Сontainers service:

• Kubernetes administrator,
• Kubernetes operator,
• Kubernetes auditor.

The operations available to Kubernetes administrator are also available to Project owner, Superadministrator, and Project administrator.

For other roles these operations are unavailable.

For Kubernetes clusters of version 1.23 and later, the role of a Kubernetes administrator, operator, or auditor also defines the internal Kubernetes role (admin, edit, or view) assigned to the user.