Nebius

B Nebius AI Cloud (IAM service accounts, Compute, Managed Kubernetes, Object Storage, Container Registry)

Federated credentials let a Nebius service account trust any OIDC issuer: an external JWT is exchanged at Nebius STS for a 12-hour IAM token that drives the API, CLI, Terraform, registry and Kubernetes. Object Storage still runs on S3 access keys, which can be minted short-lived from that token but may also never expire. Nebius is itself an OIDC issuer for GCP and others, yet Data Transfer and Serverless jobs take pasted keys.

Docs: docs.nebius.com · Checked 2026-10-22 · source YAML · dispute via PR

Inbound A

How a workload running anywhere authenticates to this product.

A federated-credentials resource binds an external OIDC issuer (issuer URL, optional inline JWKS) and a federated subject (the JWT's sub) to a service account; the workload posts its JWT as the actor_token to Nebius STS (RFC 8693) and receives a short-lived IAM access token. The static alternatives are service-account authorized keys (a private key that signs a JWT exchanged for the same token) and S3-style access keys for Object Storage.

Issuers: any

docs.nebius.com checked 2026-10-22
“IAM subject (service account) that the federated subject impersonates.”
docs.nebius.com checked 2026-10-22
“OIDC-compatible JWT issuer URL.”
docs.nebius.com checked 2026-10-22
“For oidc_provider, the subject is calculated from the "sub" claim of the federated JWT token.”
raw.githubusercontent.com checked 2026-10-22
“// The OIDC provider does not have to be a full OIDC provider, but it must expose”
docs.nebius.com checked 2026-10-22
“Nebius STS is an HTTP-based service that exchanges identity credentials for short-lived Nebius access tokens or OIDC ID tokens.”
docs.nebius.com checked 2026-10-22
“A token that represents the acting identity of the exchange flow, for example, an external JWT.”
raw.githubusercontent.com checked 2026-10-22
“// NewFederatedCredentialsTokener creates a [BearerTokener] serving token from”
docs.nebius.com checked 2026-10-22
“File path to a federated subject credentials.”
docs.nebius.com checked 2026-10-22
“Authorized keys are used to obtain IAM tokens for service accounts.”
docs.nebius.com checked 2026-10-22
“For a CI/CD environment, use a service account and either issue a long-lived static key and save it in your pipeline settings, or get a short-lived token each time your pipeline runs.”
docs.nebius.com checked 2026-10-22
“Access tokens have a lifetime of 12 hours.”
docs.nebius.com checked 2026-10-22
“Access keys in Nebius AI Cloud are used to authenticate service accounts in AWS-compatible services, such as Object Storage.”
docs.nebius.com checked 2026-10-22
“Authentication with an IAM token is not allowed over HTTP because HTTP does not use encryption.”

Judgment call for a reviewer. The federation is real and self-serve: federated credentials are a first-class IAM resource in the CLI, REST API and Terraform provider, the STS overview lists "an external JWT" as an accepted token, the Go SDK ships a federated-credentials tokener and CLI profiles take a federated-credentials file. Trust is pinned by issuer and sub only; no audience or extra-claim condition is documented, the same gap the A on keycard-agent-identity accepted. The weakness is documentation: there is no walkthrough for GitHub Actions or any other issuer, only reference pages and the STS parameter table, so if the reviewer reads "documented for workloads" as needing a how-to, this drops to C (the authorized-key JWT flow is a static root). Data planes, graded on the weakest path a workload must use: Container Registry takes the 12-hour IAM token (static keys optional); kubeconfigs come from `nebius mk8s cluster get-credentials`, i.e. the same CLI identity; Object Storage's documented S3 path needs an access key pair, but a federated service account can create one through the IAM v2 API with an expires_at minutes away and delete it after, so no long-lived secret is required, and the HTTP-access page implies IAM-token auth also works over HTTPS (not documented elsewhere). Compute VMs also get ambient tokens from the metadata service, which on its own would not earn the A.

Outbound B

How this product reaches into your cloud, repos, or other SaaS.

Nebius STS issues OIDC ID tokens (issuer https://sts.nebius.com) that a workload exchanges at Google Cloud Workload Identity Federation or any OIDC-trusting system, and every Managed Kubernetes cluster publishes its own OIDC discovery endpoint. Managed reach-ins do not use it: Object Storage Data Transfer takes S3 access key pairs or an Azure storage account key, and Serverless AI jobs take a private registry's username and password or PAT.

docs.nebius.com checked 2026-10-22
“Nebius AI Cloud allows you to produce ID tokens for your workloads.”
docs.nebius.com checked 2026-10-22
“Any platform that supports OIDC Discovery can establish trust with this identity provider and validate the issued ID tokens.”
docs.nebius.com checked 2026-10-22
“This guide explains how to configure access to Google Cloud resources for Nebius workloads using OpenID Connect (OIDC) ID tokens.”
docs.nebius.com checked 2026-10-22
“All Managed Service for Kubernetes clusters expose a public OpenID Connect (OIDC) discovery endpoint.”
docs.nebius.com checked 2026-10-22
“For a bucket in Object Storage or another S3-compatible storage service, the required credentials are a pair of keys called access and secret keys, also known as access key ID and secret access key.”
docs.nebius.com checked 2026-10-22
“If your source bucket (container) is in Azure Blob Storage, provide credentials of your storage account in Azure: the name and access key.”
docs.nebius.com checked 2026-10-22
“Personal access token, password or an API key.”

Checked: Nebius STS ID tokens (GCP guide; any OIDC Discovery consumer, so AWS and Azure federated credentials work by the same mechanism though no guide exists), Managed Kubernetes cluster OIDC issuers, Object Storage Data Transfer (S3-compatible sources such as AWS S3 and Azure Blob), Serverless AI jobs and endpoints pulling from Docker Hub, GHCR, Azure, NGC or custom registries, and the Wiz integration (Wiz reaching into Nebius, an inbound credential). The keyless path is "the product is itself an OIDC issuer I can trust", for workload code you write. Nebius's own managed services that reach into your clouds do not use it: Data Transfer wants a static S3 key pair or an Azure storage account key (account-wide), with least-privilege roles documented only for the Nebius side; registry credentials can be held in SecretStash but are still static. Nebius-held cross-account roles or STS-signed tokens for Data Transfer would make this A.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Mixed by key type. Static keys (Container Registry, Observability) default to six months and are capped at three years, which would pass. But authorized keys (the control-plane static root) and S3 access keys take an optional expires_at and are issued without one if it is omitted, and no org policy to force an expiry is documented. Graded on the weakest key, per the changeable-default precedent. docs.nebius.com checked 2026-10-22 “Access keys can be issued without an expiration date.” docs.nebius.com checked 2026-10-22 “(Optional) Set an expiration date.” docs.nebius.com checked 2026-10-22 “By default, the key lifetime is 6 months.”
✓ Rotation via API	Access keys, authorized keys and static keys all have create, list and delete/revoke (plus activate/deactivate) methods in the IAM API, CLI, SDKs and Terraform provider. docs.nebius.com checked 2026-10-22 “--url https://api.nebius.cloud/iam/v2/access-keys/{id}” docs.nebius.com checked 2026-10-22 “--url https://api.nebius.cloud/iam/v1/auth-public-keys/{id}” docs.nebius.com checked 2026-10-22 “--url https://api.nebius.cloud/iam/v1/static-keys/revoke”
✓ Scoped keys	Every key belongs to a service account, a purpose-built machine principal whose access comes from group memberships; access permits can grant a role on a tenant, project or single resource, and bucket policies narrow Object Storage further. Static keys are additionally pinned to one service. Keys cannot be narrower than their service account. docs.nebius.com checked 2026-10-22 “Service accounts that are used to manage resources via programming interfaces, such as the Nebius AI Cloud CLI.” docs.nebius.com checked 2026-10-22 “To follow the principle of least privilege, create custom groups and assign roles with as few permissions as possible to these groups.” docs.nebius.com checked 2026-10-22 “Each static key is issued for a specific Nebius AI Cloud service and cannot be used for other services.”
✗ Last-used visible	The AccessKey, AuthPublicKey and StaticKey resources expose state, fingerprint, algorithm and expiry but no last-used field, and no docs page mentions one. The console view was not checked. raw.githubusercontent.com checked 2026-10-22 “string aws_access_key_id = 5;” raw.githubusercontent.com checked 2026-10-22 “string fingerprint = 2;”
✗ Leak revocation	Nebius does not appear in GitHub's supported secret-scanning patterns table, in the Partner column or any other. docs.github.com checked 2026-10-22

Notes

One card for the Nebius AI Cloud platform: IAM, Compute, Managed Kubernetes, Container Registry and Object Storage share one IAM and one token. Unlike CoreWeave, federation reaches the control plane, so it is not split. The A rests on the federated-credentials resource, which is documented only in reference pages; a published GitHub Actions or generic-OIDC walkthrough and an audience condition would settle it. Two of five hygiene checks pass; mandatory expiry on authorized and access keys, a last-used timestamp and a GitHub partnership would fix the rest. Nebius Token Factory (formerly AI Studio) uses its own API keys and has its own card, nebius-ai-studio.

Badge

[![wif.tax grade](https://wif.tax/badge/nebius-ai-cloud.svg)](https://wif.tax/p/nebius-ai-cloud/)