# Kubernetes Networking Policies

Kubernetes Networking Policies are like the traffic rules of your Kubernetes cluster. They let you control who can talk to whom and how they communicate within your cluster. Think of them as security checkpoints, ensuring that only the right pods and services can exchange information.

## **Why Networking Policies Matter**

Imagine running a busy office building. You wouldn’t want just anyone wandering into sensitive meeting rooms or accessing confidential files, right? Similarly, in Kubernetes, not all pods need—or should—talk to each other. Networking Policies help you set these boundaries, ensuring that your cluster is both secure and efficient.

## How They Work

By default, Kubernetes is like an open highway—any pod can talk to any other pod. While this might be fine for small setups, it’s risky for production environments. Networking Policies allow you to flip the default behavior by explicitly defining rules for pod communication.

Here’s how they work:

1. **Selectors**: Choose which pods the policy applies to using labels.
2. **Ingress Rules**: Define what can _enter_ the [pod](/content/finops-glossary/kubernetes-pods/index.html).
3. **Egress Rules**: Specify what the pod can _send out_.

You define these rules in YAML manifests, and Kubernetes enforces them.

**How to Set Up Kubernetes Network Policies**

Now that you know what Networking Policies are, let’s walk through setting them up step by step.

## **1. Start with the Basics**

To begin, ensure your Kubernetes cluster is using a **[CNI plugin](/content/finops-glossary/cni-container-network-interface/index.html)** that supports Network Policies, such as Calico, Cilium, or Weave Net. Without a compatible plugin, these policies won’t have any effect.

## **2. Define a Default Deny Policy**

The best way to secure your cluster is by blocking all traffic by default and then selectively allowing only the traffic you need.

### YAML Example: Default Deny Policy

This policy blocks all [ingress](/content/finops-glossary/kubernetes-ingress-controllers/index.html) and egress traffic in a namespace:

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: my-namespace
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
```

Apply it with:

```yaml
kubectl apply -f default-deny.yaml
```

## **3. Add Specific Policies**

Once the default deny policy is in place, you can create specific policies to allow necessary communication.

### Example 1: Allow Frontend to Access Backend

Imagine your frontend pods need to talk to backend pods on port 8080.

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
```

#### Example 2: Allow DNS Access for All Pods

To enable DNS resolution, you’ll need to allow traffic to the `kube-dns` service.

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: my-namespace
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53
```

## **Challenges and Gotchas**

While Networking Policies are powerful, they can get tricky:

- **CNI Dependency**: Ensure your plugin supports Network Policies.
- **Complex Configurations**: Large setups with many microservices require careful planning to avoid unintended communication blocks.
- **Default Deny Policy**: Always start with a default deny policy to ensure no unintended access.

## **Test Your Policies**

Once policies are applied, test them to ensure they work as intended:

Use `kubectl exec` to run commands from one pod to another. Example:

```yaml
kubectl exec -it <pod-name> -- curl <target-service>
```

Tools like [Calico’s Policy Editor](https://docs.tigera.io/calico/latest/network-policy/get-started/calico-policy/calico-network-policy) or [NetworkPolicy Editor](https://editor.networkpolicy.io/) can simulate policies before applying them.

## **Key Benefits**

- **Improved Security**: Reduce attack surfaces by limiting pod communication.
- **Fine-grained Control**: Precisely manage traffic flow in your cluster.
- **Regulatory Compliance**: Meet strict data flow requirements.

## **Resources for Learning More**

1. **Official Kubernetes Documentation**:
   - [Kubernetes Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
2. **Cilium Network Policies**:
   - [Cilium Documentation](https://docs.cilium.io/en/stable/index.html)
3. **Weave Net**:
   - [Weaveworks Documentation](https://github.com/weaveworks/wkp-docs)