Istio Glossary

Reviewed Version: Istio 1.31.0 Last Updated: October 12, 2026

This glossary organizes key terms related to Istio and Service Mesh in grouped reference sections.

Reference language: The Architecture and DestinationRule section links below use the maintained English guides. These links provide the current reference where locale translations have not yet been synchronized.

A-C

AuthorizationPolicy

An Istio security policy defining ALLOW, DENY, CUSTOM, or AUDIT behavior for selected workloads or target resources. Authentication and authorization are separate; waypoint policies use targetRefs.

Control Plane

The configuration, discovery, and identity-management layer, implemented by istiod. Application payloads flow through data-plane proxies rather than through istiod.

Ambient Mode

A data plane mode first shipped as alpha in Istio 1.18 and generally available since Istio 1.24 that provides service mesh functionality without Sidecar Proxies.

Features:

No Sidecar containers required
Uses ztunnel at the node level
Improved resource efficiency
Separation of L4 and L7 functions

Related Documentation: Ambient Mode

Certificate Authority (CA)

An authority that issues and manages certificates for mTLS communication between services.

Role in Istio:

Istiod's Citadel function performs the CA role
Issues certificates based on SPIFFE ID
Automatic certificate renewal (default TTL: 24 hours)

Related Terms: Citadel, SPIFFE, mTLS

Circuit Breaker

A pattern that blocks requests to failed services to prevent failure propagation throughout the entire system.

How It Works:

Closed: Normal operation
Open: Blocks requests after consecutive failures
Half-Open: Allows some requests after a certain time

Istio Implementation: Connection-pool circuit breaking and per-endpoint outlier ejection do not expose this literal three-state machine.

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: glossary-example-1
spec:
  host: reviews
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s

Related Documentation: Circuit Breaker

Citadel

A security component that existed independently through Istio 1.4. It is now integrated into Istiod.

Main Functions:

Certificate Authority (CA) management
SPIFFE ID issuance and management
X.509 certificate generation and renewal

Current Status: Exists as an internal function within Istiod in Istio 1.5+

Related Terms: Istiod, Certificate Authority

CDS (Cluster Discovery Service)

One of the xDS APIs that allows Envoy to dynamically receive configuration for upstream services (clusters).

Information Provided:

Cluster name and type
Load balancing policy
Health check settings
Circuit breaker settings
TLS settings

Related Terms: xDS, Envoy

D-F

Data Plane

The layer that handles actual traffic in a service mesh.

Istio's Data Plane:

Envoy sidecars, or ambient ztunnel plus optional L7 waypoints
Handles enrolled mesh traffic; exclusions and protocol limits apply
mTLS encryption/decryption
Metric collection

Related Terms: Control Plane, Envoy

DestinationRule

An Istio CRD that defines policies for traffic routed by VirtualService.

Main Functions:

Subset definition (version, region, etc.)
Load balancing policy
Connection Pool settings
Circuit Breaker settings
TLS settings

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Related Documentation: DestinationRule

eBPF (Extended Berkeley Packet Filter)

A technology that allows programs to run safely inside the Linux kernel.

Istio can coexist with an eBPF-based primary CNI such as Cilium. Istio CNI is a separate chained plugin/node agent that configures redirection; ambient does not require eBPF and does not replace the primary CNI.

Advantages:

Low overhead
Kernel-level processing
Dynamic programming capability

Related Terms: Ambient Mode, iptables

EDS (Endpoint Discovery Service)

One of the xDS APIs that dynamically provides actual endpoints (pod IPs) within a cluster.

Information Provided:

Endpoint IP addresses and ports
Health status
Load balancing weights
Locality information

Example:

json

{
  "cluster_name": "outbound|9080||reviews",
  "endpoints": [
    {
      "lb_endpoints": [
        {"endpoint": {"address": {"socket_address": {"address": "10.244.1.5", "port_value": 9080}}}},
        {"endpoint": {"address": {"socket_address": {"address": "10.244.2.8", "port_value": 9080}}}}
      ]
    }
  ]
}

Related Terms: xDS, CDS

Envoy Proxy

A high-performance L7 proxy that forms the Data Plane of Istio.

History:

Developed by Matt Klein at Lyft in 2016
CNCF Incubating project in 2017
CNCF Graduated project in 2018

