Skip to main content
Roles are sets of permissions that are granted to users and service accounts to work with resources in Nebius AI Cloud. Roles are assigned to groups:
  • Default groups in each tenant (auditors, viewers, editors, admins) have corresponding predefined general roles.
  • When you create custom groups, you should create at least one access permit that assigns a role to the group. You can configure an access permit to apply to the entire tenant, a project within it or an individual resource within it. For more details and instructions, see Managing custom groups.

​
List of roles

The following roles are available:
  • General
    • auditor
    • viewer
    • editor
    • admin
  • Compute
    • compute.instance-power-operator
    • compute.serial-console-user
  • Object Storage
    • storage.viewer
    • storage.uploader
    • storage.editor
    • storage.object-editor
    • storage.object-viewer
    • storage.object-lister
    • storage.bucket-policy-editor
  • Audit Logs
    • auditlogs.audit-event-viewer
    • auditlogs.audit-event-exporter
  • SecretStash
    • mysterybox.payload-viewer

​
General roles

General roles grant permissions for resources from all services. For example, if you are in a group that has the admin role within a tenant, you can perform all actions listed below on all Compute virtual machines, Managed Kubernetes clusters, etc. in the tenant. The default groups within a tenant are assigned corresponding tenant-wide general roles.
Default groups and general roles grant a wide range of permissions across all services. To follow the principle of least privilege, create custom groups and assign roles with as few permissions as possible to these groups.
The following general roles are available:
  • auditor: view certain types of resources without access to data.
  • viewer: view most types of resources (except some resources related to access management, security and similar areas) and access data in them (for example, download objects in buckets).
  • editor: view and manage most types of resources and access data in them.
  • admin: view and manage all types of resources and access data in them.
The graph below shows how general roles are related to each other (the arrow means “is a sub-role of”):
The auditor role is going to be deprecated in the near future. We recommend using the viewer role and viewers default group instead.
General roles contain the following permissions:

​
Compute

Compute roles grant permissions for Compute virtual machines. The following Compute roles are available:
  • compute.instance-power-operator: perform power operations on virtual machines without broader Compute permissions
  • compute.serial-console-user: use the serial console on virtual machines for interactive troubleshooting
These Compute roles contain the following permissions:

​
Object Storage

Object Storage roles grant permissions for Object Storage buckets and objects. The following Object Storage roles are available:
  • storage.object-viewer: download objects and view their metadata
  • storage.object-lister: list objects and view their version metadata
  • storage.viewer: view buckets, list and download objects but not upload them
  • storage.uploader: view buckets, upload objects but not list or download them
  • storage.object-editor: view buckets, list, download, upload and manage objects
  • storage.editor: view and manage buckets, list, download, upload and manage objects
  • storage.bucket-policy-editor: manage bucket policies
The graph below shows how Object Storage roles are related to each other and to general roles, shown in green (the arrow means “is a sub-role of”): Object Storage roles contain the following permissions: For more details on the actions available to different roles, see Actions supported by Object Storage roles. If you want to configure fine-grained access to objects in a bucket, apply a bucket policy in Object Storage.

​
Audit Logs

Audit Logs roles grant permissions for viewing or exporting events in Audit Logs. The following Audit Logs roles are available:
  • auditlogs.audit-event-viewer: view audit events for the tenant
  • auditlogs.audit-event-exporter: view and list available audit log exports, start a new export and cancel an export
Audit Logs roles contain the following permissions:

​
SecretStash

MysteryBox is now called SecretStash. The Nebius AI Cloud CLI, API and Terraform provider still use the mysterybox service identifier. Keep using mysterybox in scripts and manifests.
SecretStash roles grant permissions for SecretStash secrets. The only available role is mysterybox.payload-viewer, which is a sub-role of the admin general role. mysterybox.payload-viewer contains the following permissions:
Creating a secret or a version of a secret does not automatically grant you access to view payloads in that secret or version. The editor role is enough to create a secret or a version, but viewing payloads requires the mysterybox.payload-viewer role, which is a sub-role of admin but not editor.

​
Data Subject Requests

Roles for Data Subject Requests (DSRs) grant permissions to receive copies of personal and non-personal data stored in a tenant and its resources in a machine-readable format, and erase the data if required. If you represent a legal entity and want to send a DSR, you need a role for DSRs. The only available role for DSRs is dsr.admin, which allows you to create Data Subject Requests and general support requests. It is a sub-role of the admin general role. dsr.admin contains the following permissions:
The dsr.admin role allows you to receive copies of and erase all personal and non-personal data in the tenant. Assign this role with caution.
Postgres, PostgreSQL and the Slonik Logo are trademarks or registered trademarks of the PostgreSQL Community Association of Canada, and used with their permission.