> ## 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.

# Deploy network policies with CKS

> Enforce Pod-level network segmentation on CKS clusters.

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.

```bash theme={"system"}
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.

```bash theme={"system"}
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:

```bash theme={"system"}
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`.

```bash theme={"system"}
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`:

   ```bash theme={"system"}
   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:

   ```bash theme={"system"}
   kubectl run other --rm -i -t -n [NAMESPACE] --image=busybox --restart=Never -- sh
   ```

   Inside this shell, run:

   ```bash theme={"system"}
   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:

   ```bash theme={"system"}
   # 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:

   ```bash theme={"system"}
   # 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](/security/tutorials/ebpf-observability) and Falco for runtime threat detection.