Network Policies (Advanced)

By default, Kubernetes allows all pods to communicate with each other. This is flexible, but not always secure.

Network Policies allow you to explicitly define which workloads are allowed to talk to each other, and which are not.

This guide explains what Network Policies are, when you should use them, and how they fit into KubeRaya’s networking and security models.

What Network Policies Are (and Are Not)

What They Are

• Kubernetes-native rules for pod-to-pod traffic
• Applied at the network layer
• Used to control ingress and egress between workloads
• Scoped by namespace and pod labels

What They Are Not

• Not a replacement for:
  • Ingress
  • TLS
  • Authentication
• Not a firewall for the internet
• Not enabled automatically by default

Network Policies are about internal traffic control, not public exposure.

Why Network Policies Matter

Without Network Policies:

• Any pod can talk to any other pod
• Compromised workloads can move laterally
• Internal services are implicitly trusted

With Network Policies:

• Traffic is explicitly allowed
• Unintended communication is blocked
• Blast radius is reduced during incidents

Network Policies help you move from implicit trust to explicit intent.

When You Should Use Network Policies

Network Policies are especially valuable when:

• Running multiple services in one cluster
• Handling sensitive data
• Operating multi-tenant workloads
• Enforcing zero-trust principles
• Protecting internal APIs and databases

If your cluster hosts more than one workload, Network Policies are worth considering.

Basic Network Policy Concepts

Pod Selection

Policies apply to pods using labels.

Example:

podSelector:
  matchLabels:
    app: backend

This targets only pods labeled app=backend.

Ingress vs Egress

• Ingress – controls traffic into pods
• Egress – controls traffic out of pods

You can define one or both.

If a pod is selected by a Network Policy, traffic not explicitly allowed is denied.

Example: Allow Frontend to Talk to Backend

Scenario

• Frontend pods should access backend API
• Backend should not accept traffic from other pods

Conceptual Flow

frontend pods → backend pods ✅
other pods   → backend pods ❌

Example Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

This policy:

• Selects backend pods
• Allows ingress only from frontend pods
• Blocks all other inbound traffic

Example: Restrict Database Access

Databases are a common target for Network Policies.

Recommended Pattern

• Database pods accept traffic only from application pods
• No direct access from other services

Conceptually:

app pods → database pods ✅
other pods → database pods ❌

This reduces the risk of accidental or malicious access.

Network Policies and Namespaces

Network Policies are namespace-scoped.

This means:

• Policies apply only within their namespace
• Cross-namespace traffic must be explicitly allowed
• Namespaces alone do not isolate traffic

Namespaces + Network Policies provide stronger isolation together.

Important Considerations (CloudRaya Context)

Network Policy Support

• Network Policies rely on the cluster’s networking implementation
• Behavior follows Kubernetes standards
• Policies affect pod-level traffic, not VPC-level routing

What Network Policies Do Not Control

• Public access (handled by Services / Ingress)
• TLS encryption
• User authentication
• External firewall rules

Think of Network Policies as internal traffic rules, not perimeter security.

Common Network Policy Mistakes

• Creating policies without understanding default deny behavior
• Forgetting to allow DNS traffic
• Overly broad pod selectors
• Applying policies without testing

Network Policies should be introduced gradually and carefully.

Recommended Adoption Strategy

1. Start with critical workloads (databases, internal APIs)
2. Apply simple ingress-only policies first
3. Test communication paths
4. Expand to egress controls if needed
5. Document traffic intent clearly

Network Policies are powerful, precision matters.

How Network Policies Fit into Kubernetes Security

Network Policies complement:

• Ingress & TLS (public access)
• RBAC (who can do what)
• Pod security settings
• Application-level authentication

Together, they help build defense in depth.

Summary

• Network Policies control pod-to-pod traffic
• They enforce explicit communication paths
• They reduce lateral movement and blast radius
• They are an advanced but powerful security tool
• Best introduced incrementally and intentionally

Used correctly, Network Policies help ensure your Kubernetes workloads are secure by design, not secure by assumption.

Related Guides

📄 Networking in Kubernetes

📄 Expose Services in Kubernetes

📄 Kubernetes Security Basics

📄 Common Kubernetes Security Mistakes

📄 Kubernetes Best Practices