Network Policies#

This page explains Kubernetes NetworkPolicies and how they could be applied to this cluster. NetworkPolicies are not deployed by default because the maintenance overhead outweighs the benefit for a single-admin homelab.

What are NetworkPolicies?#

NetworkPolicies are Kubernetes resources that control pod-to-pod and pod-to-external network traffic. Without any policies, all pods can communicate freely (Kubernetes default). Adding a policy restricts traffic to only what is explicitly allowed.

Default-deny pattern#

The standard approach is:

  1. Apply a default-deny policy to each namespace (blocks all ingress).

  2. Add explicit allow rules for legitimate traffic flows.

Example default-deny policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: monitoring
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Example allow rule (let ingress-nginx reach Grafana):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-to-grafana
  namespace: monitoring
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: grafana
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - port: 3000

Traffic flows in this cluster#

If you wanted to implement NetworkPolicies, the key traffic flows to allow would be:

From

To

Port

Purpose

ingress-nginx

all service namespaces

service ports

External access

monitoring (Prometheus)

all namespaces

metrics ports

Scraping

open-webui

rkllama

8080

LLM API

open-webui

llamacpp

8080

LLM API

cert-manager

external

443

ACME DNS-01

cloudflared

ingress-nginx

80/443

Tunnel traffic

argo-cd

all namespaces

various

GitOps sync

When to add NetworkPolicies#

Consider deploying NetworkPolicies if:

  • The cluster becomes multi-tenant (multiple users or teams).

  • Services are exposed to the public internet without Cloudflare.

  • You need to meet a compliance requirement (e.g. PCI-DSS, SOC2).

  • A workload runs untrusted code (e.g. user-submitted jobs).

For a single-admin homelab behind Cloudflare, the security benefit is marginal and the operational overhead (debugging blocked connections, maintaining rules as services change) is significant.

CNI requirements#

K3s ships with Flannel as the default CNI. Flannel supports NetworkPolicy enforcement via the kube-router backend. If you need NetworkPolicies, you may need to switch to Calico or Cilium. Check the K3s documentation for CNI configuration options.