Skip to main content
Think of Istio authorization like a ticketed event: authentication (mTLS / JWT verification) is the identity check at the gate, while authorization is the assigned seating—who can access which services, on which paths and methods. After workloads are authenticated, Istio authorization policies determine what each workload is allowed to do inside the mesh.
The image illustrates an Istio authorization setup within a Kubernetes cluster, depicting a service mesh across three nodes. Each node hosts an application and service, with Envoy proxies managing communication and authorization between services.
Example scenario: the inventory service can POST to the shoes service on port 80 but cannot GET the user service on port 80. All services have Envoy sidecars injected, so authentication has already occurred. Authorization policies then allow or deny requests according to rules you declare.
The image illustrates an authorization example using a proxy architecture with services for inventory, shoes, and users, showing request flows and authorization outcomes.

​
AuthorizationPolicy: basic examples

Authorization policies are custom resources (AuthorizationPolicy) in Istio. The examples below demonstrate common patterns: ALLOW, DENY, and a more expressive policy that checks identity and JWT claims. Example: allow POST requests to any workload in the payments namespace coming from workloads in the app namespace:
Example: deny GET requests from the app namespace to the /credit-cards-info path in the payments namespace:
Advanced example: allow requests to the payments service when the request comes from either:
  • the specific service account cluster.local/ns/identity/sa/app (a principal), OR
  • any workload in the app namespace,
and allow GET to /data and POST to /purchases only when the JWT issuer (request.auth.claims[iss]) equals https://accounts.google.com:
Important: Entries under from: are evaluated as OR between list items. If you combine multiple conditions under a single source: block instead of listing them separately, you may unintentionally require all conditions to be true (AND).
You can list multiple operation blocks under to: to allow different method/path combinations for the same rule. Use selector to scope policies to specific workloads (by labels) in the namespace.

​
Istio Authorization vs Kubernetes NetworkPolicy

Istio AuthorizationPolicy enforces application-layer (L7) access control with identity and request attributes (methods, paths, JWT claims). Kubernetes NetworkPolicy enforces network/transport-layer (L3/L4) rules like pod selectors, namespaces, IPBlocks, and ports. Example NetworkPolicy that allows traffic to pods labeled app: payments from the app namespace on TCP port 8080:
Example Istio AuthorizationPolicy that enforces a GET to /api on port 8080 and only allows requests from the app namespace:
Because Istio enforces policies at the Envoy sidecar (L7), you can implement fine-grained, identity-aware, zero-trust access control (least privilege). Policies are declarative, GitOps-friendly, and auditable.
The image is a slide titled "Why Use Authorization Policies?" showing four benefits: fine-grained access control, zero-trust architecture, identity-based access, and declarative policies.

​
Fields and examples you’ll see on the exam

Here are common source fields and fragments you may encounter in questions or practical tasks—study the full reference in the Istio docs:
Exam tip: Understand how from, to, and when combine (OR vs AND), know the difference between L3/L4 NetworkPolicy and L7 AuthorizationPolicy, and be familiar with matching by selector, principals, and JWT claim keys such as request.auth.claims[iss].
Authorization policies are more expressive than peer authentication (mTLS) alone—invest time in hands-on practice and review the Istio AuthorizationPolicy reference for all available fields. That’s the theory — next up: a hands-on demo configuring policies and testing enforcement.

Watch Video