Skip to main content

Nebius

Bring your Nebius AI Cloud tenant into the JupiterOne graph for exposure management and access reviews — the tenant and its projects, compute instances with their private and public IP addresses, hostname and DNS name, object-storage buckets with whether anonymous access is enabled, tenant user accounts with their email address and name, service accounts, IAM groups and their members, and the access permits that grant roles to each group. Find publicly reachable instances and public buckets, see which service account each instance runs as, and answer who has which role by following user to group to role. The integration reads resource configuration only: bucket contents, instance cloud-init user data and user phone numbers and profile photos are never ingested.

Installation​

This integration connects to Nebius AI Cloud using the Nebius AI Cloud REST API (https://api.nebius.cloud) and ingests your tenant and its projects, compute instances, object-storage buckets, tenant user accounts, service accounts, IAM groups, group memberships and access permits. It is built for exposure management (which instances and buckets are reachable from the internet) and access reviews (who holds which role through which group). The integration authenticates as a Nebius service account, every request is read-only, and it is managed by JupiterOne and runs in the JupiterOne cloud, so no collector is needed.

Prerequisites​

  • A Nebius AI Cloud tenant.
  • A Nebius account that can create service accounts and add them to groups. Nebius requires membership in a group with the admin role in the tenant or project, such as the default admins group.
  • openssl (or another tool) to generate an RSA key pair.
  • Access to JupiterOne with permission to configure integrations.

Configuration in Nebius​

The integration authenticates with a service-account authorized key. You upload the public half of an RSA key pair to a service account and give JupiterOne the private half. On each run the integration signs a short-lived JWT (RS256) with the private key and exchanges it at https://auth.eu.nebius.com/oauth2/token/exchange for a Bearer access token, which authorizes every API request. The private key itself is never sent to Nebius.

Each integration instance ingests one tenant: the tenant that contains the service account. To ingest another tenant, create a service account there and a separate integration instance.

Create the service account​

  1. In the Nebius web console, open Administration → IAM.
  2. Click Create resource, then Service account.
  3. Confirm the service account name, select the project to create it in, and click Create and continue.

You can also create it with the Nebius CLI: nebius iam service-account create --name <service_account_name>. Note the service account ID (serviceaccount-...); nebius iam service-account get-by-name --name <service_account_name> returns it.

Grant read access​

Nebius grants roles to groups, not directly to service accounts. Add the service account to a group that holds the viewer role across the tenant. The simplest option is the default viewers group, which Nebius creates in every tenant with the tenant-wide viewer role:

  1. In Administration → IAM, open the Groups tab and open the viewers group.
  2. Click Add members, switch to the Service accounts tab, and click Add next to the service account.

With the CLI: nebius iam group-membership create --parent-id <group_ID> --member-id <service_account_ID>.

We recommend granting the role at the tenant level. Users, groups and access permits are read from the tenant, and the integration lists the tenant's projects to find everything else. The integration never writes to Nebius, so editor and admin are not needed.

caution

The Nebius viewer role is read-only for configuration, but Nebius documents that it also lets the holder access data in resources, for example download objects from buckets. The integration never reads bucket objects or other resource data. Nebius also offers a security-auditor role, which grants read-only access to resource configuration without the data in them and is intended for third-party security tools. The integration was built against viewer; if you use a custom group with security-auditor instead, run the integration once and check the job log for permission errors.

Create the authorized key​

  1. Generate an RSA key pair:

    openssl genrsa -out private.pem 4096 && \
    openssl rsa -in private.pem -outform PEM -pubout -out public.pem

  2. In Administration → IAM, open the Service accounts tab and open the service account.

  3. Click Upload authorized key, click Attach file and select public.pem. Optionally set an expiration date, then click Upload key.

  4. The key appears on the Authorized keys tab. Copy its ID (publickey-...).

With the CLI: nebius iam auth-public-key create --account-service-account-id <service_account_ID> --data "$(cat public.pem)".

You now have the three values JupiterOne needs: the service account ID, the authorized key ID, and the private key (private.pem). Store the private key somewhere safe. If you set an expiration date on the key, the integration stops ingesting when it expires, until you upload a new key and update the instance.

Configuration in JupiterOne​

To install the Nebius integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Nebius. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the Nebius account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • The Authentication fields below.

Authentication fields​

FieldRequiredDescription
Service Account IDYesThe ID of the service account created above (serviceaccount-...).
Authorized Key IDYesThe ID of the authorized key uploaded to the service account (publickey-...).
Private Key (PEM)YesThe RSA private key paired with the authorized key. Paste the full contents of private.pem, including the BEGIN and END lines.

When you save the instance, JupiterOne checks that all three fields are set, signs a JWT and exchanges it for an access token, then reads the service account's own profile (GET /iam/v1/profiles). A malformed or non-RSA private key, an unknown key or service account, or a rejected request fails the check.

Filters​

The filter is optional. Leave it empty to ingest every project in the tenant.

FieldDefaultDescription
Project IDsEmpty (all projects in the tenant)Ingest only these Nebius projects, by project ID. Applies to projects and to the compute instances, buckets and service accounts inside them. If none of the IDs match a project, no project data is ingested.

Project IDs does not limit tenant-wide data: users, groups, group memberships and access permits are always read for the whole tenant. A group member or an instance's service account that lives in a project outside the filter is not ingested, so no relationship is created to it.

caution

Narrowing Project IDs later removes data from JupiterOne. Projects that no longer match, and the compute instances, buckets and service accounts in them, are deleted from the graph on the next run.

Click Create once all values are provided to finalize the integration.

Data Sources​

Each data source can be enabled or disabled on its own. All data sources are disabled by default, so enable the ones you want to ingest. The nebius_account entity for the tenant and the nebius_project entities for its projects are always created, because every other data source depends on them.

Data SourceDescriptionEntities Created
Fetch UsersTenant user accounts, with their email address, name, username, state and federation ID.nebius_user
Fetch GroupsIAM groups in the tenant.nebius_group
Fetch Group MembershipsWhich users and service accounts belong to each group. Requires Fetch Users, Fetch Groups and Fetch Service Accounts.Relationships only
Fetch Service AccountsService accounts in each ingested project.nebius_service_account
Fetch Compute InstancesCompute instances (virtual machines) in each ingested project, with their private and public IP addresses, hostname, DNS name and state.nebius_compute_instance
Fetch BucketsObject-storage buckets in each ingested project, with whether anonymous access is enabled, versioning, default storage class, audit logging, domain name and region.nebius_bucket
Fetch Access PermitsAccess permits granted to each ingested group: the role, and the tenant, project or resource it applies to. Requires Fetch Groups.nebius_access_role

To ingest everything the integration supports, enable all seven data sources.

caution

Fetch Group Memberships must be enabled together with Fetch Users, Fetch Groups and Fetch Service Accounts, and Fetch Access Permits must be enabled together with Fetch Groups. If a data source they depend on is disabled, they do not run at all and no memberships or access permits are ingested.

Relationships are built only when every data source they need is enabled:

RelationshipRequires
nebius_account HAS nebius_projectAlways created
nebius_account HAS nebius_userFetch Users
nebius_account HAS nebius_groupFetch Groups
nebius_project HAS nebius_compute_instanceFetch Compute Instances
nebius_project HAS nebius_bucketFetch Buckets
nebius_project HAS nebius_service_accountFetch Service Accounts
nebius_group HAS nebius_userFetch Group Memberships (with Users, Groups and Service Accounts)
nebius_group HAS nebius_service_accountFetch Group Memberships (with Users, Groups and Service Accounts)
nebius_compute_instance USES nebius_service_account (the service account the instance runs as)Fetch Compute Instances and Fetch Service Accounts
nebius_access_role ASSIGNED nebius_groupFetch Access Permits and Fetch Groups

With Fetch Service Accounts disabled, compute instances are still ingested, but without the USES relationship.

Users​

Nebius returns only the profile attributes each user has chosen to share with the tenant. A user whose attributes are not shared, or could not be read, is still ingested, named by its Nebius account name or ID, without email or name. A user is isActive: true when Nebius reports the account state as ACTIVE.

Groups and access permits​

Groups are listed at the tenant level, so groups created inside a project are not ingested, and neither are the access permits granted to them. Each access permit becomes a nebius_access_role entity named after its role, with the granted role in role and the ID of the tenant, project or resource it applies to in resourceId.

Public instances and buckets​

A compute instance has public: true when any of its network interfaces has a public IP address, or a private address in a public IP range. A bucket has public: true when Nebius reports anonymous access as enabled; when that status is missing, it is true if the bucket policy has a rule for anonymous access.

Example queries​

Publicly available buckets:

FIND nebius_bucket WITH public = true

Compute instances with a public IP address, and the service account each one runs as:

FIND nebius_compute_instance WITH public = true AS i
  THAT USES nebius_service_account AS sa
RETURN i.displayName, i.publicIpAddresses, sa.displayName

Everyone who holds the admin role, through which group, and where:

FIND nebius_access_role WITH role = 'admin' AS r
  THAT ASSIGNED nebius_group AS g
  THAT HAS (nebius_user | nebius_service_account) AS m
RETURN m.displayName, g.displayName, r.resourceId

Errors and permissions​

The integration lists compute instances, buckets and service accounts project by project, and group memberships and access permits group by group:

  • If Nebius denies access (401 or 403) for any project or group, the step fails with an authorization error. Data from that step's previous run is kept rather than deleted.
  • If a project or group is not found (404), it is skipped and the step continues.
  • Any other error fails the step.

If the integration cannot read the service account's profile, or the project the service account belongs to, it cannot resolve the tenant. The Fetch Account step then fails and no tenant data is ingested.

What the integration does not collect​

  • Bucket objects and other data stored in resources.
  • Instance cloud-init user data, which often holds secrets. It is removed before the instance is stored.
  • User phone numbers, profile photos, locale and time zone.
  • Authorized keys, or any other credential material.
  • Encryption state and data classification of buckets. Nebius does not expose them on the bucket, so encrypted and classification are left empty.
  • Other Nebius resources, such as networks, disks, Kubernetes clusters and container registries.

Rate limits​

The integration does not throttle its own requests. When Nebius answers with 429 Too Many Requests, it waits for the time given in the Retry-After header (30 seconds when the header is missing) before retrying. Requests that fail with a 5xx error or a network error are also retried, up to three attempts in total. Access tokens last 12 hours; if Nebius rejects the token with 401 or 403, the integration requests a new one and retries once.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​