Skip to main content
In this lesson we examine Kubernetes NetworkPolicies in detail and show how to restrict a database Pod so it accepts traffic only from the API Pod on port 3306. Web and API Pods remain free to communicate, but the DB Pod must be locked down. Our objective:
  • Allow only the API Pod to initiate connections to the DB Pod on TCP port 3306.
  • Deny traffic from the Web Pod to the DB Pod.
  • Keep other Pods unaffected unless they match the DB Pod selector.
A network policies diagram showing three pods — Web Pod (blue), API Pod (green) and DB Pod (orange) — connected by dashed lines labeled with ports (80, 5000, 3306). The Web↔API and API↔DB links are white (allowed) while the Web↔DB link is red (denied).
Overview
  • Kubernetes networking is permissive by default: Pods can communicate with each other unless a NetworkPolicy selects a Pod and restricts traffic.
  • NetworkPolicies only take effect if your cluster CNI implements them (for example, Calico, Cilium, or Weave Net). If your CNI does not implement NetworkPolicy, the rules will not be enforced.
  • To secure the DB Pod we create a NetworkPolicy that selects the DB Pod (via labels) and declares which sources are permitted to send traffic to it.
  • Because the API Pod initiates the connection to the DB Pod, an Ingress policy applied to the DB Pod is sufficient. Replies are allowed automatically; a separate Egress rule is not required just for responses.
If a Pod is selected by any NetworkPolicy that defines ingress (or egress) rules, traffic in that direction is restricted to the policy’s allowed sources/destinations. If no NetworkPolicy selects a Pod, it remains unrestricted.
How the solution is built (step-by-step)
  1. Associate the policy with the DB Pod
    Use podSelector so the NetworkPolicy targets only the DB Pod(s). In this example the DB Pod has the label role: db.
  2. Choose the policy direction(s)
    Since the API Pod initiates DB requests, add Ingress to policyTypes. Add Egress only if the DB Pod must initiate outbound connections (e.g., pushing backups).
  3. Define allowed sources and ports
    Each ingress rule contains from (allowed sources) and ports (destination ports/protocols). from accepts:
    • podSelector — selects Pods by label (defaults to the same namespace)
    • namespaceSelector — selects Namespaces by label
    • ipBlock — allows specific IPs or CIDRs (useful for external systems)
Selector and match logic summary Important: multiple entries in a single from/to list are ORed. But within a single list item, specifying both podSelector and namespaceSelector requires both to match (logical AND). Small YAML placement changes can change the logic and the resulting security posture. Ingress-only example
  • DB Pods labeled role: db are allowed incoming TCP traffic on port 3306 only from:
    • API Pods labeled role: api in the prod namespace, OR
    • the external IP 192.168.5.10
Notes on selector logic
  • The first from item contains both podSelector and namespaceSelector: the source Pod must match role: api and be in the namespace labeled kubernetes.io/metadata.name: prod.
  • The second from item is an ipBlock: traffic from 192.168.5.10 is also allowed.
  • These two from list entries are alternatives (OR). Traffic matching either one is accepted.
Caution: if podSelector and namespaceSelector are placed as separate top-level list items, they are evaluated as independent OR entries — which may unintentionally permit broader access. Egress example (DB initiates outbound traffic) If a process on the DB Pod needs to push backups to an external server, add Egress to policyTypes and define egress rules. The to field supports the same selector types as from. Combined ingress + egress example
  • Allow API Pods to connect to DB on 3306/TCP.
  • Allow DB Pod to reach an external backup server at 192.168.5.10:80.
Testing and validation tips
  • Always test NetworkPolicies in a development or staging cluster before applying them in production.
  • Use simple kubectl run Pods to attempt connections (e.g., nc, telnet, or mysql clients) from Web, API, and external test Pods to validate allowed and denied flows.
  • If a policy appears to have no effect, confirm your CNI supports NetworkPolicy and that the policy selects the intended Pods (labels and namespaces must match).
Quick checklist before applying
  • Ensure DB Pods have the correct label (e.g., role: db).
  • Confirm API Pods have the expected label and are in the intended namespace.
  • Verify CNI/plugin supports NetworkPolicy (Calico, Cilium, Weave Net, etc.).
  • Review YAML indentation and placement of selectors to avoid accidental OR/AND mistakes.
Links and references Summary
  • Attach NetworkPolicies to Pods using podSelector.
  • Choose Ingress when the Pod receives connections, Egress when it initiates them.
  • Use podSelector, namespaceSelector, and ipBlock to precisely allow traffic.
  • Within one from/to list item, multiple selectors are ANDed; separate list items are ORed.
  • Test policies carefully to avoid unintended exposure or blocks.

Watch Video

Practice Lab