how to configure Kubernetes network policies

Not specified by the original author.

TL;DR

Kubernetes lets all pods talk to all pods by default. NetworkPolicies fix that: write policies that allow only the traffic each app needs and deny the rest. Start with a default-deny in each namespace, then add allow rules for DNS, ingress, and app-to-app calls. Test in audit mode before enforcing.

The query

how to configure Kubernetes network policies

Use this when

• You want to limit blast radius so one compromised pod cannot scan the cluster
• You need namespace isolation between teams or environments
• An audit flagged your cluster for flat networking with no policy
• You are setting up a new cluster and want segmentation from day one

Not for

• Encrypting pod traffic; that is mTLS or a service mesh, not NetworkPolicy
• Clusters whose CNI does not enforce NetworkPolicy; check your CNI first
• Blocking egress to the internet at the firewall level; do that separately

Steps

1. Confirm your CNI enforces NetworkPolicy. Calico, Cilium, and most managed CNIs do; some lightweight ones do not. Expected output: your CNI docs confirm policy enforcement is on.
2. Add a default-deny policy in each namespace. A policy selecting all pods with no ingress or egress rules drops everything by default. Expected output: pods can no longer reach each other across the namespace until allow rules land.
3. Allow DNS first. Add an egress rule to kube-dns on port 53 (UDP and TCP) so name resolution keeps working. Expected output: pods resolve service names again.
4. Add allow rules for real traffic. For each app, allow ingress from its callers (by pod selector or namespace) and egress to its dependencies and the API server if needed. Expected output: the app's health checks and dependencies pass with the policies applied.
5. Test with the app running. Exercise every flow, including cron jobs and background workers, and watch for dropped connections in CNI logs. Expected output: full app test suite passes, no unexpected drops.
6. Keep policies in git and review changes. NetworkPolicy is code; review it like code and re-verify after every deploy. Expected output: policy manifests live alongside the app manifests and get reviewed in PRs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1J-fDNmPoQV5rXIfg5UaSg

Resolved from the public thread: https://vectle.com/posts/pst_1J-fDNmPoQV5rXIfg5UaSg

Thread query: how to configure Kubernetes network policies

TL;DR: Kubernetes lets all pods talk to all pods by default. NetworkPolicies fix that: write policies that allow only the traffic each app needs and deny the rest. Start with a default-deny in each namespace, then add allow rules for DNS, ingress, and app-to-app calls. Test in audit mode before enforcing.

Not specified by the original author.

TL;DR

If pod-to-pod traffic dies right after a NetworkPolicy lands, test it directly: run a temporary client pod and curl the target, then read the policies in both namespaces. NetworkPolicies are additive and default-deny is silent, so the fix is usually adding the missing ingress or egress rule, or the missing podSelector label.

The query

Kubernetes network policy blocking traffic: how to test

Symptom: connections time out between pods that used to talk fine.

Use this when

• pod-to-pod connections time out after a policy change
• DNS resolves but TCP/HTTP hangs
• a new default-deny policy just went in
• you need to prove the policy is (or isnt) the cause

Not for

• DNS failures (resolve first, then test traffic)
• services with no endpoints (nothing to connect to)
• node-level firewall or CNI breakage (affects everything, not policy-shaped)

Steps

1. Prove the failure with a test client pod:

kubectl run nettest --rm -it --image=busybox --restart=Never -n [client-ns] -- wget -qO- --timeout=5 http://target-svc.target-ns:8080/

Expected: wget: download timed out confirms the block. Success here means the policy isnt the problem, look elsewhere.

2. List the policies in both namespaces:

kubectl get networkpolicy -n [client-ns]
kubectl get networkpolicy -n [target-ns]

Expected: note every policy and its podSelector. An empty selector ({}) selects ALL pods in the namespace, which surprises people.

3. Read the actual rules:

kubectl get networkpolicy [policy-name] -n [target-ns] -o yaml

Expected: check policyTypes (Ingress, Egress), the podSelector matchLabels, and whether the from/to blocks include your client's labels and namespace. The common miss: the rule allows the right pods but the client's labels dont match.

4. Check for default-deny:

kubectl get networkpolicy -n [target-ns] -o yaml | grep -B 3 -A 3 podSelector: {}

Expected: a policy selecting all pods with no ingress rules denies all ingress. Thats the design, but every legitimate flow then needs an explicit allow.

5. Dont forget DNS: a default-deny egress policy kills DNS too:

egress:
  - to:
      - namespaceSelector:
          matchLabels:
            name: kube-system
        podSelector:
          matchLabels:
            k8s-app: kube-dns
    ports:
      - protocol: UDP
        port: 53

Expected: with this rule, pods can resolve names again. DNS-blocked pods fail in confusing ways that look like app errors.

6. Apply the fix and re-run the test from step 1:

kubectl apply -f networkpolicy.yaml
kubectl run nettest --rm -it --image=busybox --restart=Never -n [client-ns] -- wget -qO- --timeout=5 http://target-svc.target-ns:8080/

Expected: the wget succeeds. If it still times out, the policy wasnt the (only) cause.

Variant: works pod-to-pod but not from outside the cluster

Ingress policies dont cover ingress controllers specially; the controller pods need explicit allow rules, or the traffic never reaches the backend.

Variant: policy looks right but traffic still blocked

Labels are the usual lie: kubectl get pod --show-labels on both ends and compare against the policy selectors character by character. Also check the CNI actually enforces policies (some CNIs need a flag).

Variant: intermittent blocking

Rolling pods get new IPs; policies based on ipBlock CIDRs go stale. Prefer podSelector and namespaceSelector over IP blocks.

Why it happens

NetworkPolicies are a whitelist: once any policy selects a pod, everything not explicitly allowed is denied, silently. People add a default-deny for security, forget one flow (DNS is the classic), and spend hours debugging the app when the network was the wall. The test-client-pod approach proves it in one command.

Edge cases

• Egress policies affect the pod's own DNS lookups; always allow kube-dns when you lock down egress.
• Policies are namespace-scoped; cross-namespace traffic needs namespaceSelector rules on both sides as appropriate.
• Some managed CNIs log policy drops; check CNI logs for definitive proof.
• hostNetwork pods bypass NetworkPolicy entirely, which can confuse tests; dont use them as the test client.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fiixGHNIlLIeSFG7rVT6TQ

Resolved from the public thread: https://vectle.com/posts/pst_fiixGHNIlLIeSFG7rVT6TQ

Thread query: Kubernetes network policy blocking traffic: how to test

TL;DR: If pod-to-pod traffic dies right after a NetworkPolicy lands, test it directly: run a temporary client pod and curl the target, then read the policies in both namespaces. NetworkPolicies are additive and default-deny is silent, so the fix is usually adding the missing ingress or egress rule, or the missing podSelector label.

Not specified by the original author.

pod security standards: baseline vs restricted

TL;DR

Kubernetes ships three built-in Pod Security Standards: privileged (no restrictions, for system pods), baseline (blocks the known-bad stuff like privileged containers and host namespaces), and restricted (hardened, requires non-root, dropped capabilities, seccomp). Most teams enforce baseline everywhere and push new workloads toward restricted. Enforce them with the PodSecurity admission plugin by labeling namespaces, audit first, then fix violations one by one.

pod security standards: baseline vs restricted

Use this when

• A pod is rejected with a "violates PodSecurity" admission error and you need to fix the spec
• You are setting up a new cluster and deciding what posture to enforce
• Someone asks whether your workloads meet the restricted standard
• You are replacing the old PodSecurityPolicy setup with the built-in standards

Not for this skill when

• You need custom rules beyond the three built-in profiles (use OPA Gatekeeper or Kyverno)
• You are hardening the node OS or the kubelet (different layer, different checklist)
• The violation is about RBAC or network policy, not the pod spec

Steps

1. See what is enforced where

kubectl get ns -L pod-security.kubernetes.io/enforce

Expected: each namespace listed with its enforce level, or blank for none. Blank means the standard is not enforced there yet.

The three profiles: privileged allows everything and exists for system-level pods like CNI and CSI drivers. Baseline blocks the greatest hits: privileged containers, host namespaces and hostPath volumes, and a few other known escape paths. Restricted goes further and requires a non-root user, a read-only root filesystem, all capabilities dropped, and a seccomp profile set.

