Manual OIDC token exchange for Object Storage

This guide describes how to manually configure OIDC Workload Identity Federation between a CKS cluster and AI Object Storage so that CKS workloads can authenticate to AI Object Storage without long-lived static credentials. The resulting Pod receives a projected service account token that it exchanges for temporary S3 credentials at runtime. You can do this automatically with minimal configuration by installing the Pod Identity Webhook. Use this guide when you need full control over the token exchange or for debugging.

Prerequisites

Before you begin, make sure you have the following in place. In your CoreWeave organization, you must have:

A deployed CKS cluster with OIDC Workload Identity enabled.
A user with the appropriate permissions to create and deploy AI Object Storage buckets and policies. These are enabled using an IAM Access Policy tied to the principal with the Object Storage Admin role, or an AI Object Storage organization access policy that grants the following permissions: s3:CreateBucket, cwobject:CreateAccessKey, cwobject:EnsureAccessPolicy, cwobject:ListAccessPolicy, cwobject:DeleteAccessPolicy.

In your local environment, you must have:

A terminal. This tutorial is written for bash and zsh.
kubectl installed and accessible from your terminal path.
An S3 CLI client installed and accessible from your terminal path. This guide uses the AWS CLI but any S3 CLI should work.

Configure the CKS OIDC provider

Register your CKS cluster as a trusted OIDC identity provider for AI Object Storage. This lets Pods running in the cluster exchange their projected service account tokens for temporary S3 credentials.

Launch your CKS cluster.
In the Cloud Console, retrieve the OIDC Issuer URL of your CKS cluster:
- Go to the Clusters page.
- Click the name of your desired cluster. A cluster details panel opens on the right.
- Copy the OIDC Issuer URL from the Overview section.
Configure OIDC Workload Identity Federation in the Cloud Console using this OIDC Issuer URL.
Your organization must be flagged for this feature.
Create a new OIDC configuration in the Workload Federation page.
- Click Create OIDC configuration. The configuration form opens.
- Set the configuration name (choose a name that indicates it is for federating CKS tokens with AI Object Storage).
- Enter the CKS cluster’s OIDC Issuer URL that you copied earlier into the Issuer URL field.
- Set the Client ID (Audience) field to https://coreweave.com/iam (recommended) or choose another audience.
- Click Create to save the configuration.

Configure `kubectl` and create a Kubernetes service account

Download a kubeconfig for your CKS cluster:
1. Go to the Tokens page.
2. Click Create Token. The token creation form opens.
3. Set the context for your cluster.
4. Click Download to download the kubeconfig.
Using the kubeconfig you downloaded, export an environment variable that kubectl uses to locate your kubeconfig. Fill in the path to the kubeconfig file you downloaded:
export KUBECONFIG=[PATH-TO-KUBECONFIG-FILE]
Test that your kubectl installation works:
kubectl config get-contexts kubectl get nodes
If the environment variable is set properly, you see the context you downloaded for your CKS environment from your kubeconfig.yaml file, and you see running Nodes for your CoreWeave environment.
Create a Kubernetes service account. Create a .yaml file with the following data and save it to a file named test-service-account.yaml:
test-service-account.yaml
apiVersion: v1 kind: ServiceAccount metadata: name: test-service-account namespace: default

Create the account:

kubectl apply -f test-service-account.yaml

Verify the account is created:
kubectl get serviceaccounts
If successful, test-service-account is visible.

Grant the service account access to Object Storage

You must grant the service account’s federated identity access to AI Object Storage through an organization access policy. Use the OIDC Issuer URL you copied earlier and the service account name to construct the WIF principal:

role/[OIDC-ISSUER-URL]:system:serviceaccount:default:test-service-account

Replace [OIDC-ISSUER-URL] with the OIDC Issuer URL from your cluster’s details panel. The following example policy grants the service account full S3 access to all buckets in your organization:

{
  "policy": {
    "version": "v1alpha1",
    "name": "wif-service-account-access",
    "statements": [
      {
        "name": "allow-s3-access-for-cks-workload",
        "effect": "Allow",
        "actions": ["s3:*", "cwobject:CreateAccessKeyOIDC"],
        "resources": ["*"],
        "principals": ["role/[OIDC-ISSUER-URL]:system:serviceaccount:default:test-service-account"]
      }
    ]
  }
}

