Skip to main content

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.

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

​
Prerequisites

Prior to completing these steps, the following prerequisites need to be in place: In your CoreWeave organization, you need to have the following:
  • 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 need to have the following:
  • 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 enables pods running in the cluster to exchange their projected service account tokens for temporary S3 credentials.
  1. Launch your CKS cluster.
  2. In the Cloud Console, retrieve the OIDC Issuer URL for 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.
  3. Configure OIDC Workload Identity Federation in the Cloud Console using this OIDC Issuer URL.
    • Note: Your organization must be flagged for this feature.
  4. 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 both the Issuer URL and Client ID (Audience) fields.
    • Click Create to save the configuration.

​
Configure kubectl and create a Kubernetes service account

  1. 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.
  2. Using the kubeconfig you downloaded, export an environment variable that kubectl will use to locate your kubeconfig. Fill in the path to the kubeconfig file you downloaded: 
    export KUBECONFIG=[PATH-TO-KUBECONFIG-FILE]
  3. Test that your kubectl installation is working: 
    kubectl config get-contexts
kubectl get nodes
    If the environment variable is set properly, you should see the context you downloaded for your CKS environment from your kubeconfig.yaml file and you should see running nodes for your CoreWeave environment.
  4. Create a Kubernetes service account by creating a .yaml file with the following data and saving it to a file named test-service-account.yaml:
    test-service-account.yaml
    apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-service-account
  namespace: default
  5. Create the account: 
    kubectl apply -f test-service-account.yaml
  6. Verify the account has been created: 
    kubectl get serviceaccounts
    If successful, test-service-account will be 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

  • You can define AI Object Storage policies referencing a role of the form <issuer>:<subject> where the issuer is discovered via the well-known URL and subject follows a standard pattern for Kubernetes service accounts, based on namespace and service account name.
  • To get the OIDC well-known URL, you can go to the Cloud Console and navigate to Clusters -> [Your Cluster Name], and copy the OIDC Issuer URL.
Using the service account created, use the following syntax for principals when creating your AI Object Storage org and bucket policies:
Principal TypeSyntax
Principal[OIDC-ISSUER-URL]:system:serviceaccount:default:test-service-account
Org 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 [OIDC-ISSUER-URL] with the OIDC Issuer URL you copied from your cluster’s details panel, and replace [YOUR-CONTAINER-IMAGE] with your application’s container image: To work with AI Object Storage, you need to configure your Pod’s S3 endpoints to use virtual addressing style and set the appropriate endpoint URL.
Because the environment variables handle credential exchange, your application only needs to configure the S3 endpoint and addressing style. For example, with the AWS CLI:
aws configure set s3.addressing_style virtual
aws configure set endpoint_url "http://cwlota.com"
Alternatively, this file can be mounted into the container from a ConfigMap, with the AWS_CONFIG_FILE variable set to the location of the mounted file.
[default]
s3 =
    addressing_style = virtual
endpoint_url = http://cwlota.com
Use the LOTA endpoint (cwlota.com) when your workloads run inside a CKS cluster 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: [YOUR-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/[YOUR-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: "[OIDC-ISSUER-URL]"
          expirationSeconds: 3600
  1. 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 expirationSeconds.

​
Verify the setup (optional)

To confirm the projected token exchange works before deploying your real workload, create a test pod using 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/[YOUR-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: "[OIDC-ISSUER-URL]"
          expirationSeconds: 3600
  1. Apply the test pod: 
    kubectl apply -f test-manual-pod.yaml
  2. Check the pod logs for the response: 
    kubectl logs test-manual-oidc
    If your OIDC configuration and organization access policies are configured correctly, you should see a JSON response listing your buckets. If you see an AccessDenied error, verify that your organization access policies grant the s3:ListAllMyBuckets action to the correct WIF principal.
  3. Clean up the test pod: 
    kubectl delete pod test-manual-oidc

​
Validate locally (optional)

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 is useful for one-time testing and debugging. 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

curl \
    -H "Authorization: $(kubectl create token -n default test-service-account)" \
    "https://api.coreweave.com/v1/cwobject/temporary-credentials/oidc/[YOUR-ORG-ID]" | jq
If the authentication is successful, there will be a response like this 
{
  "AccessKeyId": "CW...",
  "SecretAccessKey": "<redacted>",
  "Token": "",
  "Expiration":"2026-03-14T21:44:43Z",
  "attributes": {
    "cw-role": "https://[CKS-OIDC-ISSUER]:system:serviceaccount:default:test-service-account"
  }
}

​
Test access with the AWS CLI

Configure a local AWS CLI profile to use auth.sh as the credential process. These commands set the virtual addressing style, set the credential process, set the region, and set 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/[YOUR-ORG-ID]"

aws configure set s3.addressing_style virtual --profile cw-test
aws configure set credential_process "./auth.sh" --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 only accessible from within CoreWeave clusters.
Run an S3 command to verify the credential exchange works: 
aws s3api list-buckets --profile cw-test

​
Next steps

Last modified on April 30, 2026