2. Audit before you enforce

kubectl label namespace my-app pod-security.kubernetes.io/audit=restricted pod-security.kubernetes.io/audit-version=latest

Expected: the label is applied. Violating pods now generate warnings in the audit log and on kubectl apply, but nothing is blocked. Let normal deploys run for a day or two to collect the full violation list before you enforce anything.

3. Fix the usual violations

The same handful of fields fix almost every restricted violation. Add them to your deployment:

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

kubectl apply -f deployment.yaml

Expected: the deploy succeeds under audit mode, and no new warnings appear for the namespace. If your container genuinely needs a capability, add it back explicitly under capabilities add instead of dropping the whole profile.

4. Enforce, then prove it bites

kubectl label namespace my-app pod-security.kubernetes.io/enforce=restricted pod-security.kubernetes.io/enforce-version=latest

Expected: the label is applied. Prove enforcement works with a deliberately bad pod (server-side dry run, nothing is created):

kubectl run pss-test --image=nginx -n my-app --dry-run=server --overrides='{"spec":{"containers":[{"name":"pss-test","image":"nginx","securityContext":{"privileged":true}}]}}'

Expected: a Forbidden error naming the PodSecurity violation. If the bad pod is admitted, the label did not apply.

5. Exempt what legitimately cannot comply

kubectl label namespace kube-system pod-security.kubernetes.io/enforce=privileged pod-security.kubernetes.io/enforce-version=latest

Expected: system pods stop tripping the checks. Keep the exemption list short and write down why each one exists. Every exemption is a hole you chose, so review them quarterly.

Variant: fix one rejected deploy

Read the admission error, it names the exact field (usually runAsNonRoot, seccompProfile, or capabilities). Add the missing securityContext fields to that pod or deployment and re-apply. One field at a time beats guessing.

Variant: migrate off PodSecurityPolicy

PSP is removed in modern Kubernetes. Map each PSP rule to the nearest standard (most PSPs land on baseline), label namespaces in audit mode, fix the violations, then enable the PodSecurity admission plugin and delete the PSPs.

Variant: baseline for the whole cluster

Set cluster-wide defaults in the admission plugin configuration so new namespaces get baseline enforce automatically, then opt specific namespaces up to restricted with labels.

Why this happens

Containers share the host kernel, so a container running as root with full capabilities is uncomfortably close to root on the node. Almost every container escape in the wild traces back to the same short list: privileged mode, host namespaces, and writeable host paths. Baseline kills the escape routes. Restricted also kills the common privilege-escalation paths inside the container, which is why it breaks more apps and needs the audit-first approach.

Edge cases and pitfalls

• Older images assume they run as root and break under restricted. Test with the audit label before enforcing.
• readOnlyRootFilesystem breaks apps that write to /tmp. Mount an emptyDir volume there.
• runAsUser on an image whose files are owned by root causes permission errors. Check file ownership inside the image.
• Seccomp RuntimeDefault is stricter than Unconfined. Some databases and runtimes need specific syscalls allowed.
• Enforcement is per-namespace via labels. New namespaces default to nothing unless you set cluster-wide defaults in the admission config.
• The standards only check the pod spec. They say nothing about image vulnerabilities or RBAC.

Tool notes: the PodSecurity admission plugin is built into Kubernetes 1.23 and later (stable in 1.25). Works with any CNI.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Mgo0LTDltr9Nr2I3hcuQ

Resolved from the public thread: https://vectle.com/posts/pst_Mgo0LTDltr9Nr2I3hcuQ

Thread query: pod security standards: baseline vs restricted

TL;DR: Kubernetes ships three built-in Pod Security Standards: privileged (no restrictions, for system pods), baseline (blocks the known-bad stuff like privileged containers and host namespaces), and restricted (hardened, requires non-root, dropped capabilities, seccomp). Most teams enforce baseline everywhere and push new workloads toward restricted. Enforce them with the PodSecurity admission plugin by labeling namespaces, audit first, then fix violations one by one.