> ## 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.
# Authorizaton
> Explains Istio AuthorizationPolicy usage, enforcement via Envoy, differences with Kubernetes NetworkPolicy, examples, evaluation semantics, benefits, and exam-focused tips for fine grained L7 access control.
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).
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.
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:
```yaml theme={null}
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"]
```
2. Deny GET requests from workloads in the `app` namespace to a specific path (for example, `/credit-cards-info`):
```yaml theme={null}
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"]
```
3. A more expressive policy showing multiple sources (OR semantics), multiple operations, and a JWT `iss` claim check:
```yaml theme={null}
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)
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
| Resource | Layer | Common controls | Example use case |
| --------------------------- | --------- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Kubernetes `NetworkPolicy` | Layer 3/4 | IP / namespace selectors, ports, protocols | Restrict which pods or namespaces can open TCP connections to a service |
| Istio `AuthorizationPolicy` | Layer 7 | HTTP methods, paths, headers, JWT claims, service account principals | Allow 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:
```yaml theme={null}
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):
```yaml theme={null}
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//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
* Istio AuthorizationPolicy: [https://istio.io/latest/docs/reference/config/security/authorization-policy/](https://istio.io/latest/docs/reference/config/security/authorization-policy/)
* Kubernetes NetworkPolicy: [https://kubernetes.io/docs/concepts/services-networking/network-policies/](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
* GitOps with ArgoCD (for declarative policy workflows): [https://argo-cd.readthedocs.io/](https://argo-cd.readthedocs.io/)
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.