Key Features:

High-performance proxy written in C++
Dynamic configuration through xDS API
HTTP/1.1, HTTP/2, gRPC support
Rich observability

Components:

Listeners: Port listening
Filters: Request/response processing
Routers: Routing decisions
Clusters: Upstream services

Related Documentation: Architecture - Envoy Proxy

G-I

Galley

A configuration validation component that existed independently through Istio 1.4. It is now integrated into Istiod.

Main Functions:

Istio configuration validation
Kubernetes resource processing
Error checking before configuration deployment

Current Status: Exists as an internal function within Istiod in Istio 1.5+

Related Terms: Istiod

Gateway

An Istio CRD that defines entry points for external traffic entering the Service Mesh.

Types:

Ingress Gateway: External to internal traffic
Egress Gateway: Internal to external traffic

yaml

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "example.com"

Related Documentation: Gateway and VirtualService

gRPC

A high-performance RPC (Remote Procedure Call) framework developed by Google.

Relationship with Istio:

xDS API is gRPC-based
Used for Istiod to Envoy communication
HTTP/2 based (supports multiplexing)

Advantages:

Bidirectional streaming
Low latency
Uses Protocol Buffers

Related Terms: xDS

Identity

Represents the identity of a workload within the Service Mesh.

Istio's Identity:

Uses SPIFFE ID format
Based on Kubernetes ServiceAccount
Proven by X.509 certificates

Example:

spiffe://cluster.local/ns/default/sa/reviews

Related Terms: SPIFFE, mTLS

iptables

A firewall tool that controls network traffic in Linux.

Role in Istio:

istio-init or the Istio CNI node agent configures traffic redirection
Redirects all pod traffic to Envoy
Uses NAT table (PREROUTING, OUTPUT chains)

Simplified rules (illustration, not an installation script):

bash

# Outbound: All traffic except Envoy -> 15001
iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner 1337 -j REDIRECT --to-port 15001

# Inbound: All traffic -> 15006
iptables -t nat -A PREROUTING -p tcp -j REDIRECT --to-port 15006

Setup alternative: Istio CNI performs privileged network setup at node level.

Related Documentation: Architecture - iptables

Istiod

The unified Control Plane component in Istio 1.5+.

Integrated Functions:

Pilot: Service Discovery, Traffic Management
Citadel: Certificate Authority, Identity
Galley: Configuration Validation

Execution Method:

Single Go binary: pilot-discovery
All functions run within a single process
Default ports: 15012 (xDS), 15017 (Webhook)

Advantages:

Reduced complexity
Simplified operations
Resource efficiency

Related Documentation: Architecture - Istiod

J-L

LDS (Listener Discovery Service)

One of the xDS APIs that allows Envoy to dynamically receive ports to listen on and filter chains.

Information Provided:

Listener address and port
Protocol (HTTP, TCP)
Filter chain configuration
TLS settings

Istio's Default Listeners:

0.0.0.0:15001: Outbound TCP
0.0.0.0:15006: Inbound TCP
0.0.0.0:15021: Health check
0.0.0.0:15090: Prometheus metrics

Related Terms: xDS, Envoy

Locality-aware Load Balancing

A load balancing method that considers locality (Region, Zone) information.

Priority:

Endpoints in the same Zone
Different Zone in the same Region
Different Region

