Automatic authentication with the Pod Identity Webhook

This tutorial shows you how to automate CoreWeave Kubernetes Service (CKS) Workload Federation for CoreWeave AI Object Storage by configuring the Pod Identity Webhook. With the webhook in place, your Pods automatically receive the configuration needed to obtain temporary Object Storage credentials through their ServiceAccount. Your workloads can then access buckets without managing long-lived access keys. By the end, you’ll have a CKS cluster federated with Object Storage and a sample workload that uses an annotated ServiceAccount to obtain credentials on demand.

Prerequisites

A CKS cluster with OpenID Connect (OIDC) Workload Identity enabled.
helm version 3
kubectl installed and configured for your cluster.

The following table separates roles that cover the administrative tasks from the narrower permissions used by this tutorial:

Task	Role that covers the task	Granular permissions
Create or manage the CKS cluster	CKS Admin	After the cluster exists, Kubernetes RBAC controls whether you can install the Helm chart and create the tutorial’s Namespace, ServiceAccount, and Pods.
Create an OIDC Workload Federation configuration if the automatic configuration is missing	IAM Admin	CoreWeave IAM Access Policies assign roles rather than individual IAM actions.
Create and view the Object Storage organization access policy	Object Storage Admin	`cwobject:EnsureAccessPolicy` and `cwobject:ListAccessPolicy` granted to your user through an existing organization access policy. Add `cwobject:DeleteAccessPolicy` if you must delete the policy.
Exchange the ServiceAccount token and run the verification command	No CoreWeave IAM role applies to the federated ServiceAccount.	Grant `cwobject:CreateAccessKeyOIDC` and `s3:ListAllMyBuckets` to the WIF principal in an Object Storage organization access policy, with `resources: ["*"]`.

An Object Storage Admin must create the first organization access policy that delegates granular cwobject: permissions. The Object Storage Admin role governs the Object Storage control plane; it doesn’t grant S3 data access.

Install the Pod Identity Webhook

Install the Pod Identity Webhook to use Object Storage. The following steps install the webhook from CoreWeave Charts:

Set environment variables for your organization ID and Availability Zone:
- Replace [ORG-ID] with your organization’s ID. You can find your organization ID on the CoreWeave Console settings page.
- Replace [AVAILABILITY-ZONE] with an Availability Zone that supports Object Storage.
export ORG_ID=[ORG-ID] export REGION=[AVAILABILITY-ZONE]
Availability Zones that support AI Object Storage
- US-CENTRAL
- US-EAST
- US-WEST
- CA-EAST
- EU-NORTH
- EU-SOUTH
US-CENTRAL-05A

US-CENTRAL-06A

US-CENTRAL-07A

US-CENTRAL-08A

US-CENTRAL-08B

US-EAST-01A

US-EAST-02A

US-EAST-03A

US-EAST-04A

US-EAST-04B

US-EAST-06A

US-EAST-08A

US-EAST-13A

US-EAST-14A

US-EAST-15A

US-EAST-17A

RNO2A

US-WEST-01A

US-WEST-04A

US-WEST-09B

US-WEST-10A

CA-EAST-01A

EU-NORTH-05A

EU-SOUTH-03B

EU-SOUTH-04A
Learn more about Regions and Availability Zones.

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 \
  --namespace pod-identity-webhook \
  --create-namespace \
  --wait \
  --set config.orgID=$ORG_ID \
  --set config.region=$REGION

The output resembles the following:

"coreweave" has been added to your repositories
NAME: pod-identity-webhook
LAST DEPLOYED: Fri Mar 13 20:05:00 2026
NAMESPACE: pod-identity-webhook
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete

With the --wait flag, Helm waits until the release resources are ready. The Pod Identity Webhook can then inject credential configuration into annotated Pods.

Verify OIDC Workload Federation

Before the Pod Identity Webhook can obtain credentials, Object Storage must trust the OIDC tokens your CKS cluster issues. When you create a CKS cluster with OIDC Workload Identity enabled, CoreWeave registers this trust automatically. CoreWeave creates an OIDC configuration for the cluster with the audience https://coreweave.com/iam. This audience matches the default audience that the Pod Identity Webhook injects, so you don’t need to create another OIDC configuration.

In the Cloud Console, retrieve the OIDC Issuer URL for your CKS cluster:
- Go to the Clusters page.
- On the Clusters page, click the name of your cluster. A cluster details panel opens on the right.
- In the Cluster access section, copy the OIDC Issuer URL. You need this URL again when you configure access policies.
On the Workload Federation page, verify that the automatically created OIDC configuration for your cluster exists:
- On the Workload Federation page, find the row that corresponds to your cluster. The automatically created configuration’s description begins with “Auto-created OIDC workload federation config” and contains the cluster name. In the search field, enter the cluster name to filter for matching OIDC configurations.
- Confirm that its Issuer matches your cluster’s OIDC Issuer URL.
- Confirm that its Client ID (Audience) is https://coreweave.com/iam.

Configure OIDC workload identity federation manually

If the automatically created configuration is missing, create an OIDC workload identity federation (WIF) configuration manually:

In the Cloud Console, go to the Create OIDC Configuration page.
Enter the following values:
- Configuration name: A unique name for this configuration
- Issuer URL: Your cluster’s OIDC Issuer URL
- Client ID (Audience): https://coreweave.com/iam
On the Create OIDC Configuration page, click Create.

