Security

Overview

Istio provides a comprehensive security model covering service-to-service authentication (mTLS), end-user authentication (JWT), and fine-grained authorization policies. Security is enforced at the data plane by Envoy sidecars, ztunnel proxies, and waypoint proxies. The control plane (Citadel within istiod) manages certificate lifecycle and trust establishment.

See also: index, architecture, operations

1. Mutual TLS (mTLS)

Identity Model

Istio uses SPIFFE (Secure Production Identity Framework for Everyone) for workload identity:

spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>

This identity is encoded in the X.509 certificate SAN and used throughout the mesh for authentication and authorization.

Certificate Lifecycle

1. Citadel (within istiod) acts as the mesh CA
2. Envoy sidecar / ztunnel sends a CSR (Certificate Signing Request) to Citadel
3. Citadel validates the request against the Kubernetes Service Account
4. Citadel issues a short-lived X.509 certificate (default 24-hour lifetime)
5. The proxy automatically rotates the certificate before expiry
6. Certificate distribution uses the Envoy SDS (Secret Discovery Service) API

PeerAuthentication Modes

PeerAuthentication controls the mTLS mode for service-to-service communication:

Mode	Behavior
STRICT	All connections must use mTLS. Plaintext connections are rejected.
PERMISSIVE	Accepts both mTLS and plaintext connections. Useful for migration.
DISABLE	mTLS is disabled. Connections are plaintext.
UNSET	Inherits from parent (namespace then mesh-wide). Defaults to PERMISSIVE.

Example -- enforce STRICT mTLS for an entire namespace:

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

Example -- namespace PERMISSIVE with specific workload STRICT:

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: PERMISSIVE
---
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: finance
  namespace: foo
spec:
  selector:
    matchLabels:
      app: finance
  mtls:
    mode: STRICT

Migration Path

Use PERMISSIVE mode during onboarding to allow gradual migration of services into the mesh. Switch to STRICT once all clients are meshed. In ambient mode, ztunnel enforces mTLS at L4 by default.

2. Certificate Rotation and CA Management

Automatic Rotation

• Workload certificates have a default 24-hour lifetime
• Proxies request new certificates automatically before expiry
• No application downtime during rotation

Root CA Options

CA Type	Description
Self-signed (default)	Istio generates its own root CA on install
Kubernetes CA	Uses the Kubernetes cluster CA as trust root
External CA	Integrates with enterprise PKI via CSR flow
Plugin CA	Custom CA implementation via the Istio CA plugin interface

Certificate Hierarchy

Root CA (long-lived, provisioned at install)
  └── Intermediate CA (managed by Citadel)
        └── Workload Certificate (24h, per Service Account)

3. AuthorizationPolicy

AuthorizationPolicy provides fine-grained L4 and L7 access control based on identity, namespace, headers, and other request attributes.

graph LR
    SRC["Source Workload<br/>identity: spiffe://.../sa/frontend"] -->|request| DST["Destination Workload<br/>identity: spiffe://.../sa/backend"]
    DST -->|evaluate AuthPolicy| POL{"AuthorizationPolicy"}
    POL -->|ALLOW| PASS["Request forwarded"]
    POL -->|DENY| REJECT["Connection rejected"]

Policy Structure

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["spiffe://cluster.local/ns/frontend/sa/frontend-sa"]
        namespaces: ["frontend"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/*"]
    when:
    - key: request.headers[x-token]
      values: ["valid-token"]

Actions

Action	Behavior
ALLOW	Allow requests matching the rules. All other requests are denied.
DENY	Deny requests matching the rules. Evaluated before ALLOW.
AUDIT	Log requests matching the rules (does not block).
CUSTOM	Delegate to an external authorization service.

Matching Criteria

• source: principals (SPIFFE identity), namespaces, ipBlocks, remoteIpBlocks
• operation: hosts, methods, paths, ports, protocols
• when conditions: arbitrary key-value conditions on request properties (headers, claims, etc.)

4. RequestAuthentication (JWT)

RequestAuthentication validates JSON Web Tokens in incoming requests. It supports OpenID Connect providers and custom JWT issuers.

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-auth
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  jwtRules:
  - issuer: "https://auth.YOUR_DOMAIN"
    jwksUri: "https://auth.YOUR_DOMAIN/.well-known/jwks.json"
    audiences:
    - "api-backend"
    forwardOriginalToken: true

Key features:

• Token validation against JWKS endpoints
• Support for multiple JWT issuers per workload
• forwardOriginalToken: true passes the raw token to the backend application
• Token claims can be used in AuthorizationPolicy when conditions
• Supports token triggered from headers, cookies, or query parameters

JWT + AuthorizationPolicy Integration

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: production
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals: ["https://auth.YOUR_DOMAIN/my-audience"]

An empty requestPrincipals means any authenticated request is allowed. Omitting it allows unauthenticated requests.

5. Ambient Mesh Security

In ambient mode, the security model differs from sidecar mode:

Layer	Component	Security
L4	ztunnel	Automatic mTLS between nodes via HBONE protocol
L7	Waypoint proxy	AuthorizationPolicy, RequestAuthentication (JWT)
Node	ztunnel	Multi-tenant -- holds certs for all local Service Accounts

ztunnel enforces mTLS at L4 by default in ambient mode. HBONE tunneling on port 15008 ensures all inter-node traffic is encrypted. L7 policies (HTTP method/path filtering, JWT validation) require a waypoint proxy.

6. External CA Integration

For enterprises with existing PKI infrastructure, Istio supports external CA integration:

1. Configure istiod with --root-ca pointing to the external root certificate
2. Enable the CSR signing API on the external CA
3. Istiod forwards CSRs to the external CA for signing
4. The external CA controls certificate policies, revocation, and audit

7. Security Policy Evaluation Order

Istio evaluates security policies in the following order (highest priority first):

1. DENY AuthorizationPolicy (always evaluated first)
2. AUTHORIZATION POLICY (CUSTOM action, external auth)
3. ALLOW AuthorizationPolicy
4. AUDIT AuthorizationPolicy (logging only, does not block)
5. PeerAuthentication (mTLS enforcement)
6. RequestAuthentication (JWT validation)

Key Insight

Istio's security model is defense-in-depth: PeerAuthentication ensures transport encryption (mTLS), RequestAuthentication validates end-user identity (JWT), and AuthorizationPolicy enforces fine-grained access control at both L4 and L7. In ambient mode, L4 security is provided by ztunnel with zero application changes, while L7 policies require a waypoint proxy.