Configuration Example:

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: glossary-example-2
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        distribute:
        - from: us-west/zone-1a/*
          to:
            "us-west/zone-1a/*": 80
            "us-west/zone-1b/*": 20

Related Documentation: Zone Aware Routing

M-O

Mixer

A policy and telemetry component that existed through Istio 1.4.

Main Functions:

Policy enforcement (Rate Limiting, Access Control)
Telemetry collection

Reasons for Removal:

Performance overhead (Mixer call for every request)
Complex architecture

Current Status: Deprecated during the 1.5 transition; remaining Mixer functionality removed in 1.8

Related Terms: Istiod

mTLS (Mutual TLS)

A bidirectional TLS communication method where client and server authenticate each other.

Istio's mTLS:

Automatic certificate issuance and renewal
SPIFFE ID-based authentication
TLS cipher is negotiated; it is not fixed to AES-256-GCM

Modes:

STRICT: Only mTLS allowed
PERMISSIVE: mTLS + plaintext allowed (for migration)
DISABLE: Disable Istio transport mTLS in sidecar mode; unsupported in ambient

yaml

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

Related Documentation: mTLS

Outlier Detection

A feature that automatically excludes endpoints exhibiting abnormal behavior.

Detection Conditions:

Consecutive error count
Error rate
Connection failures/timeouts; latency alone is not an outlier-ejection threshold

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: glossary-example-3
spec:
  host: reviews
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

Related Documentation: Outlier Detection

P-R

Downstream

From Envoy's perspective, this refers to the side that sends requests. That is, the client that initiates a connection to Envoy.

Envoy's Downstream:

Connections coming into Envoy (Inbound)
Client sending requests
Connections received by Listener

Traffic Flow:

Downstream (Client)  ->  Envoy Proxy  ->  Upstream (Backend)

Example Scenarios:

1. Sidecar Mode - Outbound Request

In sidecar mode the application (downstream) sends a request to the Envoy sidecar in the same Pod, and Envoy forwards it to the backend service (upstream).

In sidecar mode the application (downstream) sends a request to the Envoy sidecar in the same Pod, and Envoy forwards it to the backend service (upstream).Open full screen ↗

Perspective:

From Envoy's view: Application is Downstream (sending requests)
From Envoy's view: Backend service is Upstream (receiving requests)

2. Ingress Gateway - External Request

From the Ingress Gateway's Envoy perspective, an external client is the downstream side and the internal service it routes to is the upstream side.

From the Ingress Gateway's Envoy perspective, an external client is the downstream side and the internal service it routes to is the upstream side.Open full screen ↗

Downstream-related Envoy Configuration:

yaml

# Listener - Receive Downstream connections
apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: downstream-config
  namespace: default
spec:
  workloadSelector:
    labels:
      app: reviews
  configPatches:
  - applyTo: LISTENER
    match:
      context: SIDECAR_INBOUND
    patch:
      operation: MERGE
      value:
        per_connection_buffer_limit_bytes: 32768  # Downstream buffer

Downstream Metrics:

bash

# Downstream connection count
envoy_listener_downstream_cx_active

# Downstream request count
envoy_http_downstream_rq_total

# Downstream response time
envoy_http_downstream_rq_time

Related Terms: Upstream, Envoy, Listener

Upstream

From Envoy's perspective, this refers to the side that receives requests. That is, the backend service to which Envoy initiates a connection.

Envoy's Upstream:

Connections going out from Envoy (Outbound)
Backend service processing requests
Endpoints managed by Cluster

Traffic Flow:

Downstream (Client)  ->  Envoy Proxy  ->  Upstream (Backend)

Upstream Components:

1. Cluster (Upstream Group)

yaml

# Define Upstream Cluster with DestinationRule
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews  # Upstream service
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    connectionPool:
      tcp:
        maxConnections: 100      # Upstream connection limit
      http:
        http1MaxPendingRequests: 50
        http2MaxRequests: 100
    outlierDetection:
      consecutive5xxErrors: 5        # Upstream failure detection
      interval: 30s

2. Endpoint (Actual Upstream Instance)

bash

# Check upstream endpoints
istioctl proxy-config endpoints <pod-name> | grep reviews

# Example output:
# ENDPOINT              STATUS      CLUSTER
# 10.244.1.5:9080       HEALTHY     outbound|9080||reviews.default.svc.cluster.local
# 10.244.2.8:9080       HEALTHY     outbound|9080||reviews.default.svc.cluster.local
# 10.244.3.12:9080      UNHEALTHY   outbound|9080||reviews.default.svc.cluster.local

Upstream Traffic Policy:

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: glossary-example-4
spec:
  host: reviews
  trafficPolicy:
    # Upstream load balancing
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-user-id"

    # Upstream connection pool
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 30s
      http:
        h2UpgradePolicy: UPGRADE

    # Upstream TLS
    tls:
      mode: ISTIO_MUTUAL

    # Upstream Circuit Breaker
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s

Upstream vs Downstream Comparison:

Item	Downstream	Upstream
Direction	Coming into Envoy (Inbound)	Going out from Envoy (Outbound)
Role	Sending requests (Client)	Receiving requests (Server)
Envoy Configuration	Listener, Filter Chain	Cluster, Endpoint
Examples	External users, other services	Backend API, Database
Metrics	`downstream_cx_`, `downstream_rq_`	`upstream_cx_`, `upstream_rq_`

Real-world Examples:

Scenario 1: Service A -> Service B Call

+---------------------------------------------------------+
| Service A Pod                                           |
|                                                         |
|  App --> Envoy Sidecar                                 |
|          |                                              |
|          | Downstream: App                              |
|          | Upstream: Service B                          |
+----------|-------------------------------------------------+
           |
           v
+---------------------------------------------------------+
| Service B Pod                                           |
|                                                         |
|          Envoy Sidecar --> App                          |
|          |                                              |
|          | Downstream: Service A Envoy                  |
|          | Upstream: Local App (Service B)              |
+---------------------------------------------------------+

Service A's Envoy Perspective:

Downstream: Service A's application
Upstream: Service B

Service B's Envoy Perspective:

Downstream: Service A's Envoy
Upstream: Service B's application (local)

Scenario 2: Ingress Gateway

External Client (Downstream)
        |
Ingress Gateway (Envoy)
        |
Internal Service (Upstream)

Upstream Metrics:

bash

# Upstream connection count
envoy_cluster_upstream_cx_active

# Upstream request counter; derive success/error rates from response-class counters
envoy_cluster_upstream_rq_total

# Upstream response time
envoy_cluster_upstream_rq_time

# Upstream health check
envoy_cluster_health_check_success

# Upstream Circuit Breaker
envoy_cluster_circuit_breakers_default_remaining_rq

Passive Upstream Health Detection: Active health-check statistics require separate configuration.

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: glossary-example-5
spec:
  host: reviews
  trafficPolicy:
    outlierDetection:
      # Upstream health detection
      consecutiveGatewayErrors: 5
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

Debugging:

bash

# 1. Check upstream cluster
istioctl proxy-config clusters <pod-name> --fqdn reviews.default.svc.cluster.local

# 2. Check upstream endpoint status
istioctl proxy-config endpoints <pod-name> --cluster "outbound|9080||reviews.default.svc.cluster.local"

# 3. Check upstream metrics
kubectl exec <pod-name> -c istio-proxy -- \
  curl -s localhost:15000/stats/prometheus | grep upstream

# 4. Check upstream connections
istioctl proxy-config all <pod-name> -o json | \
  jq '.configs[] | select(.["@type"] | contains("ClustersConfigDump"))'

Related Terms: Downstream, Envoy, Cluster, Endpoint

Pilot

A traffic management component that existed independently through Istio 1.4. It is now integrated into Istiod.

Main Functions:

Service Discovery
Traffic Management (VirtualService, DestinationRule processing)
xDS Server

Current Status: Exists as an internal function within Istiod in Istio 1.5+

Related Terms: Istiod, xDS

RDS (Route Discovery Service)

One of the xDS APIs that dynamically provides HTTP routing rules.

Information Provided:

Route matching rules (path, headers, etc.)
Weight-based routing
Redirect and rewrite rules
Timeout and Retry settings

Relationship with VirtualService:

VirtualService -> Converted by Istiod -> RDS configuration

Related Terms: xDS, VirtualService

Rate Limiting

A feature that limits the number of requests allowed per unit time.

Implementation Methods:

Local Rate Limiting: Processed locally by Envoy
Global Rate Limiting: Uses an external Rate Limit service

yaml

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: filter-local-ratelimit
  namespace: default
spec:
  workloadSelector:
    labels:
      app: reviews
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener:
        filterChain:
          filter:
            name: envoy.filters.network.http_connection_manager
            subFilter:
              name: envoy.filters.http.router
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.local_ratelimit
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
          stat_prefix: http_local_rate_limiter
          token_bucket:
            max_tokens: 100
            tokens_per_fill: 100
            fill_interval: 1s
          filter_enabled:
            default_value:
              numerator: 100
              denominator: HUNDRED
          filter_enforced:
            default_value:
              numerator: 100
              denominator: HUNDRED

Related Documentation: Rate Limiting

S-U

SDS (Secret Discovery Service)

One of the xDS APIs that dynamically provides TLS certificates and keys.

Information Provided:

X.509 certificates
Private Key
CA Root Certificate

Advantages:

No file system required
Automatic certificate renewal
Zero-downtime renewal

Related Terms: xDS, mTLS

Service Entry

An Istio CRD that registers services external to the Service Mesh into the mesh.

Use Cases:

External API access control
Apply Istio features to external services (Retry, Timeout, etc.)
Egress Gateway integration

yaml

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-api
spec:
  hosts:
  - api.external.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

Related Documentation: ServiceEntry

Service Mesh

An infrastructure layer that manages communication between microservices.

Core Features:

Traffic management (routing, load balancing)
Security (mTLS, authentication/authorization)
Observability (metrics, logs, tracing)
Resilience (Retry, Circuit Breaker)

Major Implementations:

Istio
Linkerd
Consul Connect
AWS App Mesh (support ended September 30, 2026)

SigV4 (AWS Signature Version 4)

A signature protocol for authenticating AWS API requests.

How It Works:

Sequence diagram showing Envoy transparently signing an outbound client request with AWS SigV4 credentials before forwarding it to an AWS service and returning the response.

Sequence diagram showing Envoy transparently signing an outbound client request with AWS SigV4 credentials before forwarding it to an AWS service and returning the response.Open full screen ↗

Signature Components:

Canonical Request: Standardized format of the request
- HTTP method
- URI path
- Query string
- Headers
- Payload hash
String to Sign: String to be signed
- Algorithm: AWS4-HMAC-SHA256
- Timestamp
- Credential Scope
- Canonical Request hash

Signing Key: Signing key calculation

HMAC(HMAC(HMAC(HMAC("AWS4" + SecretKey, Date), Region), Service), "aws4_request")

Signature: Final signature
```
HMAC(SigningKey, StringToSign)
```

Integration with Istio:

AWS SDKs and the AWS CLI sign HTTPS requests using temporary credentials supplied by IRSA or EKS Pod Identity. This keeps signing associated with the workload's AWS permissions. Istio mTLS identity and AWS IAM identity are separate.

Envoy's aws_request_signing HTTP filter is an advanced alternative. It needs an Envoy build containing the extension, credentials available to the proxy container, the correct AWS service/region, and a filter match restricted to the intended AWS destination. Insert it before the router, after any header/path rewrites that affect the signature. Application-originated HTTPS is opaque to this HTTP filter: Envoy cannot add a signature inside encrypted TLS. A proxy-signing design must present HTTP to the signing proxy and originate verified TLS upstream; avoid double TLS origination or exposing unsigned HTTP beyond the intended local proxy path.

The diagram above describes this explicitly configured signing-proxy path, not a default Istio capability. An IRSA annotation on the application ServiceAccount alone does not prove that a gateway or sidecar has the credential environment and token mount it needs.

Authentication is not JWT validation:

SigV4 is an HMAC request signature, not a JWT. https://sts.amazonaws.com/.well-known/jwks is not a JWT issuer endpoint for validating AWS API signatures. Istio RequestAuthentication validates JWTs from a real OIDC issuer. A CUSTOM AuthorizationPolicy additionally requires a configured extensionProviders service implementing external authorization; it cannot validate SigV4 without that implementation. Prefer IAM-authenticated AWS endpoints or the AWS SDK for AWS API access.

Read-only verification example (AWS CLI installed in the workload, with its intended IAM role):

bash

aws sts get-caller-identity
aws s3api head-object --bucket my-bucket --key object.txt --region us-west-2

Operational considerations:

Grant the workload only the required AWS actions and resources. Avoid depending on a shared node instance role.
Confirm that the selected credential provider supports temporary credentials and refresh. Session duration is configurable, not universally one hour.
CloudTrail management events and data events have different coverage; S3 object access requires the appropriate data-event configuration.
Inspect proxy configuration to confirm filter placement. A config dump does not display the Authorization header of each live request, and unsigned curl over HTTPS is not a SigV4 test.
Measure signing/buffering/credential-fetch overhead for the actual request sizes; no fixed millisecond overhead is guaranteed.

Related Terms: AuthorizationPolicy, ServiceEntry, EnvoyFilter

References:

Sidecar

A helper container pattern deployed alongside an application container.

Istio's Sidecar:

Container name: istio-proxy
Image: istio/proxyv2
Runs Envoy Proxy
Intercepts configured traffic through init-container or Istio CNI redirection

Injection Methods:

Automatic: Namespace label
Manual: istioctl kube-inject

yaml

apiVersion: v1
kind: Namespace
metadata:
  name: example-mesh
  labels:
    istio-injection: enabled  # Automatic injection

Related Documentation: Sidecar Injection

Sidecar Resource

An Istio CRD that limits the service information Envoy receives.

Purpose:

Reduce memory usage
Shorten configuration push time
Configuration scoping; not a network security boundary

yaml

apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
  namespace: default
spec:
  egress:
  - hosts:
    - "./*"  # Same namespace only
    - "istio-system/*"

Effect:

Fewer imported services can reduce memory and configuration work; measure actual savings.

Related Documentation: Architecture - Sidecar Resource

SPIFFE (Secure Production Identity Framework for Everyone)

A standard for proving workload identity in cloud-native environments.

SPIFFE ID Format:

spiffe://trust-domain/path

Istio Example:

spiffe://cluster.local/ns/default/sa/reviews
  |         |           |     |      |    |
  |         |           |     |      |    +- ServiceAccount name
  |         |           |     |      +----- "sa" (ServiceAccount)
  |         |           |     +------------ Namespace name
  |         |           +------------------ "ns" (Namespace)
  |         +------------------------------ Trust Domain
  +---------------------------------------- Protocol

Components:

SPIFFE ID: Workload identifier
SVID (SPIFFE Verifiable Identity Document): X.509-SVID or JWT-SVID; Istio mTLS uses X.509-SVID

Related Terms: Identity, mTLS

Subset

A logical grouping of services defined in DestinationRule.

Common Uses:

By version: v1, v2, v3
By deployment stage: stable, canary, test
By region: us-west, us-east, eu-central

yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: glossary-example-6
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Related Documentation: DestinationRule - Subset Concept

V-Z

Waypoint Proxy

An optional proxy that provides L7 functionality in Ambient Mode.

Role:

Selected with namespace, Service, or Pod labels; not automatically per ServiceAccount
Based on Envoy Proxy
Dedicated to L7 traffic management functions
Works alongside ztunnel

Provided Features:

L7 routing (Path, Header-based)
Retry and Timeout
Circuit Breaker
Fault Injection
Header manipulation

Deployment Example:

yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: reviews-waypoint
  namespace: default
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

Features:

ztunnel handles only L4, waypoint handles L7
Selective use only for services that need it
More resource efficient than Sidecar (shared approach)
Selected with namespace, Service, or Pod labels; not automatically per ServiceAccount

Related Terms: Ambient Mode, ztunnel

After creating the waypoint, enroll the intended service, for example kubectl label service reviews istio.io/use-waypoint=reviews-waypoint --overwrite. Deploying a Gateway alone does not route traffic through it.

VirtualService

An Istio CRD that defines how traffic is routed within the Service Mesh.

Main Functions:

Routing based on URI, headers, query parameters
Weight-based traffic distribution
Retry and Timeout settings
Fault Injection

yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - uri:
        prefix: "/v2"
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1

Related Documentation: Gateway and VirtualService

WASM (WebAssembly)

A binary instruction format designed to run in web browsers. In Istio, it is used to extend the functionality of the Envoy proxy.

Usage in Istio:

Add custom logic as Envoy Filter
Dynamically extend functionality without redeployment
Can be written in various languages (Rust, C++, Go, etc.)
Runs safely in a sandbox environment

Major Use Cases:

Custom Authentication/Authorization: Implement complex business logic
Request/Response Transformation: Header manipulation, payload transformation
Advanced Routing: Custom routing logic
Metric Collection: Specialized telemetry

The registry URLs, digests, credentials, and pluginConfig fields below are placeholders for your own built plugin; Istio does not supply those example images or interpret plugin-specific options. A file:// module must exist inside the proxy container.

WASM Plugin Example:

yaml

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: custom-auth
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  url: oci://ghcr.io/my-org/custom-auth:v1.0.0
  phase: AUTHN
  pluginConfig:
    api_key_header: "X-API-Key"
    validate_endpoint: "https://auth.example.com/validate"

Deployment Methods:

1. Deployment via OCI Registry (Recommended)

yaml

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: rate-limiter
spec:
  url: oci://ghcr.io/my-org/rate-limit:v1.0.0
  imagePullPolicy: Always
  imagePullSecret: registry-credential

2. Deployment via HTTP URL

yaml

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: custom-filter
spec:
  url: https://example.com/filters/custom-filter.wasm
  # Add sha256: with the actual 64-character module digest before deployment

3. Local File Deployment

yaml

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: local-filter
spec:
  url: file:///etc/istio/filters/custom.wasm

WASM Development Example (Rust):

rust

use proxy_wasm::traits::*;
use proxy_wasm::types::*;

proxy_wasm::main! {{
    proxy_wasm::set_http_context(|_, _| -> Box<dyn HttpContext> {
        Box::new(CustomFilter)
    });
}}

struct CustomFilter;
impl Context for CustomFilter {}

impl HttpContext for CustomFilter {
    fn on_http_request_headers(&mut self, _: usize, _: bool) -> Action {
        // Demonstrate header mutation, not production API-key authentication.
        self.set_http_request_header("x-mesh-demo", Some("wasm"));
        Action::Continue
    }
}

Build and deployment prerequisites:

Use a Rust cdylib crate with a compatible proxy-wasm dependency and a locked dependency version. The callback above follows the official Rust SDK example. Install the wasm32-unknown-unknown target, build the module, and package the resulting .wasm in a supported OCI Wasm image before referencing it from WasmPlugin. A generic docker build with no Dockerfile does not perform that packaging.

bash

rustup target add wasm32-unknown-unknown
cargo build --target wasm32-unknown-unknown --release

Measure startup time, memory, and per-request overhead for the specific plugin. Wasm executes in a runtime sandbox inside the proxy process; it is not a separate process or an unconditional security/performance guarantee.

Ambient Mode Support:

yaml

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: waypoint-filter
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: reviews-waypoint
  url: oci://ghcr.io/filters/custom:latest
  phase: AUTHN

Debugging:

bash

# Check WASM plugin status
kubectl get wasmplugin -A

# Check WASM-related logs in Envoy logs
kubectl logs <pod-name> -c istio-proxy | grep wasm

# Check WASM module load
istioctl proxy-config all <pod-name> -o json | jq '.. | objects | select(has("@type")) | select(.["@type"] | test("wasm"; "i"))'

Security Considerations:

Sandbox Isolation: Runtime sandbox inside Envoy; review plugin trust and resource use
Resource Limits: CPU and memory limits can be configured
Integrity Verification: SHA256 checks content; it does not authenticate the publisher
Least Privilege: Grant only necessary permissions

Advantages:

High performance (native code level)
Safe sandbox execution
Updateable without redeployment
Multi-language support
Standard OCI image format

Limitations:

Some system calls restricted
Limited file I/O
Network calls only through Envoy API

Related Terms: Envoy, Waypoint Proxy, Ambient Mode

References:

xDS (Discovery Service)

A set of APIs for dynamic configuration of Envoy Proxy.

Meaning of "xDS":

x: Variable representing various types
DS: Discovery Service

xDS API Types:

API	Name	Role
LDS	Listener Discovery Service	Listening ports and filter chains
RDS	Route Discovery Service	HTTP routing rules
CDS	Cluster Discovery Service	Upstream service configuration
EDS	Endpoint Discovery Service	Actual pod IP list
SDS	Secret Discovery Service	TLS certificates and keys

Communication Method:

Protocol: gRPC
Port: 15012 (Istiod)
Bidirectional streaming

Order:

Agent bootstraps identity -> Envoy subscribes to ADS resources
Istiod pushes LDS/CDS/EDS/RDS updates; local agent serves SDS certificates

Related Documentation: Architecture - xDS API Communication

Zone

Represents a Kubernetes Availability Zone.

Label Format:

yaml

topology.kubernetes.io/zone: us-west-1a

Usage in Istio:

Locality-aware Load Balancing
Zone Aware Routing
Same Zone priority routing

Related Terms: Locality-aware Load Balancing

ztunnel (Zero Trust Tunnel)

A core component of Ambient Mode, a lightweight L4 proxy running at the node level.

Role:

Deployed as DaemonSet on each node
Handles L4 traffic for all pods
Provides service mesh functionality without Sidecar
Integrates with CNI plugin

Provided Features:

mTLS: Automatic encryption/decryption
L4 Telemetry: Metric collection
Identity: Service Account-based authentication
L4 Load Balancing: Basic load balancing

Technical Features:

Written in Rust (high performance)
Istio CNI-managed traffic redirection
No Init Container required
Shared L4 proxy resources; size from measured node workload

Deployment Example:

bash

# Use the reviewed istioctl version and the complete ambient installation profile
istioctl install --set profile=ambient
kubectl rollout status daemonset/ztunnel -n istio-system

For an existing sidecar workload, remove injection/revision labels and restart pods to remove the sidecars before ambient enrollment; a new sidecar-free workload does not need a restart.

Namespace Activation:

bash

# Enable Ambient Mode
kubectl label namespace default istio-injection- istio.io/rev-
kubectl label namespace default istio.io/dataplane-mode=ambient --overwrite

Advantages:

Potential memory savings depend on node/workload and waypoint capacity
No pod restart required
Application transparency
Minimized initial latency

Limitations:

Waypoint Proxy required for L7 features
Requires a supported Linux Kubernetes platform, primary CNI, and Istio CNI prerequisites

Related Terms: Ambient Mode, Waypoint Proxy, eBPF

References

Official Documentation

Last Updated: September 13, 2026

Traffic Management

Security

Observability

Resilience

Advanced

Comparison Guide

ArgoCD

Metrics

Logging

Tracing

Alerting

Observability End-to-End Labs

Istio Glossary ​

Table of Contents ​

A-C ​

AuthorizationPolicy ​

Control Plane ​

Ambient Mode ​

Certificate Authority (CA) ​

Circuit Breaker ​

Citadel ​

CDS (Cluster Discovery Service) ​

D-F ​

Data Plane ​

DestinationRule ​

eBPF (Extended Berkeley Packet Filter) ​

EDS (Endpoint Discovery Service) ​

Envoy Proxy ​

G-I ​

Galley ​

Gateway ​

gRPC ​

Identity ​

iptables ​

Istiod ​

J-L ​

LDS (Listener Discovery Service) ​

Locality-aware Load Balancing ​

M-O ​

Mixer ​

mTLS (Mutual TLS) ​

Outlier Detection ​

P-R ​

Downstream ​

1. Sidecar Mode - Outbound Request ​

2. Ingress Gateway - External Request ​

Upstream ​

1. Cluster (Upstream Group) ​

2. Endpoint (Actual Upstream Instance) ​

Scenario 1: Service A -> Service B Call ​

Scenario 2: Ingress Gateway ​

Pilot ​

RDS (Route Discovery Service) ​

Rate Limiting ​

S-U ​

SDS (Secret Discovery Service) ​

Service Entry ​

Service Mesh ​

SigV4 (AWS Signature Version 4) ​

Sidecar ​

Sidecar Resource ​

SPIFFE (Secure Production Identity Framework for Everyone) ​

Istio Glossary

Table of Contents

A-C

AuthorizationPolicy

Control Plane

Ambient Mode

Certificate Authority (CA)

Circuit Breaker

Citadel

CDS (Cluster Discovery Service)

D-F

Data Plane

DestinationRule

eBPF (Extended Berkeley Packet Filter)

EDS (Endpoint Discovery Service)

Envoy Proxy

G-I

Galley

Gateway

gRPC

Identity

iptables

Istiod

J-L

LDS (Listener Discovery Service)

Locality-aware Load Balancing

M-O

Mixer

mTLS (Mutual TLS)

Outlier Detection

P-R

Downstream

1. Sidecar Mode - Outbound Request

2. Ingress Gateway - External Request

Upstream

1. Cluster (Upstream Group)

2. Endpoint (Actual Upstream Instance)

Scenario 1: Service A -> Service B Call

Scenario 2: Ingress Gateway

Pilot

RDS (Route Discovery Service)

Rate Limiting

S-U

SDS (Secret Discovery Service)

Service Entry

Service Mesh

SigV4 (AWS Signature Version 4)

Sidecar

Sidecar Resource

SPIFFE (Secure Production Identity Framework for Everyone)