> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# CKS Workload Federation for AI Object Storage

> Authenticate CKS workloads to AI Object Storage using OIDC Workload Identity Federation

This guide describes how to request access tokens for CoreWeave AI Object Storage operations through federation between CKS clusters (operating as OIDC Providers) and an organization's Object Storage infrastructure.

## Prerequisites

* A [CKS cluster](/products/cks/clusters/create) with [OIDC Workload Identity](/products/cks/auth-access/workload-identity/introduction) enabled.
* An AI Object Storage bucket. For setup instructions, see [Get started with AI Object Storage](/products/storage/object-storage/get-started-caios).
* The roles or granular permissions required by the setup tasks. The automatic and manual guides list both options.

## Authentication methods

CKS Workload Federation supports two methods for authenticating to AI Object Storage:

* [Automatic](/security/tutorials/cks-object-storage-authentication/automatic) using the Pod Identity Webhook, which is recommended for most use cases.
* [Manual](/security/tutorials/cks-object-storage-authentication/manual) by configuring the OIDC Workload Federation manually, which is useful for debugging or when the Pod Identity Webhook isn't available.

## How the three authorization systems relate

CoreWeave uses separate authorization systems that apply at different stages of this setup:

| System | What it controls | When it applies in this flow |
| - | - | - |
| [CoreWeave IAM Access Policies](/security/iam/access-policies) | Who can manage the platform and Object Storage control plane (create clusters, create buckets, edit org policies, create WIF config). The **Object Storage Admin** role doesn't grant S3 data access. | Roles cover broad administrative tasks such as creating the cluster, configuring OIDC Workload Federation, and initially managing organization access policies. |
| [Kubeconfig](/products/cks/auth-access/managed-auth/kubeconfig) and Kubernetes RBAC | A kubeconfig is a config file with the cluster server URL and an API key (the same type used for other CoreWeave APIs). No separate kubeconfig permissions are required. [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) controls what you can do inside the cluster (for example, creating Pods and service accounts). | You use a kubeconfig to run `kubectl` and create the workload. The API key authenticates you to the cluster, and Kubernetes RBAC authorizes your requests. |
| [AI Object Storage org and bucket access policies](/products/storage/object-storage/auth-access/organization-policies/about) | Who can perform Object Storage control-plane and S3 operations. Principals include CoreWeave users and federated OIDC roles such as `role/[ISSUER]:system:serviceaccount:namespace:name`. | An existing organization policy can delegate granular `cwobject:` actions to users. When a Pod uses OIDC, grant its WIF principal `cwobject:CreateAccessKeyOIDC` plus only the S3 actions that the workload needs. |

In short: IAM governs your ability to manage the platform and create the cluster. The API key in your kubeconfig (the same type as for other CoreWeave APIs) authenticates you to the cluster, and Kubernetes RBAC governs what you can do inside it. Org and bucket policies govern what each identity (including the Pod's OIDC role) can do with AI Object Storage data.