Skip to main content

Introduction to OIDC Workload Identity for CKS

Learn how OIDC Workload Identity eliminates credential management overhead by enabling CKS workloads to authenticate directly to cloud services

OIDC Workload Identity for CoreWeave Kubernetes Service (CKS) delivers a secure way for your workloads to authenticate with services across multiple clouds using the OpenID Connect (OIDC) protocol. OIDC addresses a key challenge for multi-cloud AI and Kubernetes users: establishing secure, scalable identity and access management between CKS workloads and external services without the operational risks and burdens of managing long-lived credentials.

When to use OIDC Workload Identity

OIDC Workload Identity is valuable for 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 eliminates credential distribution and rotation overhead while enabling fine-grained access control through each provider's native IAM systems. This approach works well for both public and private clusters, since 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), issuing 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, which eliminates the need for manually generated, distributed, or rotated 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 makes it simple to configure AWS, GCP, or other services to recognize your cluster as an identity authority.

Service account tokens

Workloads running in CKS acquire their identity via Kubernetes Service Account tokens, signed and issued by the cluster. When configured for OIDC Workload Identity, these tokens contain claims recognized by external CSPs.

Federated authentication flow

The CKS OIDC issuer URL is registered in your target cloud or service provider (for example, as an OIDC provider in AWS or inside a GCP Workload Identity Pool). Your Service Accounts are authorized to access specific resources by writing CSP IAM policies referencing claims from those tokens (such as Kubernetes namespace and ServiceAccount name). Workloads authenticate to external APIs by presenting their CKS-issued token, with no external secrets required.