Phase 2 adds Node Pools and DFS volumes on top of the VPC and CKS cluster from Phase 1. These resources are Kubernetes manifests that require a running cluster and kubeconfig. This guide also covers the following optional configurations: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.
- Object Storage
- OIDC Workload Identity Federation for Object Storage (instead of static CoreWeave API keys)
Prerequisites
- A CoreWeave account with a CoreWeave API token (create one in Console).
kubectl(required for Node Pools and DFS volumes and optional for Object Storage).- The kubeconfig you downloaded at the end of Phase 1.
Node Pools and DFS volumes
Node pools and DFS PVCs are managed as Kubernetes manifests, so Terraform needs the kubeconfig you downloaded at the end of Phase 1.Your CoreWeave user or API token must have the CKS Admin IAM role. See the prerequisites.
Configuration
In this section, you’ll set the kubeconfig path and enable Node Pools and DFS volumes.Set the kubeconfig path
Interraform.tfvars, set the path to the kubeconfig you downloaded at the end of Phase 1:
Enable node pools and DFS
To enable Node Pools and DFS volumes, set the following variables in yourterraform.tfvars file:
Create and verify your Node Pools and DFS volumes
In this section, you’ll apply your Terraform configuration to create your Node Pools and DFS volumes.Apply your Terraform configuration
Run the following commands to plan your changes and apply your changes to enable Node Pools and DFS volumes:Verify outputs
Afterterraform apply completes, verify the outputs to ensure your Node Pools and DFS volumes were created successfully:
Add Object Storage (optional)
The Object Storage module is an optional add-on that creates an AI Object Storage bucket with organization-level and optional bucket-level access policies. Object Storage resources do not require kubeconfig and can be included in either Phase 1 or Phase 2.Your user or API token must have the Object Storage Admin IAM role. See the prerequisites.
Configure object storage access policies
In this section, you’ll configure the object storage access policies for your Object Storage bucket. You need at least one organization access policy before creating buckets; bucket access policies are optional. The following policies are available in yourterraform.tfvars file (copied from the terraform.tfvars.example file) as examples; edit them to suit your needs.
Organization access policies
Theobject_storage_org_access_policies variable is a map (key = policy name), so you can create multiple policies for different concerns. At least one organization access policy must exist before creating buckets.
Open access (single policy)
A single policy granting full S3 and Object Storage API access to every principal in the organization. Suitable for dev/test environments or single-team setups where all users share the same level of access:Scoped access (multiple policies)
Separate policies for different access patterns with named principals, least-privilege actions, independently manageable and auditable:Bucket access policies (optional)
Bucket access policies add fine-grained, S3-compatible access control for a single bucket. They are evaluated after organization access policies. Managed with theobject_storage_bucket_policy_statements variable.
Create a bucket
-
Set the bucket variables in
terraform.tfvars:Bucket naming rules
Bucket names must be globally unique, and adhere to the following rules:- Length: 3 to 63 characters.
- Characters: Only lowercase letters (
a-z), numbers (0-9), and hyphens (-). No dots, uppercase letters, underscores, spaces, or other special characters. - Start and end: Must begin and end with a letter or number. Cannot start or end with a hyphen (
-). - Prohibited patterns: Cannot start with
xn--.- Reserved: Must not begin withcw-,vip-, orlog-stitcher-ch-. Must not be the exact nameint. These are reserved for internal use.
-
Run the following commands to plan your changes and apply your changes to create your Object Storage bucket:
-
After
terraform applycompletes, verify the outputs to ensure your Object Storage bucket was created successfully:
OIDC Workload Identity Federation for Object Storage
For production environments, OIDC Workload Identity Federation (WIF) eliminates static API keys by exchanging short-lived JWT tokens from your identity provider for temporary Object Storage credentials. CKS clusters expose an OIDC issuer URL for Kubernetes service account tokens. After Phase 1 completes, retrieve this URL from the Terraform output:Creating a WIF configuration requires the IAM Admin role. There is no Terraform resource for WIF configurations today; create them in Console > Organization > IAM > Workload Federation.
Migrating from an older repository layout
If you previously hadobject_storage.tf, nodepool.tf, or dfs.tf at the root level and are updating to the module layout, Terraform will plan to destroy and recreate those resources unless you move state. Run the following commands once after pulling the new layout:
terraform plan to confirm no changes for those resources.