Nscale
F Nscale cloud (control-plane API, CLI, Terraform, serverless inference, object storage)
The Nscale control-plane APIs, CLI in CI, Terraform provider and serverless inference all take one credential: a static service-account token. No federation path exists for workloads. The token has a platform-set 90-day lifetime, rotates by API and belongs to a group-scoped service account, but shows no last use and is not GitHub partner-revoked. Object storage uses static S3 keys. Importing a private Hugging Face model takes a pasted HF token. NKS clusters are graded on their own card.
Docs: docs.nscale.com · Checked 2026-10-22 · source YAML · dispute via PR
Inbound D
How a workload running anywhere authenticates to this product.
Static service-account token (a JWT shown once, sent as a Bearer token or NSCALE_SERVICE_TOKEN) accepted by the identity, compute, region, storage, NKS and reservation APIs, the CLI, the Terraform provider and the OpenAI-compatible inference API. Humans use browser or device-code login; no OIDC or token-exchange path from an external issuer is self-serve for workloads.
- docs.nscale.com checked 2026-10-22
“Each token is a signed JSON Web Token that your services can present to authenticate against the Nscale API.”
- docs.nscale.com checked 2026-10-22
“Service tokens now provide the authentication surface for all automation and integrations, offering finer-grained scoping and rotation controls.”
- docs.nscale.com checked 2026-10-22
“Service accounts provide machine-to-machine authentication for CI/CD pipelines and automated workflows.”
- docs.nscale.com checked 2026-10-22
“The provider authenticates with Nscale using a service token, which you can generate and rotate in the”
- docs.nscale.com checked 2026-10-22
“"Authorization": "Bearer <SERVICE-TOKEN>"”
- raw.githubusercontent.com checked 2026-10-22
“A long lived access token that can be exchanged for an API access token.”
- raw.githubusercontent.com checked 2026-10-22
“Domain based authentication allows integration with user provided OIDC compliant identity services.”
- raw.githubusercontent.com checked 2026-10-22
“Providers in organization namespaces are never trusted.”
- raw.githubusercontent.com checked 2026-10-22
“looks up UNI organization membership by email, and builds the userinfo and source-claims pair.”
- docs.nscale.com checked 2026-10-22
“Create credentials tied to an identity policy. The secret is returned only once”
Graded on the weakest path a workload must use to automate Nscale, which is also the only one: the service token. The identity service does implement RFC 8693 token exchange and can accept bearer tokens from external OIDC issuers, but its source shows that trust is set by Nscale's operators in the identity operator namespace ("Providers in organization namespaces are never trusted"), each token must carry a verified email and map to an existing member, and none of it is in the public docs or customer API (the org-level OAuth2 provider object has only issuer, client ID and secret, for browser login). That is human SSO, not workload federation, so it does not lift the grade. The "exchange" of a service token for a passport JWT happens inside Nscale's API edge; the workload still holds the long-lived service token, so this is D rather than C. Sibling credentials on the same cloud: object storage takes static S3 access key/secret pairs per endpoint, with AWS-style identity policies for scoping and API create/delete, but no expiry or last-used field in the Storage API; dedicated model deployments (private cloud beta) mint their own static endpoint access key. Legacy Nscale API keys were removed on 2025-11-01. Three of five hygiene checks pass, so D; inbound moves to B or A only with self-serve token exchange from GitHub Actions or any OIDC issuer for service accounts.
Outbound Frequires Private cloud organizations (beta)
How this product reaches into your cloud, repos, or other SaaS.
Bring-your-own-model procurement pulls from Hugging Face, and for private or gated repos takes an optional raw Hugging Face token in the request body. No other documented reach-in into a customer cloud, registry or SaaS exists.
- raw.githubusercontent.com checked 2026-10-22
“Queue a Hugging Face model for procurement into the caller's private Model Catalog.”
- raw.githubusercontent.com checked 2026-10-22
“Optional raw Hugging Face token used only by the processor Job.”
- docs.nscale.com checked 2026-10-22
“The **Your Models** tab lists your project's own models.”
- raw.githubusercontent.com checked 2026-10-22
“Create a compute image from a public URL.”
- docs.nscale.com checked 2026-10-22
“Fine-tuning service”
Checked: the docs index (llms.txt) and every published OpenAPI spec in nscaledev/openapi (identity, compute, region, storage, NKS, reservation, IMS). Custom images import only from a public URL with no credential; object storage has no import or replication from customer S3, GCS or Azure; file storage, volumes and reservations reach nothing outside Nscale; serverless fine-tuning, which pushed models to Hugging Face, was removed on 2026-05-20. The one place Nscale holds a credential for a third party is IMS model procurement (the "Your Models" path of dedicated deployments): a raw, write-only Hugging Face token with no guidance on using a read-only or fine-grained token or on rotation. It appears in the published API spec but not in the prose docs, and the feature is a private-cloud beta, so a reviewer could argue it is not yet a documented integration (outbound would then be N/A and the headline D). Graded F as on cudo-compute; scoped-token guidance would make it D, and an Nscale-issued OIDC identity that Hugging Face or a customer bucket could trust would make it A or B.
Hygiene for any static credential the product still issues
| ✓ Expiry enforceable | Unlike a changeable default (see the precedent in the brief), the 90 days is not a customer choice: the create and rotate requests carry no lifetime field, and the value is a server-side flag (--default-service-account-token-lifetime) set by Nscale's operator, so a never-expiring token cannot be minted. No org policy for a shorter cap exists. A service account can rotate its own token indefinitely, so the account outlives any one token.
|
| ✓ Rotation via API | Create, rotate and delete are Identity API calls (and nscale serviceaccounts subcommands), so rotation can run from a job.
|
| ✓ Scoped keys | Service accounts are a purpose-built machine principal; their authority comes only from the groups they are placed in, and groups carry predefined roles (reader, user, reservation and others) scoped to chosen projects. No custom roles. Group and role management is documented as available to private organizations only, so a self-serve serverless org may not be able to narrow a token.
|
| ✗ Last-used visible | Users have a lastActive field; the service-account status has only expiry and the token, and the Service Tokens docs describe no last-used column. Object storage access keys have none either.
|
| ✗ Leak revocation | Nscale does not appear in GitHub's supported secret-scanning patterns table, partner or otherwise.
|
Notes
One card for the Nscale cloud's shared identity layer, which every control-plane service, serverless inference and the Terraform provider use; NKS clusters are split onto nscale-nks because their API server can trust your own OIDC issuers. Much of the detail comes from Nscale's own public specs and source (nscaledev/openapi, nscaledev/uni-identity), which the docs link. A last-used timestamp and a GitHub secret-scanning partnership would complete the hygiene; self-serve token exchange for service accounts would lift inbound.
Badge
[](https://wif.tax/p/nscale/)