Service Mesh Authorization: A Bouncer for Your Microservices

Why it exists

In microservice architectures, traditional IP-based firewalls are ineffective because service instances are ephemeral and IPs change constantly. Authorization policies solve this by enabling access control based on strong, cryptographic service identities rather than network locations. This decouples security rules from application code.

The mental model

Think of it as a bouncer at a club's VIP room door. A Kubernetes NetworkPolicy is like the front door guard checking if you're on the building's guest list (can this IP talk to that IP?). An AuthorizationPolicy is the bouncer inside who inspects your ID (service identity, JWT), asks what you want (HTTP method and path), and checks if you have permission for that specific action.

How it works

You define an AuthorizationPolicy resource in Kubernetes. This policy selects a target workload (e.g., the payments-api service) and specifies rules. The rules define who is allowed or denied access (from), what operations they can perform (to), and under what conditions (when). The service mesh's sidecar proxy (like Envoy) intercepts every request to the workload and enforces these rules before the request ever reaches your application.

When to use it

Use it to enforce Zero Trust security between services. It's ideal for fine-grained control, like allowing GET but not POST requests from a specific service, or restricting access to /admin endpoints to only requests carrying a JWT with an admin: true claim. This is the tool for securing service-to-service communication.

When not to use it

Don't use it for basic L3/L4 network segmentation; a standard Kubernetes NetworkPolicy is simpler and more appropriate for blocking traffic between pods based on IP or port. Also, it's not for application-level authorization, like checking if a user has permission to edit a specific document they own. That logic belongs in your application.

One canonical example

A common pattern is to create a default "deny-all" policy for a namespace. Then, you add a second policy that explicitly allows the ingress-gateway to send GET requests to the /products path of the product-catalog service, and another policy allowing the checkout service to call any path on the inventory service. This "deny by default, allow by exception" model is a core Zero Trust principle.