Zero Trust Networking in Kubernetes with Gateway API and Linkerd

The Shift to Zero Trust

In the traditional "castle-and-moat" security model, we focused heavily on the perimeter. Once a request passed the firewall or the Ingress controller, it was often trusted implicitly. But in a modern Kubernetes environment, this approach is no longer sufficient. Zero Trust assumes that the network is always hostile, and every request—whether it comes from outside the cluster or from a neighboring service—must be authenticated, authorized, and encrypted.

By combining the Kubernetes Gateway API with a service mesh like Linkerd, we can implement a robust Zero Trust architecture that secures both North-South (external) and East-West (internal) traffic with minimal operational overhead.

Gateway API and Service Mesh: A Perfect Match

The Gateway API isn't just for external traffic. While it excels at managing the entry point to your cluster, it was designed with service mesh integration in mind. Linkerd uses the Gateway API's HTTPRoute resources to manage traffic within the mesh, providing a unified way to handle routing, retries, and security policies across the entire stack.

1. Enforcing Mutual TLS (mTLS) by Default

One of Linkerd's core strengths is "automatic mTLS." The moment you inject the Linkerd proxy into your pods, all communication between those pods is automatically encrypted. There are no certificates for you to manage manually; Linkerd handles the rotation and issuance via its own internal CA.

For a sysadmin, this means you get encryption in transit for every service-to-service call without changing a single line of application code.

2. Fine-Grained Authorization with 'Server' Resources

Zero Trust goes beyond encryption; it's about least privilege. Even if traffic is encrypted, should the 'Frontend' service really be allowed to talk to the 'Payments' database? Probably not.

Linkerd uses Server and ServerAuthorization (or AuthorizationPolicy in newer versions) resources to define exactly who can talk to what. This is where the Gateway API's role-oriented design shines. Developers can define these policies alongside their HTTPRoutes.

apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
  name: api-server
  namespace: prod-apps
spec:
  podSelector:
    matchLabels:
      app: api-service
  port: 8080
  proxyProtocol: HTTP/2
---
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-api
  namespace: prod-apps
spec:
  targetRef:
    group: policy.linkerd.io
    kind: Server
    name: api-server
  requiredAuthenticationRefs:
    - group: policy.linkerd.io
      kind: MeshTLSAuthentication
      name: frontend-auth

Bringing it Together: Routing & Security

When you use the Gateway API to route traffic into the mesh, you create a seamless security chain. The Gateway handles the edge TLS termination (using cert-manager), and then the HTTPRoute hands the request off to the Linkerd mesh, where mTLS takes over for the final hop to the service.

Operational Observability

For sysadmins, the "Zero" in Zero Trust can sometimes feel like "Zero Visibility." Linkerd solves this by providing "Golden Signals" (Success Rate, Latency, Throughput) for every secured connection. Because the Gateway API provides a standardized status block, you can quickly see if a routing issue is caused by a security policy rejection or a genuine backend failure.

# Check the status of your route to see security/routing conflicts
kubectl get httproute my-api-route -o yaml

Why Linkerd for Zero Trust?

While Istio is a powerful alternative, Linkerd is often preferred by teams looking for operational simplicity. It is "ultralight," written in Rust for performance and safety, and follows a philosophy of "it just works." When combined with the Gateway API, it provides a future-proof networking stack that satisfies both security auditors and busy developers.

"Security is not a product, but a process. By integrating Zero Trust at the networking level with Linkerd and Gateway API, we make that process invisible and automatic for our developers."