Demo Authorizaton

This lesson demonstrates authorization in Istio: after authentication (mTLS) establishes identity, AuthorizationPolicy resources determine what authenticated workloads are allowed to do. We’ll walk through a set of hands-on examples that illustrate:

Enforcing mTLS cluster-wide (PeerAuthentication)
Creating AuthorizationPolicy resources to ALLOW or DENY traffic
How rule scope (namespace, selector, methods, paths) affects behavior
The precedence of DENY over ALLOW

Prerequisites: an Istio-enabled cluster with istio-system installed and working control plane.

1. Deploy example workloads

Apply the httpbin sample used throughout this lesson:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/refs/heads/master/samples/httpbin/httpbin.yaml
# Expected output:
# serviceaccount/httpbin created
# service/httpbin created
# deployment.apps/httpbin created

Verify the httpbin pod is running:

kubectl get pods
# NAME                      READY   STATUS    RESTARTS   AGE
# httpbin-787cdcc9df-nq8ht  2/2     Running   0          74s

Create a test namespace and enable automatic Envoy sidecar injection:

kubectl create ns test
kubectl label ns test istio-injection=enabled
# Optional: validate the namespace with istioctl
# istioctl analyze -n test
# ✔ No validation issues found when analyzing namespace: test.

Run a simple client pod (nginx) in the test namespace — the Istio sidecar will be injected:

kubectl run test --image=nginx -n test
# pod/test created
kubectl get pods -n test
# NAME   READY   STATUS    RESTARTS   AGE
# test   2/2     Running   0          7s

Get the httpbin service (note: this sample uses port 8000):

kubectl get svc
# NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
# httpbin      ClusterIP   10.96.105.55    <none>        8000/TCP   90s
# kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP    39m

From the test pod, verify connectivity to httpbin (no policies yet):

kubectl exec -ti test -n test -- curl --head http://httpbin.default.svc:8000
# HTTP/1.1 200 OK
# server: envoy
# x-envoy-upstream-service-time: 11

2. Enforce mTLS cluster-wide

Create a PeerAuthentication in the istio-system namespace to enforce strict mTLS: peer_auth_global.yaml

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Apply it:

kubectl apply -f peer_auth_global.yaml
# peerauthentication.security.istio.io/default created
kubectl get peerauthentications.security.istio.io -A
# NAMESPACE      NAME     MODE   AGE
# istio-system   default  STRICT 17s

With strict mTLS enforced, workloads in the mesh must present mTLS to communicate; Istio manages certificates via Citadel / Istiod.

3. Basic ALLOW policy — namespace-based, method-scoped

Create an AuthorizationPolicy that ALLOWs only GET requests from namespace test to the workload(s) in the policy scope. auth_policy_allow_test.yaml

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin-auth-policy
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            namespaces: ["test"]
      to:
        - operation:
            methods: ["GET"]

Apply the policy and inspect:

kubectl apply -f auth_policy_allow_test.yaml
kubectl get authorizationpolicies.security.istio.io
# NAME                ACTION   AGE
# httpbin-auth-policy ALLOW    7s

Important: curl --head issues an HTTP HEAD request, not GET. Because this policy allows only GET, HEAD requests will be denied.

Tip: When testing method-based policies, use curl --request GET or a plain curl (defaults to GET). If you prefer HEAD behavior, include HEAD in the policy (e.g., methods: ["GET", "HEAD"]).

Update the policy to allow both GET and HEAD:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin-auth-policy
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            namespaces: ["test"]
      to:
        - operation:
            methods: ["GET", "HEAD"]

Apply the updated policy and test again; now both HEAD and GET succeed from test.

4. Namespace scoping — allow only selected namespaces

Create another namespace app, enable injection, and run a test client there:

kubectl create ns app
kubectl label ns app istio-injection=enabled
kubectl get ns --show-labels
# NAME    STATUS   AGE   LABELS
# app     Active   18s   istio-injection=enabled,kubernetes.io/metadata.name=app
# test    Active   5m58s istio-injection=enabled,kubernetes.io/metadata.name=test
# default Active   ...   istio-injection=enabled,kubernetes.io/metadata.name=default

Run a test pod in app:

kubectl run test --image=nginx -n app
kubectl get pods -n app
# NAME   READY   STATUS    RESTARTS   AGE
# test   2/2     Running   0          16s

A request from app will be denied by the policy that allows only test:

kubectl exec -ti test -n app -- curl --head http://httpbin.default.svc:8000
# HTTP/1.1 403 Forbidden
# server: envoy

To permit both test and app, include both namespaces in from.source.namespaces:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin-auth-policy
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            namespaces: ["test", "app"]
      to:
        - operation:
            methods: ["GET", "HEAD"]

Apply and verify connectivity from both namespaces succeeds.

5. DENY specific paths and the DENY warning

Create a DENY policy that blocks requests to the /delay path: auth_policy_deny.yaml

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin-auth-deny-policy
spec:
  action: DENY
  rules:
    - to:
        - operation:
            paths: ["/delay"]

Before applying, note the API warning behavior:

Warning: A DENY rule that uses only HTTP attributes (methods, paths) can impact TCP traffic under its scope unless you explicitly specify ports. Istio will warn when you apply such a rule. To avoid unintended TCP denial, scope the policy by ports, selector, or namespace.

Apply the DENY policy:

kubectl apply -f auth_policy_deny.yaml
# Warning: configured AuthorizationPolicy will deny all traffic to TCP ports under its scope due to the use of only HTTP attributes in a DENY rule; it is recommended to explicitly specify the port
# authorizationpolicy.security.istio.io/httpbin-auth-deny-policy created
kubectl get authorizationpolicies.security.istio.io
# NAME                      ACTION   AGE
# httpbin-auth-deny-policy  DENY     7s

Requests to http://httpbin.default.svc:8000/delay will now be denied, even if an ALLOW policy also matches — see DENY precedence below.

6. Scoping ALLOW policies by selector, path, and methods

For precise allow rules (e.g., allow only GET/HEAD to /get from clients in app and only for the httpbin workload), use a selector and explicit paths:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin-auth-policy
spec:
  action: ALLOW
  selector:
    matchLabels:
      app: httpbin
  rules:
    - from:
        - source:
            namespaces: ["app"]
      to:
        - operation:
            methods: ["GET", "HEAD"]
            paths: ["/get"]

Apply the policy and test /get from a pod running in app.

7. DENY-all pattern and rule precedence

A deny-all policy example: auth_deny_all.yaml

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  action: DENY
  rules:
    - {}

Important behavior to remember:

DENY policies are evaluated before ALLOW policies. If a DENY matches, the request is rejected even if an ALLOW would also match.
A broad deny-all in the same scope will block traffic unless you remove it or more specifically scope other policies.

If you need to restore access after applying a deny-all, delete it:

kubectl delete -f auth_deny_all.yaml
# authorizationpolicy.security.istio.io "deny-all" deleted

Per-workload deny example (target productpage only)

Instead of denying cluster-wide, target a specific workload via selector: auth_deny_product.yaml

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all-product
spec:
  selector:
    matchLabels:
      app: productpage
  action: DENY
  rules:
    - {}

Apply it:

kubectl apply -f auth_deny_product.yaml
# authorizationpolicy.security.istio.io/deny-all-product created

Now calls to productpage will return 403, while other services (e.g., httpbin) remain accessible:

kubectl exec -ti test -n app -- curl --head http://productpage.default.svc:9080/productpage
# HTTP/1.1 403 Forbidden
kubectl exec -ti test -n app -- curl --head http://httpbin.default.svc:8000/get
# HTTP/1.1 200 OK

View active policies:

kubectl get authorizationpolicies.security.istio.io -A
# NAMESPACE  NAME                 ACTION AGE
# default    deny-all-product     DENY   22s
# default    httpbin-auth-policy  ALLOW  33m

Deny rules are evaluated before allow rules. If both DENY and ALLOW match a request, the DENY takes precedence. Use targeted DENY rules (by selector, namespace, port, or path) rather than a broad deny-all unless you intend to explicitly allow everything else.

Summary table — useful Istio security resources

Resource Type	Purpose	Example / Notes
PeerAuthentication	Configure mTLS mode (DISABLE, PERMISSIVE, STRICT)	`PeerAuthentication` in `istio-system` to enable STRICT cluster-wide
AuthorizationPolicy	Allow/deny/AUDIT/CUSTOM for workload access	`AuthorizationPolicy` with `selector`, `from`, `to`, `when`
ServiceAccount / Principal	Identities used in `from.source.principals`	Use `cluster.local/ns/<ns>/sa/<sa>` for principals
Operation attributes	Filter by HTTP method/path/port	`to.operation.methods`, `to.operation.paths`, `to.operation.ports`

Reference and additional resources

The image shows a webpage from the Istio documentation focused on "Authorization," detailing various access control methods for Istio services. It includes links for setting up access controls like HTTP traffic, TCP traffic, and JWT tokens.

The Istio AuthorizationPolicy API supports:

Scoping by workload (selector.matchLabels)
from (source: namespaces, principals, service accounts)
to (operation: methods, paths, ports)
when (conditions based on request attributes, JWT claims)
Actions: ALLOW, DENY, AUDIT, CUSTOM (ALLOW and DENY are most commonly used)

For authoritative documentation and examples, see the Istio Authorization Policy reference:

https://istio.io/latest/docs/reference/config/security/authorization-policy/

The image shows a webpage from Istio's documentation discussing the "Authorization Policy," which involves access control on workloads in the mesh. It outlines the use of CUSTOM, DENY, and ALLOW actions for access control.

Key takeaways

Authentication (mTLS) establishes identity; authorization decides what that identity may do.
AuthorizationPolicy is powerful but can be subtle. Pay attention to:
- Rule scope (namespace-level vs workload selector)
- Verb vs method differences (e.g., GET vs HEAD)
- DENY precedence over ALLOW
- Warnings about DENY rules with only HTTP attributes and their potential effect on TCP traffic
Practice common patterns: allow-by-namespace, allow-by-service-account, deny-by-path, and per-workload deny to build confidence for production and certification scenarios.

Introduction

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

Conclusion

1. Deploy example workloads

2. Enforce mTLS cluster-wide

3. Basic ALLOW policy — namespace-based, method-scoped

4. Namespace scoping — allow only selected namespaces

5. DENY specific paths and the DENY warning

6. Scoping ALLOW policies by selector, path, and methods

7. DENY-all pattern and rule precedence

Per-workload deny example (target productpage only)

Summary table — useful Istio security resources

Reference and additional resources

Key takeaways

Watch Video

Practice Lab

​1. Deploy example workloads

​2. Enforce mTLS cluster-wide

​3. Basic ALLOW policy — namespace-based, method-scoped

​4. Namespace scoping — allow only selected namespaces

​5. DENY specific paths and the DENY warning

​6. Scoping ALLOW policies by selector, path, and methods

​7. DENY-all pattern and rule precedence

​Per-workload deny example (target productpage only)

​Summary table — useful Istio security resources

​Reference and additional resources

​Key takeaways

Watch Video

Practice Lab

1. Deploy example workloads

2. Enforce mTLS cluster-wide

3. Basic ALLOW policy — namespace-based, method-scoped

4. Namespace scoping — allow only selected namespaces

5. DENY specific paths and the DENY warning

6. Scoping ALLOW policies by selector, path, and methods

7. DENY-all pattern and rule precedence

Per-workload deny example (target productpage only)

Summary table — useful Istio security resources

Reference and additional resources

Key takeaways