By default, nebius profile create authenticates you through your federation, which requires opening the Nebius AI Cloud web console in a browser. In a Docker container, a CI/CD runner or a dev container, there is no browser to open, so the command fails with an error similar to the following:
To authenticate in such an environment, use one of the following methods:
On a Compute virtual machine, you can attach a service account to the VM instead. See How to work with the Nebius AI Cloud CLI on a Compute virtual machine.
Prerequisites
-
Install and configure the Nebius AI Cloud CLI.
-
Make sure you are in a group that has the
admin role within your tenant or project; for example, the default admins group. You can check this in the Administration → IAM section of the web console.
-
Create a service account and add it to a group that has the roles your workload needs, granted within the project that the workload uses. See Keeping the credentials secure. Adding the service account to the default
editors group is quicker, but grants broad access within the whole tenant.
The second and third prerequisites are only needed for the service account method.
Authenticating as a service account
An authorized key is a key pair that the CLI reads from a credentials file. Because the CLI never needs to open a browser, this method works in fully unattended environments.
Perform the first three steps on a machine where you are already authenticated, then move the credentials file to the target environment.
-
Get the ID of the service account and save it to an environment variable:
-
Get the ID of the project that the workload uses and save it to an environment variable:
-
Generate an authorized key and save the credentials to a file:
This command creates a key pair, uploads the public key to the service account and writes the credentials, including the private key, to the output file.
To limit how long the key remains valid, add the
--expires-at parameter with the expiration time in RFC 3339 format, for example --expires-at 2027-01-31T23:59:59Z.
-
Make the credentials file available in the target environment at runtime. The command in the next step reads the file from
~/.nebius/$SA_ID-credentials.json, so set the SA_ID and PROJECT_ID variables in the target environment as well.
The target environment also needs the Nebius AI Cloud CLI. Install it in the image or at the start of the job, but do not configure a profile for it, because the next step does that from the credentials file. On a minimal image, install curl before you run the installation script, and add ~/.nebius/bin to PATH afterwards.
In a Docker container, add the mount and the variables to the command that starts the container. The container must run as the user whose home directory you mount into, root in this example:
In a CI/CD pipeline, store the contents of the credentials file in a secret, then write it to a file at the start of the job:
In this example, NEBIUS_CREDENTIALS is the secret that holds the contents of the credentials file.
-
In the target environment, create a profile from the credentials file:
If you made the credentials file available at a different path, specify that path in the
--service-account-file parameter.
Use one profile per projectCreate a separate Nebius AI Cloud CLI profile for each project to ensure correct region-specific configuration.
-
Check that the CLI can authenticate with the new profile and reach the project:
The command returns the service accounts in the project. It requires a project, so it also confirms that the profile is bound to one.
The CLI exchanges the authorized key for a short-lived access token and refreshes it automatically, so a pipeline job gets a fresh token in every run.
For an example of using a service account in a pipeline that works with Container Registry, see Working in a CI/CD environment.
Authenticating as a user account without a local browser
If a browser is available on another machine, add the global --no-browser parameter. Instead of launching a browser, the CLI prints the authorization link:
The command prints a message similar to the following:
Open the link in a browser and log in to the web console. After you log in, the browser is redirected to the address in the redirect_uri parameter of the link, which is a loopback address on the machine that runs the CLI. The browser must be able to reach this address:
- If the browser runs on the same machine as the CLI, it works without additional setup.
- If the browser runs on another machine, forward the port from the link to the machine that runs the CLI. For example, over SSH:
ssh -L 59998:127.0.0.1:59998 <user>@<host>.
The CLI picks the port at random for every authentication attempt, so take the port number from the printed link each time. The CLI waits for the redirect for 15 minutes; to change this, add the --auth-timeout parameter.
If the browser cannot reach the machine that runs the CLI at all, as is usually the case with CI/CD runners, authenticate as a service account instead.
Keeping the credentials secure
The credentials file contains the private key of the service account. Never copy it into a container image with the COPY or ADD instruction, because anyone who can pull the image can read the key from the image layer.
--expires-at parameter and delete the keys that you no longer use.
Grant the service account as few permissions as possible. The default editors and admins groups grant broad access within the whole tenant, so for a pipeline that works with a single project, create a custom group and assign it only the roles that the pipeline needs. 