CoreWeave

A CKS (Kubernetes Service)

This card is the cluster API server, not the control plane that creates clusters. Under "unmanaged auth" a cluster trusts whatever OIDC issuer you configure, and every cluster is itself a public OIDC issuer your other clouds can trust. The default "managed auth" mode instead rides on the static control-plane token graded F on the coreweave-api card.

Docs: docs.coreweave.com · Checked 2026-09-16 · source YAML · dispute via PR

Inbound A

How a workload running anywhere authenticates to this product.

Unmanaged auth lets a cluster's api-server trust a customer-configured OIDC issuer (issuerUrl, clientId, usernameClaim, groupsClaim, requiredClaim, signingAlgorithms) or Kubernetes service-account tokens; managed auth (the default) uses a Cloud Console API Access Token embedded in a kubeconfig.

Issuers: any

docs.coreweave.com checked 2026-09-16
“OpenID Connect (OIDC) configuration for authentication to the cluster's api-server.”
docs.coreweave.com checked 2026-09-16
“The whole object is optional on the cluster, but when supplied, issuerUrl and clientId are required within it.”
docs.coreweave.com checked 2026-09-16
“A claim that must be present on every token for authentication to succeed.”
docs.coreweave.com checked 2026-09-16
“To enable OIDC, the Issuer URL and Client ID fields are required. All other fields are optional.”
docs.coreweave.com checked 2026-09-16
“Unmanaged authentication API for CKS clusters, enabling OIDC, Service Account, and Webhook authentication”
docs.coreweave.com checked 2026-09-16
“Managed auth is the default.”

The OIDC object maps to kube-apiserver's OIDC authenticator: any issuer with a discovery document, audience pinned by clientId, subject/claims constrained via requiredClaim and the username/groups claims. Shipped 2025-07-07 as an additive change that can be enabled on existing clusters. Two caveats: managed auth is the default and routes through the static control-plane token, so the A requires opting in to unmanaged auth; and turning the feature on (creating or updating the cluster) is itself a control-plane call that needs that static token. Private clusters are not self-service ("contact CoreWeave Support").

Outbound A

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

Every CKS cluster is an OIDC issuer with a public discovery document and JWKS at oidc.cks.coreweave.com/id/[CLUSTER-ID]; workloads present projected service-account tokens to AWS, GCP or any other OIDC-trusting service, so no CoreWeave-held cloud credential exists.

docs.coreweave.com checked 2026-09-16
“Each CKS cluster acts as an OIDC identity provider (IdP) that issues secure tokens to workloads running under specific Kubernetes Service Accounts.”
docs.coreweave.com checked 2026-09-16
“CKS publishes a public OIDC Document Discovery URL even for clusters whose API endpoints aren't exposed to the internet.”
docs.coreweave.com checked 2026-09-16
“OIDC Workload Identity is generally available and enabled by default on every CKS cluster, including sandbox clusters. No action is required to turn it on, and it can't be disabled.”
docs.coreweave.com checked 2026-09-16
“Multi-cloud authentication: Authenticate CKS workloads to AWS, GCP, and other OIDC-compatible services.”

CKS has no managed integrations that pull from a customer's cloud; the outbound story is "the product is itself an OIDC issuer I can trust", which the rubric scores A. AWS and GCP have guides; Azure federated credentials accept any public OIDC issuer but no CoreWeave guide was found. Shipped 2025-11-20.

Hygiene for any static credential the product still issues

✓ Expiry enforceable	Hygiene here is graded on the managed-auth kubeconfig, which embeds a static API Access Token in users.user.token; the unmanaged-auth OIDC path has no CoreWeave-issued static credential. Default, maximum, and org enforcement of the expiry are undocumented. docs.coreweave.com checked 2026-09-16 “Tokens have an expiration date, so a token that worked previously can expire between sessions.” docs.coreweave.com checked 2026-09-16 “Expiration How long the token remains valid.”
✗ Rotation via API	Tokens and kubeconfigs are minted and revoked only in the Cloud Console. docs.coreweave.com checked 2026-09-16 “You can view or delete Access Tokens on the Access Tokens dashboard”
✗ Scoped keys	The kubeconfig is scoped to a cluster, but the embedded token is the user's full control-plane token, so a leaked kubeconfig leaks more than cluster access. docs.coreweave.com checked 2026-09-16 “user-scoped and grant permissions to deploy CKS clusters and VPCs, access cluster metrics, and authenticate against the managed-auth endpoint.”
✗ Last-used visible	No last-used timestamp is documented for API Access Tokens or kubeconfigs. Graded conservatively. docs.coreweave.com checked 2026-09-16
✗ Leak revocation	CoreWeave is not on GitHub's secret-scanning list. docs.github.com checked 2026-09-16

Notes

Home team, graded on the same rubric as everyone else. The A holds only if you switch the cluster to unmanaged auth; the managed-auth default is the control-plane token in a kubeconfig, and its hygiene is what the checks above show.

Badge

[![wif.tax grade](https://wif.tax/badge/coreweave-cks.svg)](https://wif.tax/p/coreweave-cks/)