Skip to main content

Documentation Index

Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt

Use this file to discover all available pages before exploring further.

Think of authorization like the ticketing system at a stadium: authentication confirms your identity at the gate, while authorization determines where you may sit and what areas you can access. In a service mesh, Istio uses AuthorizationPolicy resources to express those permissions after identities have been established (for example, via mTLS or JWT authentication).
A diagram titled "Istio Authorization" showing a Kubernetes service mesh spanning three nodes. Each node box contains an app, a corresponding service, and an Envoy sidecar proxy.
Istio enforces authorization at the Envoy sidecar proxy level. You place AuthorizationPolicy objects on the mesh (cluster, namespace, or workload scope) to allow or deny traffic based on attributes such as source identity, request method, paths, ports, and JWT claims.
A diagram titled "Authorization Example" showing Envoy proxies mediating requests between services labeled Inventory, Shoes, and Users. A green arrow indicates an authorized POST to Shoes while a red arrow shows a denied GET to Users, with a note about a service account cert and key mounted into the proxy.
Key differences to remember
  • Authentication = who the caller is (identity).
  • Authorization = what the caller can do (permissions).
  • Istio AuthorizationPolicy operates at layer 7 (HTTP methods, paths, JWT claims).
  • Kubernetes NetworkPolicy operates at layer 3/4 (IP, namespace, ports).
Istio enforces policies in the proxy (Envoy). AuthorizationPolicy objects can be scoped by namespace, selector (workload label), or applied mesh-wide. Use them for fine-grained, identity-aware access controls.

​
AuthorizationPolicy examples

Below are common AuthorizationPolicy examples. Each example uses the security.istio.io/v1beta1 API and demonstrates common from, to, and when patterns.
  1. Allow POST requests from any workload in the app namespace to workloads in the payments namespace:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payments-allow-post
  namespace: payments
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["app"]
    to:
    - operation:
        methods: ["POST"]
  1. Deny GET requests from workloads in the app namespace to a specific path (for example, /credit-cards-info):
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payments-deny-credit-cards
  namespace: payments
spec:
  action: DENY
  rules:
  - from:
    - source:
        namespaces: ["app"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/credit-cards-info"]
  1. A more expressive policy showing multiple sources (OR semantics), multiple operations, and a JWT iss claim check:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payments-complex-policy
  namespace: payments
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/identity/sa/app"]
    - source:
        namespaces: ["app"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/data"]
    - operation:
        methods: ["POST"]
        paths: ["/purchases"]
    when:
    - key: request.auth.claims[iss]
      values: ["https://accounts.google.com"]
Evaluation semantics (OR vs AND)
  • Multiple entries in a list (for example, multiple - source: items) are evaluated as OR.
  • If you want an AND-like requirement, combine attributes under a single list item (for example, a source entry that contains both principals and namespaces).
  • Rules are evaluated to determine if any rule allows or denies the request according to the policy action. Be mindful of ordering and scope (namespace vs workload selector).

​
Why use Istio AuthorizationPolicy (benefits)

A presentation slide titled "Why Use Authorization Policies?" showing four colored panels. Each panel (01–04) lists a benefit—Fine-grained access control, Zero-Trust architecture, Identity-based access, and Declarative policies—with a simple icon.
Benefits include:
  • Fine-grained access control (methods, paths, headers).
  • Zero-trust model (identity first, least privilege).
  • Identity-based policies (service account principals, JWT claims).
  • Declarative resources that fit GitOps workflows and auditing.
Authorization is an important topic for the exam—expect questions that test differences between authentication and authorization, the structure of AuthorizationPolicy rules (from, to, when), and layer 7 vs layer 3/4 distinctions.

​
NetworkPolicy vs AuthorizationPolicy — at a glance

ResourceLayerCommon controlsExample use case
Kubernetes NetworkPolicyLayer 3/4IP / namespace selectors, ports, protocolsRestrict which pods or namespaces can open TCP connections to a service
Istio AuthorizationPolicyLayer 7HTTP methods, paths, headers, JWT claims, service account principalsAllow only POST to /purchases from a specific service account or JWT issuer
Example Kubernetes NetworkPolicy that allows pods in the app namespace to reach payments pods on TCP port 8080: 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payments-allow-netpol
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          app: app
    ports:
    - protocol: TCP
      port: 8080
Compare with an Istio AuthorizationPolicy that enforces namespace + port plus method and path (layer 7): 
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payments-allow-istio
  namespace: payments
spec:
  action: ALLOW
  rules:
  - selector:
      matchLabels:
        app: payments
    from:
    - source:
        namespaces: ["app"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/api"]
        ports: ["8080"]
Both are declarative and can complement each other: use NetworkPolicy for coarse L3/L4 network controls and Istio AuthorizationPolicy for fine-grained L7 access controls and identity checks.

​
Practical tips and exam focus

  • Understand the AuthorizationPolicy structure: action and rules → from, to, when.
  • Know how lists are evaluated (OR behavior) and how to combine attributes for AND-like effects.
  • Know common attributes to reference: namespaces, principals (service account identity like cluster.local/ns/<ns>/sa/<sa>), request.auth.claims[...].
  • Remember that AuthorizationPolicy is enforced by Envoy sidecars, so policy scope (namespace/selector/mesh) matters in a multi-tenant cluster.
  • Practice writing policies that mix selector and namespace scoping and test them with curl or istioctl authz check to validate behavior.
Further reading This article covered core concepts and practical examples. Try creating these policies in a test cluster and observe how Envoy enforces them to reinforce the concepts.

Watch Video