Which technology can be used to apply security policy for internal cluster traffic at the application layer of the network?

A service mesh is a dedicated infrastructure layer designed to manage service-to-service communication within a microservices architecture. It operates at the application layer (Layer 7) by injecting sidecar proxies (e.g., Envoy) into each application pod. These proxies intercept all network traffic, enabling the enforcement of fine-grained security policies for internal (east-west) cluster traffic. This includes features like mutual TLS (mTLS) for identity and encryption, and authorization policies based on application-level attributes such as HTTP methods, headers, or gRPC service names, which is not possible with standard Kubernetes resources.

A. Network Policy: This is a native Kubernetes resource that operates at the network and transport layers (L3/L4), controlling traffic based on IP addresses and ports, not application-layer data.
B. Ingress Controller: This component manages external traffic entering the cluster (north-south), routing it to internal services. It does not manage or apply policy to internal service-to-service communication.
C. Container Runtime: This software (e.g., containerd) is responsible for running containers. It handles container lifecycle and host-level isolation, not network policy enforcement between services.

1. Istio Documentation

"Authorization Policy": The official documentation for Istio

a prominent service mesh

explicitly shows how to create authorization policies that operate at Layer 7. For example

rules can specify allowed HTTP methods (e.g.

"GET") or paths (e.g.

"/api/v1"). This demonstrates the application-layer capabilities for internal traffic.

Source: Istio Authors

Authorization Policy

Istio Documentation

istio.io/latest/docs/reference/config/security/authorization-policy/. Accessed October 2023.

2. Kubernetes Documentation

"Network Policies": The official Kubernetes documentation states that Network Policies use pod selectors

IP blocks

and port numbers to control traffic flow. This confirms their operation at Layers 3 and 4 of the OSI model

not the application layer.

Source: The Kubernetes Authors

Network Policies

Kubernetes Documentation

kubernetes.io/docs/concepts/services-networking/network-policies/. Accessed October 2023.

3. Gao

Y.

et al. (2021). "A Survey on Service Mesh: Architecture

State-of-the-art

and Challenges." This peer-reviewed academic paper describes the core architecture of a service mesh

highlighting its data plane (sidecar proxies) which "can parse application-layer protocols (e.g.

HTTP

gRPC)" to provide advanced security and traffic management.

Source: IEEE Access

vol. 9

pp. 34035-34053

2021

DOI: 10.1109/ACCESS.2021.3059977. (Section III-B

"Security").

4. Linkerd Documentation

"Authorizing Incoming Requests": The documentation for Linkerd

another CNCF service mesh

details its server-side authorization policies. These policies can match on application-layer criteria like the path of an HTTP request

demonstrating L7 policy enforcement for internal cluster traffic.

Source: Linkerd Authors

Authorizing Incoming Requests

Linkerd Documentation

linkerd.io/2.14/features/server-policy/. Accessed October 2023.