Authentication and access control
In Nebius AI, identification, authentication, and access control is performed by Identity and Access Management (IAM) and Cloud Organization.
The platform works with three categories of users:
- Google accounts: Accounts in the Google authentication system.
- Federated accounts: Accounts in a corporate SAML-compatible identity federation, such as Active Directory.
- Service accounts: Accounts that can be used by a program to manage resources.
Google accounts and federated accounts are authenticated in their own systems. Nebius AI has no access to these users' passwords and only authenticates service accounts via IAM.
User access to cloud resources is regulated by roles. Nebius AI services may provide different levels of granularity while granting permissions: in some cases, a role can be assigned directly to a service resource, in other cases, permissions are only granted at the level of the folder or cloud where the service resource is located.
This ensures interaction of different categories of resources, roles, and users in the Nebius AI infrastructure. Access to resources is managed by IAM. IAM controls each request and makes sure that all operations with resources are only run by users who have the appropriate permissions.
This section provides recommendations on how to ensure safe operations with Nebius AI services:
- Centralized management and identity federations.
- Minimum privileges and security policy.
- Using service accounts.
- Two-factor authentication.
- Managing privileged users.
- Providing Nebius AI access to contractors.
- Differentiating access to resources.
Centralized management and identity federations
Cloud Organization is a single service for managing the organizational structure, setting up integration with the employee catalog, and differentiating user access to the organization's cloud resources.
For the purpose of centralized account management, use SAML-compatible identity federations. By using identity federations, a company can set up Single Sign-On, which is authentication in Nebius AI via their IdP server. With this approach, employees can use their corporate accounts that are subject to the company's security policies, such as:
- Revoking and blocking accounts.
- Password policies.
- Limiting the number of unsuccessful login attempts.
- Blocking access sessions upon expiry of a preset user's idle time.
- Two-factor authentication.
Instructions for setting up SAML-based identity federations.
Tip
Use federated accounts instead of Google accounts whenever possible.
Minimum privileges and security policy
The principle of minimum privileges requires assigning users the minimum required roles.
We don't recommend using primitive roles like admin
, editor
, member
, and viewer
that are valid in all services. To ensure more selective access control and implementation of the principle of minimum privileges, use service roles that only contain permissions for a certain type of resources in the specified service.
Note
When a new user is added to the cloud, they're automatically assigned the cloud member role: resource-manager.clouds.member
. This role is necessary for working with the cloud and does not give any privileges.
Using service accounts
A service account is an account that can be used by a program to manage resources in Nebius AI.
A service account is used to make requests as an application. Do not use employee accounts instead of service accounts. If, for example, an employee quits or moves to a different department, their account permissions are disabled, which may lead to an application failure.
When using service accounts:
-
Set up a local firewall on the VM instance so that only the necessary processes and system users have access to the metadata service (IP address:
169.254.169.254
).Example of blocking access for all users except the specified one (in this case,
root
):sudo iptables --append OUTPUT --proto tcp \ --destination 169.254.169.254 --match owner ! --uid-owner root \ --jump REJECT
-
Store the service account keys and manage them in compliance with the standard requirements.
-
Follow the principle of minimum privileges and assign to the service account only those roles that are needed to run the application.
Note
You can grant permissions to use a service account under another user or service account.
Two-factor authentication
Security standards require two-factor authentication (2FA) for accessing the infrastructure. Therefore, access to the Nebius AI management console is based on 2FA.
To enable two-factor authentication, contact an identity provider that supports 2FA and set up a SAML-compliant identity federation.
To set up 2FA for a Google account, follow the instructions
Managing privileged users
Nebius AI privileged users include accounts with the following roles:
billing.accounts.owner
.admin
assigned for a billing account.resource-manager.clouds.owner
.admin
assigned for a cloud.admin
assigned for a folder.
The billing.accounts.owner
role is granted automatically when creating a billing account and cannot be reassigned to another user. The role allows you to perform any action with the billing account. The billing.accounts.owner
role can only be assigned to a Google account. An account with the billing.accounts.owner
role is used when setting up payment methods and adding clouds.
Make sure to properly secure this account, since it has significant privileges and can't be federated with a corporate account.
The most appropriate approach would be to not use this account on a regular basis:
- Only use it for initial setup and updates.
- For the duration that this account is actively used, be sure to enable two-factor authentication (2FA) in the Google account.
- After that, if you don't use the bank card payment method (only available for this role), set a strong password for this account (generated using specialized software), disable 2FA, and refrain from using this account unnecessarily.
- Change the password to a newly generated one each time you use the account.
We recommend disabling 2FA only for this account and if it is not assigned to a specific employee. This lets you avoid linking this critical account to a personal device.
To manage a billing account, assign the admin
or editor
role for the billing account to a dedicated employee with a federated account. To view Billing data, assign the viewer
role for the billing account to a dedicated employee with a federated account.
The resource-manager.clouds.owner
role is assigned automatically when you create a cloud. A user with this role can perform any operation with the cloud or its resources and grant cloud access to other users: assign roles and revoke them.
Use the resource-manager.clouds.owner
role with caution:
- Assign it to one or more federated users in your organization.
- Set a strong password for your Google account that you used to create the cloud. Use the Google account only when absolutely necessary, for example, if no federation is available.
Be sure to fully protect your federated account with the resource-manager.clouds.owner
role:
- Enable two-factor authentication.
- Disable authentication from devices beyond the company's control.
- Configure login attempt monitoring and set alert thresholds.
To view the list of IDs of the current accounts with the resource-manager.clouds.owner
role, run the following script:
ncp resource-manager cloud list-access-bindings \
--id <cloud_ID> \
--format json | jq -r '.[] | select(.role_id=="resource-manager.clouds.owner") | .subject.id'
Assign federated accounts the admin
roles for clouds, folders, and billing accounts. Minimize the number of accounts with these roles and regularly review the expedience of these roles for the accounts they are assigned to.
Specifics of authentication in managed database services
To use a database at the application level, in addition to IAM service roles, a separate user is created: the database owner. The following password policy applies to this user:
- The password must include numbers, uppercase letters, lowercase letters, and special characters.
- It must be at least 8 characters long.
Providing Nebius AI access to contractors
If you grant third-party contractors access to your clouds, make sure to follow these security measures:
- Assign permissions to contractor employees based on the principle of minimum privileges.
- If possible, create a separate account for third-party employees in your corporate IdP and assign the necessary policies to this account.
- Make sure they handle their account secrets carefully.
- Review the expedience of granting external users access to your cloud infrastructure.
Resource model
When developing an access model for your infrastructure, we recommend the following approach:
- Place any critical resources in a separate cloud. These include resources related to the processing of payment data, personal data, and trade secret data.
- Host the resource groups that require different administrative permissions in different folders (DMZ, CDE, security, backoffice, and so on).
- Host shared resources (such as network and security groups) in a separate shared resource folder.