Skip to main content
This tutorial shows you how to deploy CKS Workload Federation for AI Object Storage automatically by configuring the Pod Identity Webhook. With the webhook in place, your Pods receive AI Object Storage credentials automatically through their service account, so your workloads can access buckets without managing long-lived access keys. By the end, you’ll have a CKS cluster federated with AI Object Storage and a sample workload that uses an annotated service account to obtain credentials on demand.

​
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 later.
  • 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 minimal 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
    The Pod Identity Webhook is now running in your cluster, ready to inject credentials into annotated Pods.

​
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 need this URL again when you configure access policies.
  2. On the Workload Federation page, create a new OIDC Configuration:
    • Click Create OIDC configuration. The configuration form opens.
    • Set the configuration name (choose a name that indicates it’s 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.
With the OIDC configuration in place, AI Object Storage trusts tokens issued by your CKS cluster and can map them to access policies.

​
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. After the policy is in place, the service account’s federated identity is authorized to call AI Object Storage.

​
Create a workload that uses the service account

With federation, the service account, and an access policy all configured, you can now deploy a workload that obtains credentials through the webhook. This example creates a Pod that uses the service account you created earlier.
  1. Configure the Pod’s S3 endpoints: To work with AI Object Storage, configure your Pod’s S3 endpoints to use virtual addressing style and set the appropriate endpoint URL.
    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.
  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: "[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.

​
Optional: Verify the webhook injection

To confirm the Pod Identity Webhook injects credentials correctly before you deploy your real workload, create a test Pod that uses 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 June 10, 2026