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 implement basic network policies on CoreWeave Kubernetes Service (CKS) clusters to segment and secure Pod-to-Pod communication. By the end, you have a working default-deny network policy and a targeted allow rule, validated with test Pods. You’ll learn the rationale behind each step, CoreWeave-specific best practices, and how to validate your configuration. This tutorial is intended for platform engineers and cluster operators who need to enforce Pod-level network segmentation on CKS.

​
Prerequisites

  • CKS cluster: You need access to a CoreWeave Kubernetes Service (CKS) cluster. CKS runs on bare-metal nodes with hardware isolation (NVIDIA BlueField-3 DPU) and uses the Cilium CNI by default for high-performance, eBPF-powered policy enforcement.
  • kubectl access: Ensure kubectl is installed and configured for your cluster identity and namespace.

​
Create or use an existing namespace

Namespaces provide logical segmentation and isolation in Kubernetes. They are foundational for multi-tenancy and enforcing network policies scoped to individual teams or workloads. This step ensures your resources don’t interfere with others and that network policies apply only within your segment. Replace [NAMESPACE] in the following examples with a name relevant to your application. 
kubectl create ns [NAMESPACE]
With a namespace ready, the next step is to deploy the Pods that your network policies will govern.

​
Deploy sample Pods

Deploy two simple Pods:
  • backend: an NGINX server exposing port 80, labeled app: backend.
  • frontend: a BusyBox Pod running sleep, labeled app: frontend.
These two Pods let you demonstrate segmentation: by restricting which Pods can reach backend, you exercise least privilege for service access. 
kubectl apply -n [NAMESPACE] -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: backend
  labels:
    app: backend
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    app: frontend
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
EOF
After applying this manifest, both Pods should be running in your namespace. Now that you have workloads in place, you can define the network policies that control traffic between them.

​
Create a default deny policy for your namespace

By default, Pods in Kubernetes can communicate freely. In CoreWeave environments, this is mitigated by a defense-in-depth architecture (hardware isolation, Cilium default policies), but explicit Kubernetes network policies are still recommended for application-level segmentation. This policy blocks all ingress and egress traffic to Pods in the namespace unless specifically permitted: 
kubectl apply -n [NAMESPACE] -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF
This policy implements a “default deny” posture essential for microsegmentation and preventing lateral movement if a Pod is compromised. CoreWeave’s network architecture offloads kernel-level filtering to Cilium using eBPF. The DPU hardware enforces policies close to the network interface. With the default-deny policy applied, all Pod traffic in the namespace is now blocked. The next step is to selectively allow the specific traffic your application requires.

​
Create an allow policy for frontend to backend access

This policy allows only the frontend Pod to access the backend Pod on any port. No other Pod in the namespace, nor from outside, can reach backend. 
kubectl apply -n [NAMESPACE] -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
EOF
This policy targets the backend Pod and allows ingress traffic only from Pods labeled app: frontend within the same namespace. All other traffic remains denied, implementing the principle of least privilege where only specifically required connections are permitted. At this point, your namespace has both a default-deny policy and a targeted allow rule. The following section confirms that these policies are working as expected.

​
Validate your network policies

Validation is crucial to ensure your policies have the intended effect. Here’s how to test and confirm enforcement:
  1. Enter the frontend Pod and attempt to reach backend: 
    kubectl exec -n [NAMESPACE] frontend -- sh -c "wget -qO- http://backend:80"
    You should receive the NGINX welcome message.
  2. Deploy a third Pod to test isolation: 
    kubectl run other --rm -i -t -n [NAMESPACE] --image=busybox --restart=Never -- sh
    Inside this shell, run: 
    wget -qO- http://backend:80
    The connection should be refused or time out, demonstrating that only frontend has access.
  3. Confirm logs and network policy enforcement: Check that your network policies are active and being enforced: 
    # Verify network policies are created and active
kubectl get networkpolicy -n [NAMESPACE]

# Check detailed policy status
kubectl describe networkpolicy deny-all -n [NAMESPACE]
kubectl describe networkpolicy allow-frontend-to-backend -n [NAMESPACE]
    You should see both policies listed as active, with the correct Pod selectors and rules configured. To observe policy enforcement in action: 
    # Watch Cilium logs during your test connections
kubectl logs -n kube-system -l k8s-app=cilium --tail=50 -f
    When you run the connection tests from steps 1 and 2, you should see log entries showing allowed connections from frontend and dropped connections from unauthorized Pods.
With your network policies in place and validated, you’ve implemented microsegmentation that uses CoreWeave’s hardware-accelerated Cilium CNI for efficient policy enforcement at the DPU level. This provides application-layer security controls that complement the platform’s built-in hardware isolation, with observability available through Cilium’s metrics and logs. For deeper audit capabilities, CoreWeave supports tools like Cilium Tetragon for eBPF-based observability and Falco for runtime threat detection.
Last modified on March 24, 2026