This page introduces the authentication methods and access control options for managing user and workload access to CoreWeave Kubernetes Service (CKS) clusters. Use it to choose the approach that best fits your organization’s identity and security requirements.
Organization access
CoreWeave supports several authentication methods for your CKS organization. The following sections describe each option and link to detailed setup guidance.
Managed Auth
Managed Auth is the recommended path for handling user authorization in CKS.
SAML SSO
Security Assertion Markup Language (SAML) is a protocol that enables the single sign-on (SSO) authentication method, which lets organization users identify themselves to services like CoreWeave Kubernetes Service and the CoreWeave Cloud Console. CoreWeave supports SAML SSO as an organization-wide authentication method.
See the SAML SSO introduction for setup details.
OIDC workload identity federation for CKS
Traditional approaches to multi-cloud authentication often rely on long-lived API keys, service account credentials, or other static secrets that you must distribute to workloads. This creates operational overhead around credential rotation, increases security risks from credential exposure, and makes it difficult to implement fine-grained access controls across different cloud providers.
OIDC workload identity transforms your CKS cluster into a trusted identity provider that can authenticate your workloads to external services without static credentials. Instead of managing secrets, your applications use short-lived tokens that Kubernetes issues. Kubernetes rotates these tokens automatically, and you can configure them with precise permissions using each cloud provider’s native IAM systems.
This approach eliminates credential sprawl while providing the security and operational benefits that multi-cloud architectures require. You can configure external services like AWS, GCP, and various SaaS platforms to trust tokens that your CKS cluster issues, enabling authentication without the traditional secret management overhead.
See the OIDC workload identity introduction for setup details. 
