Nscale
A NKS (Nscale Kubernetes Service)
This card is the NKS cluster API server, not the control plane that creates clusters. A cluster can trust up to eight OIDC issuers you choose, pinned by audience and claim, and can turn off Nscale credentials entirely. Clusters can also publish a public OIDC issuer for their service accounts. The default path runs kubectl through the CLI on your Nscale login or static service token, graded D on the nscale card.
Docs: docs.nscale.com · Checked 2026-10-22 · source YAML · dispute via PR
Inbound A
How a workload running anywhere authenticates to this product.
At cluster creation, spec.apiServer.authentication.externalIssuers lists up to 8 OIDC issuers (issuerURL, audiences, usernameClaim, required usernamePrefix, groupsClaim) bound to built-in cluster roles; Nscale credentials can be left on or disabled. The default kubeconfig holds no secret and calls `nscale kubernetes token`, which uses your login or NSCALE_SERVICE_TOKEN.
- Issuers
- any
- docs.nscale.com checked 2026-10-22
“You can also let people sign in with your own OpenID Connect (OIDC) provider, and give them one of the built-in roles: 'cluster-admin', 'admin', 'edit', or 'view'.”
- docs.nscale.com checked 2026-10-22
“Your provider's 'https://' URL, with no query string or fragment. It must match the 'iss' claim in your tokens exactly. Up to 8 issuers.”
- docs.nscale.com checked 2026-10-22
“At least one. The token's 'aud' claim must match one of them.”
- docs.nscale.com checked 2026-10-22
“People only get the access you bind. Someone with a valid token but no binding is refused everything.”
- raw.githubusercontent.com checked 2026-10-22
“Additional external JWT/OIDC issuers the cluster's API server trusts.”
- raw.githubusercontent.com checked 2026-10-22
“JWT claim mapped to the authenticated username.”
- docs.nscale.com checked 2026-10-22
“If you disable Nscale credentials, you must add at least one issuer, otherwise nobody could sign in.”
- docs.nscale.com checked 2026-10-22
“Credentials are refreshed the same way as for every other command, and 'NSCALE_SERVICE_TOKEN' is honored for CI.”
- docs.nscale.com checked 2026-10-22
“The kubeconfig contains no password or token.”
The externalIssuers block is kube-apiserver's JWT authenticator: any HTTPS issuer with discovery, audience required, subject mapped via usernameClaim (default sub) and bound to cluster-admin, admin, edit or view, so a GitHub Actions or cloud workload token can drive kubectl with no Nscale secret. Judgment calls a reviewer should check: the docs frame it as letting "people" sign in, but nothing restricts it to humans and the mechanism is the same one coreweave-cks was graded A on; and the A requires opting in, since the default is the CLI exec plugin on an Nscale user login or a static 90-day service token. The issuer list is fixed at creation ("It can't be changed later") and is set only through the API or CLI, and creating the cluster is itself a control-plane call that needs the service token graded on the nscale card. Only the built-in roles can be bound through the spec; finer RBAC is up to you inside the cluster.
Outbound A
How this product reaches into your cloud, repos, or other SaaS.
A cluster can publish a public OIDC issuer (oidc.nks.<region>.nscale.com/<cluster-id>) for its ServiceAccount tokens, which AWS, GCP, Azure or any other relying party can trust; NKS itself holds no credential for customer infrastructure.
- raw.githubusercontent.com checked 2026-10-22
“The public OIDC issuer URL of the cluster's ServiceAccount tokens. Use it to configure external relying parties.”
- raw.githubusercontent.com checked 2026-10-22
“It is absent when the cluster uses only its in-cluster issuer.”
- docs.nscale.com checked 2026-10-22
“Applications running in the cluster should use projected ServiceAccount tokens.”
- docs.nscale.com checked 2026-10-22
“A request for longer is shortened to 24 hours without an error, so check the expiry you get back.”
NKS has no managed integration that pulls from a customer's cloud, registry or SaaS (image pulls use whatever pull secrets you put in the cluster). The outbound story is "the product is itself an OIDC issuer I can trust", which the rubric scores A, as on coreweave-cks. Caveats: the public issuer appears only in the NKS API spec, not the prose docs, there is no AWS, GCP or Azure setup guide, and the spec says it is absent for clusters that use only their in-cluster issuer, without documenting how to choose. If a reviewer reads that as not documented for workloads, outbound would be N/A and the headline stays A.
Hygiene for any static credential the product still issues
| ✓ Expiry enforceable | Hygiene here is the static credential behind the default path: the Nscale service token the CLI exec plugin presents in CI. The OIDC path has no Nscale-issued secret. The 90 days is a server-side setting, not a request field, so a non-expiring token cannot be minted; see the nscale card.
|
| ✓ Rotation via API | The kubeconfig carries no token, so rotating the service token needs no kubeconfig change.
|
| ✓ Scoped keys | A service account gets cluster access through the nks:kubernetes-api permission on its groups' roles, scoped to projects: read maps to view, update to cluster-admin. Coarse, but a purpose-built machine principal with its own role, which the rubric counts.
|
| ✗ Last-used visible | Service accounts carry expiry but no last-used field; only human users have lastActive.
|
| ✗ Leak revocation | Nscale is not in GitHub's secret-scanning patterns table.
|
Notes
Split from the nscale card because the cluster API server can trust your own OIDC issuers while the rest of Nscale takes only a static service token. The A holds only for clusters created with externalIssuers (ideally with Nscale credentials disabled); the default path's hygiene is what the checks above show.
Badge
[](https://wif.tax/p/nscale-nks/)