Kubernetes L4/L7 Security: A Guide to Combining Service Mesh and NetworkPolicy

Service Mesh and NetworkPolicy: A Practical Guide to Combining L4 and L7 Security

As microservices architecture (MSA) has become the mainstream, application complexity has grown exponentially. In an environment where dozens of services talk to each other, controlling who communicates, over which path, and under what conditions is no longer just network management—it is a matter of survival.

We usually think of firewalls when we think about security. In Kubernetes, though, security can never be complete with a single firewall. There are two powerful mechanisms with different roles: NetworkPolicy and Service Mesh.

This article clearly explains how these two technologies work (L4 vs L7) and, from a practitioner’s perspective, dives into how to combine them without conflict to build the strongest possible security architecture.

Network-Level Firewall: The Role of NetworkPolicy (Layer 4)

NetworkPolicy is a Kubernetes-native feature that handles the most basic network access control. It is similar to traditional firewall rules.

How it works: NetworkPolicy allows or blocks traffic based on IP addresses and port numbers. You define rules such as “this Pod is only allowed TCP communication on port 8080.” This layer never inspects the application payload.

When to use it:

• When a specific service must be blocked at the source from reaching the external internet or a particular port in another namespace.
• When you want to enforce the principle of least privilege at the lowest level by allowing only the minimum required network connections.

💡 Hands-on example: Restricting access to port 8080 (L4)

If you want backend-service to be reachable only from the internal auth-service on port 8080, use a NetworkPolicy.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-backend-access
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend-service
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
 app: auth-service #
    ports:
    - protocol: TCP
 port: 8080 # 8080

Application-Level Traffic Control: The Power of Service Mesh (Layer 7)

A service mesh provides an infrastructure layer for service-to-service communication. Typical implementations include Istio and Linkerd, which use the sidecar pattern to deploy a proxy container (e.g., Envoy) next to each Pod.

The magic of the sidecar pattern: The sidecar proxy intercepts all inbound and outbound traffic. When it inspects traffic, it does not look only at ports; it can enforce controls based on application-level information such as HTTP headers, HTTP methods, and request paths. That is the essence of L7 control.

When to use it:

• “Allow only GET requests and reject all POST requests.”
• “Process only requests that include a specific header (X-Client-ID).”
• When you want to automatically apply authentication (mTLS) for service-to-service communication.

💡 Hands-on example: Restricting HTTP methods (L7)

If you want incoming requests to the user-api service to allow only the GET method, use a Service Mesh AuthorizationPolicy.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: restrict-get-method
  namespace: default
spec:
  selector:
    matchLabels:
      app: user-api
  action: ALLOW
  rules:
  - http:
 method: GET # GET
      paths: ["/users"]

L4 vs L7: Which Is Stronger, and How Should You Combine Them?

This is the most important question. The answer to “Which one is stronger?” is: “You need both; they play different roles.”

🛡️ Optimal Combination Strategy for Defense in Depth

The goal of a security architecture is to achieve defense in depth. That means not relying on a single security control, but building multiple layers of defense.

1. Outermost defense line (L4 – NetworkPolicy):

   • Goal: Block incoming traffic from outside, or access to completely wrong ports, at the source.
   • Example: “This service will only open port 8080; port 22 is blocked.”

2. Internal communication control (L7):

   • Example: “Even if traffic arrived on port 8080, reject the request if it is POST /api/v1/admin.”

Conclusion: The safest approach is to use L4 for basic access control and L7 for business-logic-level access control.

🚀 Summary and Practical Application Guide

With this multi-layered defense-in-depth strategy, even if one layer is breached, the next layer’s controls still protect you—resulting in a much stronger system.

Verifying Policies After Applying Them

After applying NetworkPolicy and mesh authorization policies, confirm they actually block traffic.

# attempt access from a disallowed pod (should be blocked)
kubectl run probe --rm -it --image=busybox -n other -- wget -qO- -T 3 http://api.prod:8080
# check Istio authorization denials
kubectl logs deploy/api -n prod -c istio-proxy | grep "rbac_access_denied"

If the CNI doesn't support NetworkPolicy, policies are silently ignored, so always run a blocking test at least once.