Service Mesh Security

Adopting the cloud can put strains on DevOps teams. Developers leverage microservices to architect for portability, meanwhile operators are managing extremely large hybrid and multi-cloud deployments.

A Service Mesh helps reduce the complexity of these deployments, and eases the strain on development teams. It is usually an open source component that layers transparently onto existing distributed applications. It is also a platform, including APIs that let it integrate into any logging platform, telemetry, or policy system.

Well-known Service Mesh solutions of the Cloud Native Computing Foundation (CNCF) are:

We'll focus on the security of Istio, because this service mesh is closely integrated into the dominating Kubernetes orchestration component.

Istio Security Overview

An Istio service mesh is logically split into a data plane and a control plane:


Istio uses an extended version of the Envoy proxy. Envoy is a high-performance proxy developed in C++ to mediate all inbound and outbound traffic for all services in the service mesh. Istio leverages Envoy's many built-in features:

Envoy is deployed as a sidecar to the relevant service in the same Kubernetes pod. This deployment allows Istio to extract a wealth of signals about traffic behavior as attributes. Istio can, in turn, use these attributes in Mixer to enforce policy decisions, and send them to monitoring systems to provide information about the behavior of the entire mesh. The sidecar proxy model also allows adding Istio capabilities to an existing deployment with no need to rearchitect or rewrite code.


Mixer is a platform-independent component. Mixer enforces access control and usage policies across the service mesh, and collects telemetry data from the Envoy proxy and other services. The proxy extracts request level attributes, and sends them to Mixer for evaluation.

Mixer includes a flexible plugin model. This model enables Istio to interface with a variety of host environments and infrastructure backends. Thus, Istio abstracts the Envoy proxy and Istio-managed services from these details.


Pilot provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing (e.g., A/B tests, canary rollouts, etc.), and resiliency (timeouts, retries, circuit breakers, etc.).

Pilot converts high level routing rules that control traffic behavior into Envoy-specific configurations, and propagates them to the sidecars at runtime. Pilot abstracts platform-specific service discovery mechanisms and synthesizes them into a standard format that any sidecar conforming with the Envoy data plane APIs can consume. This loose coupling allows Istio to run on multiple environments such as Kubernetes, Consul, or Nomad, while maintaining the same operator interface for traffic management.


Citadel enables strong service-to-service and end-user authentication with built-in identity and credential management. Citadel can be used to upgrade unencrypted traffic in the service mesh. Using Citadel, operators can enforce policies based on service identity rather than on relatively unstable layer 3 or layer 4 network identifiers. Istio's authorization feature can be used to control who can access services.


Galley is Istio's configuration validation, ingestion, processing and distribution component. It is responsible for insulating the rest of the Istio components from the details of obtaining user configuration from the underlying platform (usually Kubernetes).

Security Architecture

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. The following diagram depicts the core Istio Security components on external and internal interfaces. Istio Security mitigates both insider and external threats against 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 services and data. The goals of Istio security are:

Security in Istio involves multiple components:

The following diagram shows the interactions between these security components:

Identity is a fundamental concept of any security infrastructure. At the beginning of a service-to-service 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 service. 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 services they used, and reject any clients who failed to pay their bill from accessing the services.

In the Istio identity model, Istio uses a service identity to determine the identity of a service. This gives great flexibility and granularity to represent a human user, an individual service, or a group of services. On platforms that do not have such identity available, Istio can use other identities that can group service instances, such as service names.

Istio service identities on different platforms:


Istio provides two types of authentication:

In both cases, Istio stores the authentication policies in the Istio config store via a custom Kubernetes API. Pilot keeps them up-to-date for each proxy, along with the keys where appropriate. Additionally, Istio supports authentication in permissive mode to help understand how a policy change can affect the security posture before it becomes effective.

How to authenticate on Kubernetes

How to authenticate on-premises


Although it's strongly recommended to using the Istio authorization mechanisms, Istio is capable of working with 3rd party authentication & authorization plugins via the Mixer component.

Istio's RBAC-based authorization feature provides namespace-level, service-level, and method-level access control for services in an Istio service mesh. Its featured are:

Pilot watches for changes to Istio authorization policies. It fetches the updated authorization policies if it sees any changes. Pilot distributes Istio authorization policies to the Envoy proxies that are co-located with the service instances.

Each Envoy proxy runs an authorization engine that authorizes requests at runtime. When a request comes to the proxy, the authorization engine evaluates the request context against the current authorization policies, and returns the authorization result, ALLOW or DENY.

Policies and Telemetry

Infrastructure backends are usually designed to provide support functionality used to build services. They include items such as access control systems, telemetry capturing systems, quota enforcement systems, billing systems, etc. Services traditionally directly integrate with these backend systems, creating a hard coupling and baking-in specific semantics and usage options.

Istio provides a uniform abstraction that makes it possible for Istio to interface with an open-ended set of infrastructure backends. This is done in such a way to provide rich and deep controls to the operator, while imposing no burden on service developers. Istio is designed to change the boundaries between layers in order to reduce systemic complexity, eliminate policy logic from service code and give control to operators.

Mixer is the Istio component responsible for providing policy controls and telemetry collection:

The Envoy sidecar logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry. The sidecar has local caching such that a large percentage of precondition checks can be performed from cache. Additionally, the sidecar buffers outgoing telemetry such that it only calls Mixer infrequently.

At a high level, Mixer provides:

Beyond these functional aspects, Mixer also has reliability and scalability benefits. Policy enforcement and telemetry collection are entirely driven from configuration.

Mixer is a highly modular and extensible component. One of its key functions is to abstract the details of different policy and telemetry backend systems, allowing the rest of Istio to be agnostic of those backends.

Mixer's flexibility in dealing with different infrastructure backends comes from its general-purpose plugin model. Individual plugins are known as adapters and they allow Mixer to interface to different infrastructure backends that deliver core functionality, such as logging, monitoring, quotas, ACL checking, and more. The exact set of adapters used at runtime is determined through configuration and can easily be extended to target new or custom infrastructure backends. For example, adapters are available for these backends: