> ## Documentation Index > Fetch the complete documentation index at: https://docs.nebius.com/llms.txt > Use this file to discover all available pages before exploring further. # How resources, identities and access are managed in Nebius AI Cloud In Nebius AI Cloud, you can manage virtual machines, GPU clusters, Kubernetes clusters and Object Storage buckets. These components are called *resources* and are part of a *project*. You can allow other users in your federation to access your resources. You can also create special *service accounts* that can be used in programming interfaces (e.g., the [Nebius AI Cloud CLI](../cli)) to manage resources on your behalf. *Groups* are used to provide users and service accounts with different levels of access to resources. The mentioned entities are combined in a *tenant*, which is a central place for Identity and Access Management in Nebius AI Cloud. ## Resource management Resources are organized within a *project* and a project is part of a *tenant*. In the [web console](https://console.nebius.com), project-level resources appear in the navigation sidebar above the **Manage** section. Tenant-level resources, such as billing or Identity and Access Management settings, are listed below **Manage**. ### Tenants A *tenant* is your workspace in Nebius AI Cloud. It is the largest organizational unit that contains all other entities, including projects, users, quotas and billing information. A tenant includes: * Projects, which are isolated workspaces that contain [resources](#resource-hierarchy). * Groups with identity and access settings. * User accounts. * (Optional) A federation and user accounts from it. * Quotas and billing settings that define resource limits and usage accounting. * Audit logs that record actions performed within the tenant. When you [sign up for Nebius AI Cloud](../signup-billing/sign-up), a tenant is created automatically. You can also be added to other tenants and work with their resources. Additionally, you can [create multiple tenants](./tenants/create) of your own and invite users to collaborate within them. You cannot delete a tenant. To allow a user or a service account to view or manage resources in the tenant, add the required members to a corresponding tenant [group](./authorization/groups). Each group can perform different sets of operations with resources. ### Projects A *project* allows you to create and organize Nebius AI Cloud resources. Each project and its resources belong to only one [region](../overview/regions). Projects provide isolation between environments. You can group resources by product, ML team or any other criteria. For example, you can keep development and production workloads in separate projects. A project contains: * Resources, such as Compute virtual machines, Managed Service for Kubernetes® clusters or Object Storage buckets. * [Service accounts](#accounts-and-members) to work with the project resources. * Quotas that define resource limits. * Groups with project-level identity and access settings. When you sign up for Nebius AI Cloud, a project for your resources is created automatically. For more information about how to manage projects, see the [instructions](./manage-projects). ### Resource hierarchy Most resources belong to and are managed by individual Nebius AI Cloud services. For example: * The Compute service manages virtual machines, disks and shared filesystems. * The Managed Kubernetes service manages Managed Kubernetes clusters. * The Object Storage service manages buckets. Each resource type has a parent–child relationship. The parent defines the scope of permissions and resource inheritance. Projects are the parents of most service resources, while tenants are the parents of projects. Some resources can include other resources, forming parent–child relationships with them. For example: * A Managed Kubernetes cluster includes node groups. * A MysteryBox secret includes secret versions. You can learn which service manages a resource by checking one of the following: * The documentation section (for example, [Compute](../compute/), [Object Storage](/object-storage/)). * The CLI command group (for example, `nebius compute disk ` or `nebius storage bucket `). In some cases, the web console may show a slightly different organization for usability. For example, disks and shared filesystems appear under **Storage** in the web console, though they are part of the Compute service. ```mermaid theme={null} --- config: layout: elk elk: nodePlacement.strategy: NETWORK_SIMPLEX edgeRouting: POLYLINE hierarchyHandling: INCLUDE_CHILDREN --- graph LR classDef default fill:#e0ff4f,stroke-width:0px,color:#111c30; T[Tenant] T --> U[User] T --> G[Group] T --> F[Federation] T --> A[Audit event] T --> AE[Audit event export] T --> Q[Quota] T --> P[Project] %% Project resources P --> GR[Group] P --> QU[Quota] P --> RS[Virtual machine, Soperator cluster, Object Storage bucket and other resources] P --> K8s[Managed Kubernetes cluster] P --> S[MysteryBox secret] P --> PGC[Managed PostgreSQL® cluster] P --> SA[Service account] P --> RT[Routing table] P --> SG[Security group] %% Kubernetes children K8s --> NG[Node group] %% Secrets children S --> SV[Secret version] SV --> PL[Payload] %% Service account children SA --> AK[Access key] SA --> AUK[Authorized key] SA --> SK[Static key] %% Group children G --> GM[Group membership] GR --> GRM[Group membership] G --> GAP[Access permit] GR --> GRAP[Access permit] %% Federation children F --> FC[Federation certificate] %%PostgreSQL cluster children PGC --> PGB[Backup] %%Network children RT --> RTE[Route] SG --> SR[Security rule] ```

Service

Resource

Parent

Associated resource

Identity and Access Management

User account

-

-

Tenant

-

-

Tenant user account

Tenant

-

Federation

Tenant

-

Federation certificate

Federation

-

Invitation

Tenant

Tenant user account

Group

Tenant
Project

-

Group membership

Group

Tenant user account
Service account

Access permit

Group

Different resource types

Project

Tenant

-

Service account

Project

-

Access key

Service account

-

Authorized public key

Service account

-

Static key

Project

Service account

Audit Logs

Audit event

Tenant

-

Audit event export

Tenant

-

Compute

Virtual machine (instance)

Project

Disk
Service account
GPU cluster
Platform
Subnet
Allocation
Security group

Disk

Project

-

Shared filesystem

Project

-

GPU cluster

Project

-

Platform

Project

-

Managed Kubernetes®

Cluster

Project

Subnet
Allocation

Node group

Cluster

GPU cluster
Subnet

Serverless AI

Endpoint

Project

Virtual machine
Shared filesystem
Bucket
Subnet

Job

Project

Virtual machine
Shared filesystem
Bucket
Subnet

Managed MLflow

MLflow cluster

Project

Network
Service account

Managed PostgreSQL®

PostgreSQL cluster

-

Network

Backup

PostgreSQL cluster

-

Quotas

Quota allowance

Tenant
Project

-

Container Registry

Registry

Project

-

Image

Registry

-

Object Storage

Bucket

Project

-

Virtual Networks

Allocation

Project

Pool

Network

Project

Pool

Pool

Project

-

Subnet

Project

Network
Routing table

Routing table

Project

Network

Route

Routing table

-

Security group

Project

Network

Security rule

Security group

Security group

MysteryBox

Secret

Project

-

Secret version

Secret

-

Payload

Secret version

-
## Identity management ### Accounts and members You can use two types of accounts to work with Nebius AI Cloud resources: * Users from an identity federation. * Service accounts that are used to manage resources via CLI requests. Service accounts belong to the project and can be used only to work with their project resources. ### Federations A *federation* is your identity federation in Nebius AI Cloud. You can create and manage federations so that your users can log into Nebius AI Cloud through [single sign-on (SSO)](/iam/federations/saml-sso). ### Service account keys To authenticate in Nebius AI Cloud, service accounts use the following key types: * [Access keys](./service-accounts/access-keys) are used in services with AWS-compatible APIs, such as Object Storage. * [Authorized keys](./service-accounts/authorized-keys) are used to obtain IAM tokens for service accounts. ## Access management Being on the tenant user list does not grant access to resources. Each account should be assigned to a group that specifies the level of access the account has to the tenant resources. From least to most access, the default groups in a tenant are the following: * `auditors` can view **certain types** of resources **without access to data**. * `viewers` can view **most types** of resources (except some resources related to access management, security, etc.) and **access data** in them (e.g. download objects in buckets). * `editors` can view **and manage** most types of resources and access data in them. * `admins` can view and manage **all types** of resources and access data in them. For more information, see [groups description](./authorization/groups). Authentication methods vary depending on the type of account and interface used. For more details, see [How to authenticate in Nebius AI Cloud interfaces](./log-in). *** *Postgres, PostgreSQL and the Slonik Logo are trademarks or registered trademarks of the PostgreSQL Community Association of Canada, and used with their permission.*