Create this policy using the Cloud Console, with the CoreWeave Terraform Provider, or the AI Object Storage API. For more granular policies (read-only access, specific buckets, multiple principals), see Organization access policy examples.

Set up the workload

With the service account created and granted access, reference it from your AI Object Storage policies and from your workload Pod.

You can define AI Object Storage policies that reference a role of the form [ISSUER]:[SUBJECT], where the issuer is discovered through the well-known URL and the subject follows a standard pattern for Kubernetes service accounts, based on namespace and service account name.
To get the OIDC well-known URL, go to the Cloud Console, navigate to the Clusters page, select your cluster, and copy the OIDC Issuer URL.

Using the service account you created, use the following syntax for principals when you create your AI Object Storage org and bucket policies:

Principal type	Syntax
Principal	`[OIDC-ISSUER-URL]:system:serviceaccount:default:test-service-account`
Organization policy `"principals"`	`["role/[OIDC-ISSUER-URL]:system:serviceaccount:default:test-service-account"]`
Bucket policy `"Principal"`	`{"AWS": "arn:aws:iam::[ORG-ID]:role/[OIDC-ISSUER-URL]:system:serviceaccount:default:test-service-account"}`

Create the workload Pod

Create a Pod manifest that mounts a projected service account token with the correct audience. The Pod uses this token to exchange for temporary AI Object Storage credentials at runtime. Replace [ORG-ID] with your CoreWeave organization ID, and replace [CONTAINER-IMAGE] with your application’s container image: To work with AI Object Storage, configure your Pod’s S3 endpoints to use virtual addressing style and set the appropriate endpoint URL.

Configure S3 endpoints for Pods

Because the environment variables handle credential exchange, you only need to configure the S3 endpoint and addressing style in your application. For example, with the AWS CLI:

aws configure set s3.addressing_style virtual
aws configure set endpoint_url "http://cwlota.com"

Alternatively, you can mount this configuration file into the container from a ConfigMap and set the AWS_CONFIG_FILE variable to the location of the mounted file.

[default]
s3 =
    addressing_style = virtual
endpoint_url = http://cwlota.com

When your workloads run inside a CKS cluster, use the LOTA endpoint (cwlota.com) for optimal performance. For more configuration options (Boto3, s3cmd, Multi-Storage Client), see Attaching endpoints.

workload-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-workload
  namespace: default
spec:
  serviceAccountName: test-service-account
  containers:
  - name: app
    image: "[CONTAINER-IMAGE]"
    env:
    - name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
      value: /var/run/secrets/tokens/oidc-token
    - name: AWS_CONTAINER_CREDENTIALS_FULL_URI
      value: "https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[ORG-ID]"
    - name: AWS_DEFAULT_REGION
      value: "US-EAST-04A"
    volumeMounts:
    - name: oidc-token
      mountPath: /var/run/secrets/tokens
      readOnly: true
  volumes:
  - name: oidc-token
    projected:
      sources:
      - serviceAccountToken:
          path: oidc-token
          audience: "https://coreweave.com/iam"   # Or a custom audience
          expirationSeconds: 3600

Apply the manifest:
kubectl apply -f workload-pod.yaml

The projected token is mounted at /var/run/secrets/tokens/oidc-token inside the Pod. AWS SDKs and the AWS CLI automatically use the AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE and AWS_CONTAINER_CREDENTIALS_FULL_URI environment variables to exchange the OIDC token for temporary S3 credentials. Credentials rotate automatically based on the expirationSeconds value.

Optional: Verify the setup

To confirm the projected token exchange works before you deploy your real workload, create a test Pod that uses the amazon/aws-cli image:

test-manual-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-manual-oidc
  namespace: default
