--- title: "Istio Security" source: "https://www.tigera.io/learn/guides/istio/istio-security/" description: "Istio secures microservices in cloud-native applications, particularly on Kubernetes. It provides security features to control, observe, and manage communications between services. Using Istio, organizations can protect service-to-service traffic, enforce fine-grained access controls, and simplify compliance efforts in distributed environments." --- ## Guides: Istio Security # How Istio Security Works and Addressing Critical Security Gaps - [Istio](https://www.tigera.io/learn/guides/istio/) - [Istio Network Policy](https://www.tigera.io/learn/guides/istio/istio-network-policy/) - [Istio Gateway](https://www.tigera.io/learn/guides/istio/istio-gateway/) - [Istio Dashboard](https://www.tigera.io/learn/guides/istio/istio-dashboard/) - [Istio vs Linkerd](https://www.tigera.io/learn/guides/istio/istio-vs-linkerd/) - [Istio Multi Cluster](https://www.tigera.io/learn/guides/istio/istio-multi-cluster/) - [Istio Kubernetes](https://www.tigera.io/learn/guides/istio/istio-kubernetes/) - [Istio Proxy](https://www.tigera.io/learn/guides/istio/istio-proxy/) - [Istio Security](https://www.tigera.io/learn/guides/istio/istio-security/) - [Istio Service Mesh](https://www.tigera.io/learn/guides/istio/istio-service-mesh/) - [Istio Ingress](https://www.tigera.io/learn/guides/istio/istio-ingress/) - [Istio Ambient](https://www.tigera.io/learn/guides/istio/istio-ambient/) ## What Is Istio Security? [Istio](https://www.tigera.io/learn/guides/istio/) secures microservices in cloud-native applications, particularly on Kubernetes. It provides security features to control, observe, and manage communications between services. Using Istio, organizations can protect service-to-service traffic, enforce fine-grained access controls, and simplify compliance efforts in distributed environments. Security in Istio covers authentication, authorization, confidentiality, and integrity of data exchanged between services. The platform integrates transparent policy enforcement and traffic encryption into the service mesh. These controls are centrally managed but distributed across the mesh, offering uniform policy management and high performance. Istio eliminates the need for applications to implement their own security mechanisms, reducing the risk of inconsistencies or errors. Its security features help protect against man-in-the-middle attacks, unauthorized access, and lateral movement within compromised environments, making it critical for securing modern, interconnected applications. **In this article:** - Core Components of Istio’s Security Architecture - Tutorial: Configuring Istio Authorization Policy - Istio Security Challenges and Gaps - Istio Security vs. Kubernetes Security Responsibilities - Closing the Gaps: Complementary Controls Istio Doesn’t Provide ## Core Components of Istio’s Security Architecture ### Certificate Management Certificate management in Istio is managed primarily by the Citadel component, which acts as a certificate authority for issuing and rotating certificates automatically throughout the service mesh. Each workload and service is assigned a unique identity in the form of an X.509 certificate, enabling strong mutual authentication. This automated certificate management simplifies lifecycle handling and reduces operational overhead compared to manual secret provisioning. Regular certificate rotation in Istio minimizes the attack surface by ensuring that the window in which a compromised certificate can be abused is short. Certificates can be rolled over without disruption to the application, maintaining secure connections at all times. ### Authentication Istio supports both peer authentication and request authentication to ensure only valid identities can access services in the mesh. Peer authentication establishes trust between services at the transport layer using mutual TLS (mTLS). By requiring both ends of a communication channel to present valid certificates, Istio prevents impersonation and unauthorized connections. Request authentication focuses on verifying the identity of end-users, typically using JWT tokens or similar credentials. Istio can enforce authentication policies selectively on services or entire namespaces, ensuring only requests with valid and verifiable credentials are processed. This dual approach allows granular control over who (or what) can connect to and request resources from your workloads. ### Authorization Authorization in Istio uses a policy-driven model to define which identities have access to specific resources. Policies can be written as allow or deny rules that match on attributes like source workload, destination, HTTP method, or paths. The policy engine is capable of enforcing simple allowlists as well as more complex, conditional logic for highly specific access scenarios. With Istio, authorization policies can be applied at various scopes, including mesh-wide, namespace, or per-workload, providing flexibility in how security rules are structured. This enables organizations to build layered defenses, limiting the blast radius of potential breaches and tightly controlling access to sensitive components. Istio’s API-driven approach also makes it easy to integrate with broader enterprise security policies or identity providers. ### TLS Configuration Istio enforces encrypted communication between workloads using mutual TLS. mTLS encrypts data in transit and authenticates both client and server, preventing eavesdropping and unauthorized connections. Istio allows flexible, incremental adoption of mTLS—services can be migrated from plaintext to encrypted communication with minimal disruption. Fine-grained mTLS configuration lets operators define which namespaces or workloads require strict encryption, and under what circumstances. Automated certificate distribution and rotation ensure secure key management. When properly configured, Istio’s TLS capabilities protect against common network-layer attacks and help satisfy regulatory or compliance requirements for data protection. ## Tutorial: Configuring Istio Authorization Policy Istio Authorization Policy enables fine-grained access control to workloads in a mesh by defining who can access what under which conditions. This tutorial demonstrates how to configure basic ALLOW, DENY, AUDIT, and CUSTOM actions using AuthorizationPolicy resources. ### Creating an Allow Policy To allow access to specific workloads based on service accounts or namespaces, you can define an ALLOW policy. In the example below, requests from either the sleep service account in the default namespace or any workload in the test namespace are allowed to access a workload in the foo namespace if they: - Use the GET method for paths prefixed with /info, or - Use the POST method for the exact /data path Additionally, requests must include a valid JWT token issued by https://accounts.google.com: ``` `apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: httpbin namespace: foo spec: action: ALLOW rules: - from: - source: principals: ["cluster.local/ns/default/sa/sleep"] - source: namespaces: ["test"] to: - operation: methods: ["GET"] paths: ["/info*"] - operation: methods: ["POST"] paths: ["/data"] when: - key: request.auth.claims[iss] values: ["https://accounts.google.com"]` ``` Store above code in a file called google-jwt.yaml and apply it using the following command: ``` `kubectl apply -f google-jwt.yaml` ``` ![Output of applying the JWT authorization policy](https://www.tigera.io/app/uploads/2026/10/istio-security-tutorial-01.jpg) Any requests not matching this policy will be denied by default. ### Creating Deny Policies To explicitly block certain requests, use the DENY action. The following example blocks any POST requests originating from the dev namespace to workloads in the foo namespace: ``` `apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: deny-dev-post namespace: foo spec: action: DENY rules: - from: - source: namespaces: ["dev"] to: - operation: methods: ["POST"]` ``` Let’s store the above code in deny-policy.yaml. You can apply this policy using the following code: ``` `kubectl apply -f deny-policy.yaml` ``` ![Output of applying the deny policy for POST requests](https://www.tigera.io/app/uploads/2026/10/istio-security-tutorial-02.jpg) For TCP traffic, make sure to scope deny rules using the ports field. The following example denies all POST requests on port 8080, affecting both HTTP and TCP traffic: ``` `apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: deny-post-8080 namespace: foo spec: action: DENY rules: - to: - operation: methods: ["POST"] ports: ["8080"]` ``` Let’s store if deny-port.yaml and we can apply it using the following command: ``` `kubectl apply -f deny-port.yaml` ``` ![Output of applying the deny policy for port 8080](https://www.tigera.io/app/uploads/2026/10/istio-security-tutorial-03.jpg) ### Auditing Requests The AUDIT action allows you to log request attempts without affecting access. Use this to monitor policy effects before enforcing them. The example below audits any GET requests to paths starting with /user/profile/ for workloads labeled app: myapi in the ns1 namespace: ``` `apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: namespace: ns1 name: audit-get-profile spec: selector: matchLabels: app: myapi action: AUDIT rules: - to: - operation: methods: ["GET"] paths: ["/user/profile/*"]` ``` Store above code in a file called audit.yaml and apply it using the following command: ![Output of applying the audit policy](https://www.tigera.io/app/uploads/2026/10/istio-security-tutorial-04.jpg) Auditing requires a separate plugin to be configured; without it, audit decisions are recorded internally but not processed. ### Using Custom External Authorization With the CUSTOM action, you can integrate external systems for decision-making. The example below delegates all requests with path prefix /admin/ on the ingress gateway to a custom provider called my-custom-authz: ``` `apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: ext-authz namespace: istio-system spec: selector: matchLabels: app: istio-ingressgateway action: CUSTOM provider: name: "my-custom-authz" rules: - to: - operation: paths: ["/admin/*"]` ``` Please store the above code as custom-external.yaml. You can apply it using the following command: ``` `kubectl apply -f custom-external.yaml` ``` ![Output of applying the CUSTOM external authorization policy](https://www.tigera.io/app/uploads/2026/10/istio-security-tutorial-05.jpg) This approach is useful when integrating with external authorization services that implement enterprise-specific policies. ### Testing and Validation with Dry Run You can test policies using the istio.io/dry-run annotation. This prevents the policy from affecting traffic while recording what would have been denied. The following example tests a deny policy without enforcing it: ``` `apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: dry-run-example annotations: "istio.io/dry-run": "true" spec: selector: matchLabels: app: httpbin action: DENY rules: - to: - operation: paths: ["/headers"]` ``` This helps identify misconfigurations and unintended denials before rollout. Store the above as dry-run.yaml and execute it using the following command: ``` `kubectl apply -f dry-run.yaml` ``` ![Output of applying the dry-run authorization policy](https://www.tigera.io/app/uploads/2026/10/istio-security-tutorial-06.jpg) ## Istio Security Challenges and Gaps While Istio provides a strong foundation for securing service-to-service communication, it is not a complete security solution on its own. Several challenges and potential gaps can arise due to misconfigurations, misuse, or over-reliance on Istio as the sole security layer. ### Sidecar Injection Bypass Istio, outside of ambient mode, relies on sidecar proxies to enforce security policies and intercept traffic. If sidecars are not properly injected into workloads, either due to disabled namespace or pod-level labels, application traffic may bypass the service mesh entirely. This creates blind spots where policies such as mTLS, authentication, or authorization are not enforced. To mitigate this, platform teams should restrict access to Kubernetes resources that control injection behavior and enforce compliance using policy tools like OPA Gatekeeper or Admission Webhooks. ### Traffic Redirection Evasion Istio uses iptables rules to redirect traffic through the sidecar. Malicious or misinformed teams can manipulate pod annotations, misuse special user IDs (such as UID 1337 used by Istio), or exploit Linux capabilities like NET_ADMIN to override or remove these rules. These actions can allow unauthorized traffic to flow uninspected. Preventive strategies include enforcing UID restrictions, validating container image configurations, and adopting Istio CNI to remove the need for elevated privileges. ### Weak Inbound And Outbound Controls Improperly configured PeerAuthentication policies can permit plaintext traffic within the mesh by setting permissive modes, weakening the guarantees of mutual TLS. Similarly, outbound traffic can be routed outside the mesh using ServiceEntry or ExternalName configurations, allowing workloads to reach external endpoints without passing through the egress gateway. These patterns bypass centralized control and monitoring. To reduce this risk, organizations should restrict access to these resource types and continuously audit configurations. ### Configuration Manipulation Risks Istio allows fine-grained control over its behavior through custom resources like Sidecar and EnvoyFilter. If application teams can override global policies, for example, by setting outboundTrafficPolicy: ALLOW_ANY, they may unintentionally (or maliciously) expose services to untrusted destinations. EnvoyFilter misuse can introduce conflicting behavior or denial-of-service conditions. Controlling access to these resources and maintaining centralized review processes are essential to avoid inconsistent or insecure mesh behavior. ### Istio as Part of a Broader Security Strategy Istio strengthens microservice security through identity-based access, encryption, and traffic policy enforcement. However, it is not a replacement for traditional security tools like firewalls, intrusion detection systems, or secure container runtimes. As Istio operates at the network layer, it must be complemented by host-level and infrastructure security controls. Adopting a layered defense model that combines Istio with CNI plugins, secure supply chain practices, and observability tools ensures a more robust security posture. ## Istio Security vs. Kubernetes Security Responsibilities Istio and Kubernetes operate at different layers of the security stack and complement each other rather than overlapping. Kubernetes handles security at the infrastructure and workload orchestration levels (Layer 3/4), while Istio provides fine-grained control over service-to-service communications at the application level (Layer 7): - **NetworkPolicy vs. AuthorizationPolicy:** Kubernetes NetworkPolicy controls traffic flow between pods based on IP addresses and ports. It operates at the network layer and lacks visibility into the identity of the service or user making a request. Istio’s AuthorizationPolicy, on the other hand, supports identity-based access using service accounts and JWT claims, allowing policies to be expressed in terms of “who” is calling “what” service under “which” conditions. - **Layer 3/4 vs. Layer 7 enforcement:** Kubernetes enforces boundaries using source/destination IPs and ports, suitable for coarse-grained segmentation. Istio can enforce HTTP method-based rules, header checks, and path-specific restrictions, enabling microsegmentation at a much finer granularity. This allows for policies such as “allow POST to /submit only from frontend service authenticated via Google JWT,” which Kubernetes cannot express. - **Runtime security outside Istio’s scope:** Istio does not monitor what happens inside a container or detect malicious processes. It cannot detect threats like file system access anomalies, memory exploits, or privilege escalations. These are addressed by runtime security tools (e.g., Falco or eBPF-based systems) that monitor kernel-level behavior, often deployed alongside container security platforms. - **Workload-level vs. pod-level identity:** Istio assigns identities to workloads using SPIFFE-compatible X.509 certificates, typically derived from Kubernetes service accounts. However, this identity is at the pod or workload level and does not represent the actual Unix process or user inside the container. This gap means if a pod is compromised, Istio assumes any connection from it is legitimate. Bridging this with runtime attestation or process-level identity (such as those provided by eBPF-based systems) is necessary for defense in depth. In practice, Istio should be treated as a policy enforcement layer that complements, not replaces, Kubernetes security primitives, runtime protection, and infrastructure-level controls. ## Closing the Gaps: Complementary Controls Istio Doesn’t Provide ### Cluster-Level eBPF Observability and Threat Detection Istio controls and observes east‑west traffic *inside* the mesh, but it does not monitor host‑level behavior or kernel interactions. Tools based on eBPF (extended Berkeley Packet Filter) run at the kernel level and can observe system calls, process activity, container boundary events, and networking beyond the service mesh proxies. Cluster‑level eBPF observability lets you detect threat patterns that Istio cannot see, such as unusual process behavior, unauthorized network connections initiated from compromised containers, or in‑memory exploitation techniques. When paired with threat‑detection rules, eBPF can alert or block suspicious activity without needing agents inside every container. ### Network-Level Microsegmentation While Istio offers microsegmentation at the application level (L7) using service identities and policies, it does not enforce segmentation at the *network* layer (L3/L4) outside the mesh boundary or in non‑HTTP/TCP protocols. Traditional network microsegmentation (implemented via Kubernetes NetworkPolicies, Cilium, or cloud provider security groups) restricts traffic based on IP, ports, and protocols across cluster nodes and external systems. Network‑level segmentation reduces the attack surface by preventing unwanted lateral movement even before traffic reaches the mesh. In insecure or mixed environments (where parts of the workload cannot run Istio sidecars), network microsegmentation ensures that only explicitly permitted flows are allowed, providing defense in depth. ### Compliance Reporting Istio enforces policies and generates telemetry, but it does *not* provide out‑of‑the‑box compliance reporting aligned to standards such as PCI DSS, HIPAA, or SOC 2. Compliance reporting requires aggregating logs, audit trails, user‑access data, and change history into structured reports that map to control requirements. Integrating Istio with centralized logging and compliance platforms (e.g., SIEM systems) enables automated evidence collection, tracking policy violations over time, and producing auditable reports that demonstrate adherence to regulatory controls. This ensures that mesh security activities contribute to organizational compliance, not just enforcement. ### Runtime Anomaly Detection Istio does not inspect container internals or detect anomalies in application behavior at runtime. It focuses on network traffic patterns *between* services, not the *behavior within* a workload. Runtime anomaly detection identifies deviations from normal execution, such as unusual file access, unexpected memory use, privilege escalation attempts, or unauthorized binary execution. Tools like runtime threat detection or eBPF‑based monitors observe the operating system, container runtime, and application behavior in real time. They can generate alerts or enforce policies when abnormal behavior is detected, stopping exploitation attempts that mesh traffic controls would not catch. ### East-West Traffic Visibility Outside the Mesh Istio provides rich insight into traffic that flows *through the mesh sidecars*, including metrics, traces, and logs. However, it does not inherently capture or control east‑west traffic that bypasses the mesh, whether due to workloads without sidecars, external services, host network traffic, or non‑mesh communication paths. True east‑west visibility requires tools that instrument the cluster network interfaces or hypervisor level (e.g., cloud VPC flow logs, service‑aware packet inspection). These tools reveal flows between all endpoints, enabling detection of shadow services, misconfigured hosts, or lateral movement that does not traverse Istio proxies. ### Multi-Cluster Security Posture Management Istio supports multi‑cluster meshes, but maintaining *consistent security posture* across clusters is not automatic. Each cluster may have distinct control plane versions, policies, identity authorities, or ingress/egress configurations. Istio does not provide a unified dashboard for cross‑cluster security posture, drift detection, or policy compliance across deployments. Multi‑cluster security posture management tools unify policy definitions, detect configuration drift, enforce common baselines, and visualize risk across clusters and clouds. These systems ensure that security policies, audit trails, and compliance standards are applied uniformly, reducing gaps that arise from decentralized management or heterogeneous environments. ## Closing Istio’s Security Gaps with Tigera’s Workload-Level Protection While an **Istio Ingress Gateway** provides robust Layer 7 control at the edge, a truly production-grade **microservices architecture** requires a security posture that extends deep into the networking layer. This is where **Calico** provides the critical foundation that Istio needs to deliver a complete, zero-trust environment. ### Bridging the Gap Between Layer 3 and Layer 7 Istio excels at application-level traffic management, but it relies on the underlying Container Network Interface (CNI) to handle the actual plumbing of the cluster. Calico complements Istio by providing: - **Unified Policy Enforcement:** Calico allows you to define security policies that span from the network layer (IPs and ports) to the service level (identities and paths). This “defense-in-depth” approach ensures that even if a high-level proxy is bypassed, your north-south and east-west traffic remains protected by kernel-level enforcement. - **High-Performance Load Balancing:** While Istio handles application-level load balancing, Calico optimizes the data plane using eBPF. This ensures that packets reach the Istio Ingress Gateway with minimum latency and maximum throughput, reducing the “sidecar tax” often associated with service meshes. - Istio Ambient Mode Support: As discussed in our tutorials, managing sidecars can be complex. Calico is uniquely designed to support Istio Ambient Mode, providing a sidecarless experience that simplifies operational overhead while maintaining the granular security Istio is known for. - **Advanced Egress Control:** Istio manages service-to-service communication, but Calico provides the DNS-based policy enforcement needed to secure traffic leaving the cluster to external APIs or legacy databases, preventing data exfiltration at the source. ### Full-Stack Observability By combining Calico with Istio, platform teams gain a “single pane of glass” for troubleshooting. While Istio provides traces and application metrics, Calico provides the flow logs and raw network data needed to identify if a performance bottleneck is occurring at the application code level or within the Kubernetes network fabric itself. ### Next Steps & Deep Dives To learn more about optimizing your Istio and Calico environment, explore these resources: - **Sidecarless Efficiency:** Read [An In-Depth Look at Istio Ambient Mode with Calico](https://www.tigera.io/blog/an-in-depth-look-at-istio-ambient-mode-with-calico/) to see how to run a mesh without the overhead. - **Security Architecture:** Explore our guide on [Service Mesh with eBPF](https://www.tigera.io/learn/guides/ebpf/ebpf-service-mesh/) to understand how the underlying data plane impacts your security.