Configure OIDC workload identity federation with a custom audience

If a workload needs a custom audience, create an additional OIDC configuration. Set Issuer URL to your cluster’s OIDC Issuer URL. Set Client ID (Audience) to the custom audience. Then annotate the workload’s ServiceAccount with caios.coreweave.com/audience set to that same custom audience, as described in Use your ServiceAccount. To change the default audience for every workload that uses the webhook, set the chart’s config.audience value instead. See the Pod Identity Webhook chart values for details. With the OIDC configuration in place, Object Storage trusts tokens issued by your CKS cluster and can map them to access policies.

Use your ServiceAccount

The Pod Identity Webhook injects the configuration your Pods need to obtain Object Storage credentials. Add one of these annotations to the ServiceAccount that your workload uses:

Audience type	Annotation syntax
Default audience	`caios.coreweave.com/inject: "true"`
Custom audience	`caios.coreweave.com/audience: custom` (use when you need to match a specific WIF audience)

Create a ServiceAccount with the appropriate annotation, then run your workload with that ServiceAccount.

Create the following manifest and save it to a file named object-storage-sa.yaml. This example uses the default audience annotation. For a custom audience, adjust the annotation:
object-storage-sa.yaml
apiVersion: v1 kind: ServiceAccount metadata: name: my-object-storage-sa namespace: default annotations: caios.coreweave.com/inject: "true"
Apply the manifest to create the ServiceAccount:
kubectl apply -f object-storage-sa.yaml
Verify that the ServiceAccount exists and has the appropriate annotation:
kubectl get serviceaccounts my-object-storage-sa -o jsonpath='{.metadata.annotations.caios\.coreweave\.com/inject}' true
The true response confirms that the ServiceAccount has the default audience annotation.

Grant the ServiceAccount access to Object Storage

You must grant the ServiceAccount’s federated identity access to Object Storage through an organization access policy. To construct the WIF principal, use the OIDC Issuer URL you copied earlier and the ServiceAccount name: Replace [OIDC-ISSUER-URL] with the OIDC Issuer URL from your cluster’s details panel.

role/[OIDC-ISSUER-URL]:system:serviceaccount:default:my-object-storage-sa

The verification Pod requires only cwobject:CreateAccessKeyOIDC to exchange its OIDC token and s3:ListAllMyBuckets to run aws s3api list-buckets. Both are global actions and require resources: ["*"]. For a production workload, replace s3:ListAllMyBuckets with the specific S3 actions and bucket resources that the workload needs. The following example policy grants only the actions required by the verification Pod:

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

Create this policy using the Cloud Console, the CoreWeave Terraform Provider, or the Object Storage API. Before you deploy your workload, replace s3:ListAllMyBuckets with its required S3 actions and resources. For examples, see Organization access policy examples. After the policy is in place, it authorizes the ServiceAccount’s federated identity to call Object Storage.

Create a workload that uses the ServiceAccount

After you configure federation, the ServiceAccount, and an access policy, you can deploy a workload that obtains credentials through the webhook. This example creates a Pod that uses the ServiceAccount you created earlier.

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.
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.
Create the following manifest and save it to a file named object-storage-pod.yaml. Make the following adjustments:
- Replace [CONTAINER-IMAGE] with the container image that you want to use for your workload.
- Reference the same ServiceAccount in your Pod so the Pod Identity Webhook can inject credential configuration:
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.

Apply the manifest to create the workload:

kubectl apply -f object-storage-pod.yaml

Pods that use this ServiceAccount receive the necessary environment or volume configuration to call Object Storage.

Optional: Verify the webhook injection

Before you deploy your real workload, you can confirm that the Pod Identity Webhook injects credential configuration correctly. Create a test Pod that uses the amazon/aws-cli:2.33.2 image and run an S3 command against Object Storage.

Create the following manifest and save it to a file named test-webhook-pod.yaml. The test Pod uses the ServiceAccount and lists your buckets:

test-webhook-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-webhook
  namespace: default
spec:
  restartPolicy: Never
  serviceAccountName: my-object-storage-sa
  containers:
  - name: test
    image: amazon/aws-cli:2.33.2
    command:
    - sh
    - -c
    - |
        aws configure set s3.addressing_style virtual
        aws configure set endpoint_url http://cwlota.com
        aws s3api list-buckets

Apply the manifest:
kubectl apply -f test-webhook-pod.yaml
Check the Pod logs for the response:
kubectl logs test-webhook
When the webhook injection and your access policies are configured correctly, the logs contain a JSON response that lists your buckets. If you see an AccessDenied error, verify the organization policy. It must grant cwobject:CreateAccessKeyOIDC and s3:ListAllMyBuckets to the correct WIF principal with resources: ["*"].
Clean up the test Pod:
kubectl delete pod test-webhook

Next steps

To configure OIDC Workload Federation manually or for debugging, see Manual OIDC token exchange.
Learn more about Workload Identity Federation for Object Storage.

​Prerequisites

​Install the Pod Identity Webhook

​Verify OIDC Workload Federation

​Configure OIDC workload identity federation manually

​Configure OIDC workload identity federation with a custom audience

​Use your ServiceAccount

​Grant the ServiceAccount access to Object Storage

​Create a workload that uses the ServiceAccount

​Optional: Verify the webhook injection

​Next steps