Skip to main content
OIDC Workload Identity for CoreWeave Kubernetes Service (CKS) lets your workloads authenticate with services across multiple clouds using the OpenID Connect (OIDC) protocol. OIDC addresses a common challenge for multi-cloud AI and Kubernetes users: it establishes identity and access management between CKS workloads and external services without the operational risks of managing long-lived credentials.

​
When to use OIDC Workload Identity

OIDC Workload Identity helps applications that need to authenticate with multiple cloud providers or external services. Rather than managing static API keys or service account credentials across different environments, your workloads can use short-lived tokens that Kubernetes issues and rotates automatically. This removes credential distribution and rotation overhead while enabling fine-grained access control through each provider’s built-in IAM systems. This approach works well for both public and private clusters, because the OIDC metadata endpoints don’t expose sensitive cluster information.

​
How OIDC works

OIDC (OpenID Connect) is an industry-standard protocol for federated identity, widely supported by public cloud service providers (CSPs) and many SaaS platforms. On CoreWeave, each CKS cluster acts as an OIDC identity provider (IdP) that issues secure tokens to workloads running under specific Kubernetes Service Accounts. These tokens let workloads authenticate to any external service (including AWS, GCP, and many SaaS tools) configured to trust the CKS cluster’s OIDC identity. This approach eliminates the need to manually generate, distribute, or rotate secrets.

​
Your CKS cluster as a trusted OIDC IdP

Every CKS cluster publishes a public OIDC Document Discovery URL (such as https://oidc.cks.coreweave.com/id/xxxxx), where external services can discover identity metadata and cryptographic keys. This lets you configure AWS, GCP, or other services to recognize your cluster as an identity authority.

​
Service account tokens

Workloads running in CKS acquire their identity through Kubernetes Service Account tokens that the cluster signs and issues. When configured for OIDC Workload Identity, these tokens contain claims that external CSPs recognize.

​
Federated authentication flow

Federated authentication ties these pieces together so workloads can reach external services using their cluster-issued identity. The flow has three parts:
  • Register the CKS OIDC issuer URL in your target cloud or service provider (for example, as an OIDC provider in AWS or inside a GCP Workload Identity Pool).
  • Authorize your Service Accounts to access specific resources by writing CSP IAM policies that reference claims from those tokens (such as Kubernetes namespace and ServiceAccount name).
  • Allow workloads to authenticate to external APIs by presenting their CKS-issued token, with no external secrets required.

​
Next steps

For end-to-end procedures that apply these concepts to specific cloud providers, see the following tutorials:
Learn how to secure access to Google Cloud Storage from CKS Pods using OIDC federation.
Learn how to authenticate CKS workloads to AI Object Storage using OIDC Workload Federation.
Last modified on June 10, 2026