Istio Security
What is Istio Security?
Istio SecurityThe security feature set of the Istio service mesh: workload identity via SPIFFE, automatic mutual TLS, and AuthorizationPolicy/RequestAuthentication for fine-grained access control.
Istio Security is the security subsystem of the Istio service mesh. The Istio control plane (istiod) issues SPIFFE-based X.509 identities to every workload and configures Envoy sidecars to establish mutual TLS between pods, eliminating plaintext east-west traffic. PeerAuthentication policies enforce STRICT or PERMISSIVE mTLS at namespace or workload scope. AuthorizationPolicy provides allow/deny rules over source identities, hosts, paths, methods, and conditions; RequestAuthentication validates JWTs against issuers. Operational risks include misconfigured PERMISSIVE mode that allows plaintext, overly broad allow-policies, and unpatched istiod CVEs (such as CVE-2024-3727). Best practice combines STRICT mTLS, default-deny AuthorizationPolicy, and audit of policy changes.
● Examples
- 01
PeerAuthentication mtls.mode=STRICT in namespace prod to require mTLS for all pods.
- 02
AuthorizationPolicy that denies all by default and explicitly allows reviews-service to call ratings-service.
● Frequently asked questions
What is Istio Security?
The security feature set of the Istio service mesh: workload identity via SPIFFE, automatic mutual TLS, and AuthorizationPolicy/RequestAuthentication for fine-grained access control. It belongs to the Cloud Security category of cybersecurity.
What does Istio Security mean?
The security feature set of the Istio service mesh: workload identity via SPIFFE, automatic mutual TLS, and AuthorizationPolicy/RequestAuthentication for fine-grained access control.
How does Istio Security work?
Istio Security is the security subsystem of the Istio service mesh. The Istio control plane (istiod) issues SPIFFE-based X.509 identities to every workload and configures Envoy sidecars to establish mutual TLS between pods, eliminating plaintext east-west traffic. PeerAuthentication policies enforce STRICT or PERMISSIVE mTLS at namespace or workload scope. AuthorizationPolicy provides allow/deny rules over source identities, hosts, paths, methods, and conditions; RequestAuthentication validates JWTs against issuers. Operational risks include misconfigured PERMISSIVE mode that allows plaintext, overly broad allow-policies, and unpatched istiod CVEs (such as CVE-2024-3727). Best practice combines STRICT mTLS, default-deny AuthorizationPolicy, and audit of policy changes.
How do you defend against Istio Security?
Defences for Istio Security typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Istio Security?
Common alternative names include: Istio mTLS, Istio AuthorizationPolicy.
● Related terms
- cloud-security№ 1014
Service Mesh Security
The set of identity, encryption, and authorization controls a service mesh provides to secure service-to-service traffic in a cloud-native environment.
- cloud-security№ 1078
SPIFFE
An open standard for assigning cryptographic, portable identities to software workloads using URI-based SPIFFE IDs and short-lived X.509 or JWT SVIDs.
- cloud-security№ 1248
Workload Identity
A cryptographic identity assigned to a service, container, or function so it can authenticate to other systems without long-lived shared secrets.
- network-security№ 1262
Zero Trust Network
A network architecture that never trusts users, devices, or services by default and enforces continuous, identity-aware verification of every connection.
- cloud-security№ 600
Kubernetes Security
The protection of a Kubernetes cluster — its API server, control plane, nodes, workloads, and network — from misconfiguration, compromise, and lateral movement.
● See also
- № 1079SPIRE Runtime