Istio / Security

Istio 1.32 is now available! Click here to learn more
Breaking down a monolithic application into atomic services offers various benefits, including better agility, better scalability and better ability to reuse services. However, microservices also have particular security needs:
Istio Security provides a comprehensive security solution to solve these issues. This page gives an overview on how you can use Istio security features to secure your services, wherever you run them. In particular, Istio security mitigates both insider and external threats against your data, endpoints, communication, and platform.
The Istio security features provide strong identity, powerful policy, transparent TLS encryption, and authentication, authorization and audit (AAA) tools to protect your services and data. The goals of Istio security are:
Visit our mutual TLS Migration docs to start using Istio security features with your deployed services. Visit our Security Tasks for detailed instructions to use the security features.
Security in Istio involves multiple components:
A Certificate Authority (CA) for key and certificate management
The configuration API server distributes to the proxies:
Sidecar and perimeter proxies work as Policy Enforcement Points (PEPs) to secure communication between clients and servers.
A set of Envoy proxy extensions to manage telemetry and auditing
The control plane handles configuration from the API server and configures the PEPs in the data plane. The PEPs are implemented using Envoy. The following diagram shows the architecture.
In the following sections, we introduce the Istio security features in detail.
Identity is a fundamental concept of any security infrastructure. At the beginning of a workload-to-workload communication, the two parties must exchange credentials with their identity information for mutual authentication purposes. On the client side, the server’s identity is checked against the secure naming information to see if it is an authorized runner of the workload. On the server side, the server can determine what information the client can access based on the authorization policies, audit who accessed what at what time, charge clients based on the workloads they used, and reject any clients who failed to pay their bill from accessing the workloads.
The Istio identity model uses the first-class service identity to determine the identity of a request’s origin. This model allows for great flexibility and granularity for service identities to represent a human user, an individual workload, or a group of workloads. On platforms without a service identity, Istio can use other identities that can group workload instances, such as service names.
The following list shows examples of service identities that you can use on different platforms:
Istio securely provisions strong identities to every workload with X.509 certificates. Istio agents, running alongside each Envoy proxy, work together with istiod to automate key and certificate rotation at scale. The following diagram shows the identity provisioning flow.
Istio provisions keys and certificates through the following flow:
ClusterTrustBundle is a Kubernetes Custom Resource Definition (CRD) introduced to help manage trusted Certificate Authority (CA) bundles cluster-wide. It is primarily used to distribute and trust public X.509 certificates across the entire cluster. This concept is especially useful in environments where components and workloads need to validate TLS certificates signed by non-standard or private CAs. Istio has added experimental support for this in recent versions, making it easier to manage trust for services.
To use ClusterTrustBundle in Istio, you must enable it by setting a flag during installation. Here’s how:
Ensure your Kubernetes cluster is version 1.27 or later and that ClusterTrustBundles are enabled.
Add this to your istio configuration
You create ClusterTrustBundles as Kubernetes resources, for example:
Once created, the Istio control plane will use these for validating certificates in secure communications, like mutual TLS (mTLS).
Istio provides two types of authentication:
Peer authentication: used for service-to-service authentication to verify the client making the connection. Istio offers mutual TLS as a full stack solution for transport authentication, which can be enabled without requiring service code changes. This solution:
Request authentication: Used for end-user authentication to verify the credential attached to the request. Istio enables request-level authentication with JSON Web Token (JWT) validation and a streamlined developer experience using a custom authentication provider or any OpenID Connect providers, for example:
In all cases, Istio stores the authentication policies in the Istio config store via a custom Kubernetes API. Istiod keeps them up-to-date for each proxy, along with the keys where appropriate. Additionally, Istio supports authentication in permissive mode to help you understand how a policy change can affect your security posture before it is enforced.
Istio tunnels service-to-service communication through the client- and server-side PEPs, which are implemented as Envoy proxies. When a workload sends a request to another workload using mutual TLS authentication, the request is handled as follows:
Istio configures TLSv1_2 as the minimum TLS version for both client and server with the following cipher suites:
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
Istio mutual TLS has a permissive mode, which allows a service to accept both plaintext traffic and mutual TLS traffic at the same time. This feature greatly improves the mutual TLS onboarding experience.
Many non-Istio clients communicating with a non-Istio server presents a problem for an operator who wants to migrate that server to Istio with mutual TLS enabled. Commonly, the operator cannot install an Istio sidecar for all clients at