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 tutorial demonstrates how to deploy CKS Workload Federation for AI Object Storage automatically by configuring the Pod Identity Webhook.

​
Prerequisites

  • A CKS cluster with OIDC Workload Identity enabled on the cluster. The AI Object Storage federation configuration is covered in the steps below.
  • Helm version 3.8 or higher.
  • kubectl installed and configured for your cluster.
  • Appropriate IAM roles (for example, CKS Admin and Object Storage Admin) assigned through an IAM Access Policy.

​
Install the Pod Identity Webhook

If you install the Pod Identity Webhook, you can use AI Object Storage with very little configuration. You can install the Pod Identity Webhook from CoreWeave Charts with the following steps:
  1. Set environment variables for your organization ID and region: 
    export ORG_ID=[YOUR-ORG-ID]
export REGION=[YOUR-REGION]
    • Replace [YOUR-ORG-ID] with your organization’s ID. You can find your organization ID on the CoreWeave Console settings page.
    • Replace [YOUR-REGION] with your CoreWeave availability zone. Make sure to use an eligible CoreWeave availability zone that supports AI Object Storage.
    • US-CENTRAL-05A
    • US-CENTRAL-06A
    • US-CENTRAL-07A
    • US-CENTRAL-08A
    • US-CENTRAL-08B
    Learn more about Regions and Availability Zones.
  2. Add the CoreWeave Charts repository and install the Pod Identity Webhook: 
    helm repo add coreweave https://charts.core-services.ingress.coreweave.com
helm install pod-identity-webhook coreweave/pod-identity-webhook -n pod-identity-webhook --create-namespace --set config.orgID=$ORG_ID --set config.region=$REGION
    Successful output should look like this: 
    "coreweave" has been added to your repositories
NAME: cks
LAST DEPLOYED: Fri Mar 13 20:05:00 2026
NAMESPACE: default
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete

​
Configure OIDC Workload Federation

Before the Pod Identity Webhook can obtain credentials, you must register your CKS cluster as an OIDC provider for AI Object Storage. Your cluster must have OIDC Workload Identity enabled so it can issue signed tokens.
  1. In the Cloud Console, retrieve the OIDC Issuer URL for your CKS cluster:
    • Go to the Clusters page.
    • Click the name of your cluster. A cluster details panel opens on the right.
    • Copy the OIDC Issuer URL from the Overview section. You will need this URL again when configuring access policies.
  2. 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 into both the Issuer URL and Client ID (Audience) fields.
    • Click Create to save the configuration.

​
Use your service account

The Pod Identity Webhook injects the configuration your pods need to obtain AI Object Storage credentials. Add one of these annotations to the Service Account that your workload uses:
Audience TypeAnnotation Syntax
Default audiencecaios.coreweave.com/inject: "true"
Custom audiencecaios.coreweave.com/audience: custom
(use when you need to match a specific WIF audience)
Create a Service Account with the appropriate annotation, then run your workload with that service account.
  1. Create the following manifest and save it to a file named object-storage-sa.yaml. This example uses the default audience annotation. Adjust it if you want to use a custom audience:
    object-storage-sa.yaml
    apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-object-storage-sa
  namespace: default
  annotations:
    caios.coreweave.com/inject: "true"
  2. Apply the manifest to create the service account: 
    kubectl apply -f object-storage-sa.yaml
  3. Verify the service account has been created and has the appropriate annotation: 
    kubectl get serviceaccounts my-object-storage-sa -o jsonpath='{.metadata.annotations.caios\.coreweave\.com/inject}'
true

​
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:my-object-storage-sa
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:my-object-storage-sa"]
      }
    ]
  }
}
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.

​
Create a workload that uses the service account

This example creates a Pod that uses the service account you just created.
  1. Configure the Pod’s S3 endpoints: 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.
  2. Create the following manifest and save it to a file named object-storage-pod.yaml, making the following adjustments:
    • Fill in the container image with the image you want to use for your workload.
    • Reference the same service account in your Pod so the Pod Identity Webhook can inject credentials:
    object-storage-pod.yaml
    apiVersion: v1
kind: Pod
metadata:
  name: my-workload
  namespace: default
spec:
  serviceAccountName: my-object-storage-sa
  containers:
  - name: app
    image: [YOUR-CONTAINER-IMAGE]
    # Your app uses the injected env or volume to obtain S3 credentials.
  3. Apply the manifest to create the workload: 
    kubectl apply -f object-storage-pod.yaml
Pods that use this service account receive the necessary environment or volume configuration to call AI Object Storage.

​
Verify the webhook injection (optional)

To confirm the Pod Identity Webhook is injecting credentials correctly before deploying your real workload, you can create a test pod using the amazon/aws-cli image and run an S3 command against AI Object Storage.
  1. Create a test pod that uses the service account and lists your buckets:
    test-webhook-pod.yaml
    apiVersion: v1
kind: Pod
metadata:
  name: test-webhook
  namespace: default
spec:
  serviceAccountName: my-object-storage-sa
  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
  2. Apply the manifest: 
    kubectl apply -f test-webhook-pod.yaml
  3. Check the pod logs for the response: 
    kubectl logs test-webhook
    If the webhook injection and your 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.
  4. Clean up the test pod: 
    kubectl delete pod test-webhook

​
Next steps

Last modified on April 30, 2026