spec:
  serviceAccountName: test-service-account
  containers:
  - name: test
    image: amazon/aws-cli
    command:
    - sh
    - -c
    - |
        aws configure set s3.addressing_style virtual
        aws configure set endpoint_url http://cwlota.com
        aws s3api list-buckets
    env:
    - name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
      value: /var/run/secrets/tokens/oidc-token
    - name: AWS_CONTAINER_CREDENTIALS_FULL_URI
      value: "https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[ORG-ID]"
    - name: AWS_DEFAULT_REGION
      value: "US-EAST-04A"
    volumeMounts:
    - name: oidc-token
      mountPath: /var/run/secrets/tokens
      readOnly: true
  volumes:
  - name: oidc-token
    projected:
      sources:
      - serviceAccountToken:
          path: oidc-token
          audience: "https://coreweave.com/iam"   # Or a custom audience
          expirationSeconds: 3600

Apply the test Pod:
kubectl apply -f test-manual-pod.yaml
Check the Pod logs for the response:
kubectl logs test-manual-oidc
If your OIDC configuration and organization access policies are configured correctly, you see a JSON response that lists your buckets. If you see an AccessDenied error, verify that your organization access policies grant the s3:ListAllMyBuckets action to the correct WIF principal.
Clean up the test Pod:
kubectl delete pod test-manual-oidc

Optional: Validate locally

You can also validate the OIDC token exchange from your local machine, outside of a Kubernetes Pod, by creating a service account token and calling the credential endpoint directly. This helps with one-time testing and debugging when you want to isolate the credential exchange from the rest of your workload. Additional local prerequisites:

curl for calling the credential endpoint.
jq for parsing JSON responses.
jwt.io (optional) for inspecting OIDC token contents.

Test that the service account token can authenticate

Create a service account token and exchange it for temporary AI Object Storage credentials. Replace [ORG-ID] with your CoreWeave organization ID:

curl \
    -H "Authorization: $(kubectl create token -n default test-service-account)" \
    "https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[ORG-ID]" | jq

If authentication succeeds, you see a response similar to the following:

{
  "AccessKeyId": "CWAKIAEXAMPLE1234567",
  "SecretAccessKey": "wJalrXUtnFEMIK7MDENGbPxRfiCYEXAMPLEKEY",
  "Token": "",
  "Expiration": "2026-03-14T21:44:43Z",
  "attributes": {
    "cw-role": "https://oidc.example.coreweave.com/abc123:system:serviceaccount:default:test-service-account"
  }
}

Test access with the AWS CLI

Configure a local AWS CLI profile that uses a credential process script to fetch temporary credentials. Replace [CREDENTIAL-SCRIPT-PATH] with the path to your credential script (for example, /bin/cw-auth.sh). The script must obtain a service account token, exchange it at the credential endpoint, and return JSON in the format the AWS CLI expects. For a full walkthrough of writing this script, see Workload Identity Federation with a credential process. The following commands set the virtual addressing style, the credential process, the region, and the endpoint URL in a new profile called cw-test:

export AWS_CONTAINER_AUTHORIZATION_TOKEN=$(kubectl create token -n default test-service-account)
export AWS_CONTAINER_CREDENTIALS_FULL_URI="https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[ORG-ID]"

aws configure set s3.addressing_style virtual --profile cw-test
aws configure set credential_process "[CREDENTIAL-SCRIPT-PATH]" --profile cw-test
aws configure set region "US-EAST-04A" --profile cw-test
aws configure set endpoint_url "https://cwobject.com" --profile cw-test

Use the primary endpoint (https://cwobject.com) for local testing because the LOTA endpoint (http://cwlota.com) is accessible only from within CoreWeave clusters.

Run an S3 command to verify the credential exchange works:

aws s3api list-buckets --profile cw-test

Next steps

To use the automatic method instead, see Automatic authentication with the Pod Identity Webhook.
Learn more about OIDC Workload Identity for CKS.
Learn more about Workload Identity Federation for AI Object Storage.

​Prerequisites

​Configure the CKS OIDC provider

​Configure kubectl and create a Kubernetes service account

​Grant the service account access to Object Storage

​Set up the workload

​Create the workload Pod

​Optional: Verify the setup

​Optional: Validate locally

​Test that the service account token can authenticate

​Test access with the AWS CLI

​Next steps

Prerequisites

Configure the CKS OIDC provider

Configure `kubectl` and create a Kubernetes service account

Grant the service account access to Object Storage

Set up the workload

Create the workload Pod

Optional: Verify the setup

Optional: Validate locally

Test that the service account token can authenticate

Test access with the AWS CLI

Next steps