Understanding Kubernetes NetworkPolicies for Security

techhadoop kubernetes, OCP

In Kubernetes and OpenShift, a NetworkPolicy is a declarative firewall rule that dictates how groups of pods are allowed to communicate with each other and with external network endpoints.

By default, Kubernetes networking operates on a flat, open network topology. This means any pod in any namespace can freely talk to any other pod in the cluster without any authentication or restriction. While this makes initial application development easy, it is a massive security risk in production.

NetworkPolicies allow you to implement a Zero-Trust network architecture by constraining traffic using label selectors.

1. How NetworkPolicies Work (The Mechanics)

NetworkPolicies are stateful Layer-3 and Layer-4 packet filters. When you define a rule allowing a frontend pod to talk to a backend pod, the underlying CNI plug-in (like Calico, Cilium, or OVNKubernetes) automatically permits the return traffic for that connection without needing an explicit reverse rule.

NetworkPolicies are scoped by Namespaces and track traffic using two primary vectors:

  • Ingress (Incoming Traffic): Dictates who is allowed to send packets into the targeted pods.
  • Egress (Outgoing Traffic): Dictates where the targeted pods are allowed to send packets out to.

2. Default-Deny: The Foundation of Zero-Trust

Before writing granular rules for individual applications, security best practices dictate that you lock down the namespace entirely. If you don’t establish a baseline block, any pod without an explicit policy remains wide open.

Applying a Default Deny All policy changes the namespace’s behavior from “allow everything” to “isolate everything.” Once this is applied, pods inside this namespace become completely isolated, and packets are dropped unless an explicit whitelist policy is created.

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: finance-prod # The target namespace being locked down
spec:
  podSelector: {} # An empty selector matches EVERY pod in this namespace
  policyTypes:
    - Ingress
    - Egress

3. Designing a Whitelist Policy (The Blueprint)

Once the namespace is isolated, you selectively punch holes through the firewall to allow legitimate application traffic.

The production-ready blueprint below demonstrates how to configure a multi-layered security rule. It ensures that pods carrying the label app: oracle-database will only accept incoming traffic over a specific port if it originates from an authorized frontend pod or a specific corporate network block:

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-security-gate
  namespace: finance-prod
spec:
  # 1. Target: What pods does this firewall rule apply to?
  podSelector:
    matchLabels:
      role: database
      app: oracle-database
  policyTypes:
    - Ingress
  # 2. Rules: What incoming traffic is allowed through the gate?
  ingress:
    - from:
        # Source Matrix A: Match pods inside the SAME namespace based on labels
        - podSelector:
            matchLabels:
              role: api-frontend
        
        # Source Matrix B: Match pods from a DIFFERENT namespace (requires matching namespace labels)
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: analytics-reporting
          podSelector:
            matchLabels:
              job: batch-reporting
        # Source Matrix C: Match external corporate bare-metal networks outside the cluster
        - ipBlock:
            cidr: 192.168.42.0/24
            except:
              - 192.168.42.15/32 # Explicitly block a rogue staging server IP
      # 3. Ports: Restrict traffic strictly to the application layer port
      ports:
        - protocol: TCP
          port: 1521 # Oracle SQL Listener standard port

4. Crucial Pitfalls to Avoid in Interviews & Production

The podSelector vs namespaceSelector Bracket Trap

When writing individual elements under the from: block, the nesting layout determines whether the rule applies as an AND or an OR condition:

– OR Condition (Separate List Items):YAML

This allows traffic from any pod in a namespace labeled team: alpha

OR any pod labeled app: frontend within the local namespace.

– AND Condition (Combined Single Item):

from: 
- namespaceSelector: 
    matchLabels: { team: alpha } 
-podSelector:
   matchLabels: { app: frontend }

This strictly allows traffic ONLY from pods labeled app: frontend that reside inside a namespace labeled team: alpha.

The CNI Enforcement Blindspot

Kubernetes NetworkPolicies are merely abstractions. The core kube-apiserver will accept your NetworkPolicy YAML files regardless of your cluster setup. However, if your cluster utilizes a basic CNI plugin that lacks security enforcement capabilities (such as Flannel), the rules will be completely ignored, and traffic will remain wide open. You must ensure your cluster runs a security-capable CNI like OVNKubernetes, Calico, or Cilium for these firewalls to take physical effect in the kernel layer.

Leave a Reply