istio weight 20 networks multiple clusters tenancy title Deployment Models keywords Describes the options and considerations when configuring your Istio deployment single cluster control plane

Answer:
---
title: Deployment Models
description: Describes the options and considerations when configuring your Istio deployment.
weight: 20
keywords:
  - single-cluster
  - multiple-clusters
  - control-plane
  - tenancy
  - networks
  - identity
  - trust
  - single-mesh
  - multiple-meshes
aliases:
  - /docs/concepts/multicluster-deployments
  - /docs/concepts/deployment-models
  - /docs/ops/prep/deployment-models
owner: istio/wg-environments-maintainers
test: n/a
---

When configuring a production deployment of Istio, you need to answer a number of questions.
Will the mesh be confined to a single cluster or distributed across
multiple clusters? Will all the services be located in a single fully connected network, or will
gateways be required to connect services across multiple networks? Is there a single
control plane, potentially shared across clusters,
or are there multiple control planes deployed to ensure high availability (HA)?
Are all clusters going to be connected into a single multicluster
service mesh or will they be federated into a multi-mesh deployment?

All of these questions, among others, represent independent dimensions of configuration for an Istio deployment.

1. single or multiple cluster
1. single or multiple network
1. single or multiple control plane
1. single or multiple mesh

In a production environment involving multiple clusters, you can use a mix
of deployment models. For example, having more than one control plane is recommended for HA,
but you could achieve this for a 3 cluster deployment by deploying 2 clusters with
a single shared control plane and then adding the third cluster with a second
control plane in a different network. All three clusters could then be configured
to share both control planes so that all the clusters have 2 sources of control
to ensure HA.

Choosing the right deployment model depends on the isolation, performance,
and HA requirements for your use case. This guide describes the various options and
considerations when configuring your Istio deployment.

## Cluster models

The workload instances of your application run in one or more
clusters. For isolation, performance, and
high availability, you can confine clusters to availability zones and regions.

Production systems, depending on their requirements, can run across multiple
clusters spanning a number of zones or regions, leveraging cloud load balancers
to handle things like locality and zonal or regional fail over.

In most cases, clusters represent boundaries for configuration and endpoint
discovery. For example, each Kubernetes cluster has an API Server which manages
the configuration for the cluster as well as serving
service endpoint information as pods are brought up
or down. Since Kubernetes configures this behavior on a per-cluster basis, this
approach helps limit the potential problems caused by incorrect configurations.

In Istio, you can configure a single service mesh to span any number of
clusters.

### Single cluster

In the simplest case, you can confine an Istio mesh to a single
cluster. A cluster usually operates over a
[single network](#single-network), but it varies between infrastructure
providers. A single cluster and single network model includes a control plane,
which results in the simplest Istio deployment.

Single cluster deployments offer simplicity, but lack other features, for
example, fault isolation and fail over. If you need higher availability, you
should use multiple clusters.

### Multiple clusters

You can configure a single mesh to include
multiple clusters. Using a
multicluster deployment within a single mesh affords
the following capabilities beyond that of a single cluster deployment:

- Fault isolation and fail over: `cluster-1` goes down, fail over to `cluster-2`.
- Location-aware routing and fail over: Send requests to the nearest service.
- Various [control plane models](#control-plane-models): Support different
  levels of availability.
- Team or project isolation: Each team runs its own set of clusters.

Multicluster deployments give you a greater degree of isolation and
availability but increase complexity. If your systems have high availability
requirements, you likely need clusters across multiple zones and regions. You
can canary configuration changes or new binary releases in a single cluster,
where the configuration changes only affect a small amount of user traffic.
Additionally, if a cluster has a problem, you can temporarily route traffic to
nearby clusters until you address the issue.

You can configure inter-cluster communication based on the
[network](#network-models) and the options supported by your cloud provider. For
example, if two clusters reside on the same underlying network, you can enable
cross-cluster communication by simply configuring firewall rules.

Within a multicluster mesh, all services are shared by default, according to the
concept of namespace sameness.
[Traffic management rules](/docs/ops/configuration/traffic-management/multicluster)
provide fine-grained control over the behavior of multicluster traffic.

### DNS with multiple clusters

When a client application makes a request to some host, it must first perform a
DNS lookup for the hostname to obtain an IP address before it can proceed with
the request.
In Kubernetes, the DNS server residing within the cluster typically handles
this DNS lookup, based on the configured `Service` definitions.

Istio uses the virtual IP returned by the DNS lookup to load balance
across the list of active endpoints for the requested service, taking into account any
Istio configured routing rules.
Istio uses either Kubernetes `Service`/`Endpoint` or Istio `ServiceEntry` to
configure its internal mapping of hostname to workload IP addresses.

This two-tiered naming system becomes more complicated when you have multiple
clusters. Istio is inherently multicluster-aware, but Kubernetes is not
(today). Because of this, the client cluster must have a DNS entry for the
service in order for the DNS lookup to succeed, and a request to be
successfully sent. This is true even if there are no instances of that
service's pods running in the client cluster.

To ensure that DNS lookup succeeds, you must deploy a Kubernetes `Service` to
each cluster that consumes that service. This ensures that regardless of
where the request originates, it will pass DNS lookup and be handed to Istio
for proper routing.
This can also be achieved with Istio `ServiceEntry`, rather than Kubernetes
`Service`. However, a `ServiceEntry` does not configure the Kubernetes DNS server.
This means that DNS will need to be configured either manually or
with automated tooling such as the
[Address auto allocation](/docs/ops/configuration/traffic-management/dns-proxy/#address-auto-allocation)
feature of [Istio DNS Proxying](/docs/ops/configuration/traffic-management/dns-proxy/).

There are a few efforts in progress that will help simplify the DNS story:

- [Admiral](https://github.com/istio-ecosystem/admiral) is an Istio community
  project that provides a number of multicluster capabilities. If you need to support multi-network
  topologies, managing this configuration across multiple clusters at scale is challenging.
  Admiral takes an opinionated view on this configuration and provides automatic provisioning and
  synchronization across clusters.

- [Kubernetes Multi-Cluster Services](https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/1645-multi-cluster-services-api)
  is a Kubernetes Enhancement Proposal (KEP) that defines an API for exporting
  services to multiple clusters. This effectively pushes the responsibility of
  service visibility and DNS resolution for the entire `clusterset` onto
  Kubernetes. There is also work in progress to build layers of `MCS` support
  into Istio, which would allow Istio to work with any cloud vendor `MCS`
  controller or even act as the `MCS` controller for the entire mesh.

## Network models

Istio uses a simplified definition of network to
refer to workload instances that have direct
reachability. For example, by default all workload instances in a single
cluster are on the same network.

Many production systems require multiple networks or subnets for isolation
and high availability. Istio supports spanning a service mesh over a variety of
network topologies. This approach allows you to select the network model that
fits your existing network topology.

### Single network

In the simplest case, a service mesh operates over a single fully connected
network. In a single network model, all
workload instances
can reach each other directly without an Istio gateway.

A single network allows Istio to configure service consumers in a uniform
way across the mesh with the ability to directly address workload instances.
Note, however, that for a single network across multiple clusters,
services and endpoints cannot have overlapping IP addresses.

### Multiple networks

You can span a single service mesh across multiple networks; such a
configuration is known as **multi-network**.

Multiple networks afford the following capabilities beyond that of single networks:

- Overlapping IP or VIP ranges for **service endpoints**
- Crossing of administrative boundaries
- Fault tolerance
- Scaling of network addresses
- Compliance with standards that require network segmentation

In this model, the workload instances in different networks can only reach each
other through one or more [Istio gateways](/docs/concepts/traffic-management/#gateways).
Istio uses **partitioned service discovery** to provide consumers a different
view of service endpoints. The view depends on the
network of the consumers.

This solution requires exposing all services (or a subset) through the gateway.
Cloud vendors may provide options that will not require exposing services on
the public internet. Such an option, if it exists and meets your requirements,
will likely be the best choice.

In order to ensure secure communications in a multi-network scenario, Istio
only supports cross-network communication to workloads with an Istio proxy.
This is due to the fact that Istio exposes services at the Ingress Gateway with TLS
pass-through, which enables mTLS directly to the workload. A workload without
an Istio proxy, however, will likely not be able to participate in mutual
authentication with other workloads. For this reason, Istio filters
out-of-network endpoints for proxyless services.

## Control plane models

An Istio mesh uses the control plane to configure all
communication between workload instances within the mesh. Workload instances
connect to a control plane instance to get their configuration.

In the simplest case, you can run your mesh with a control plane on a single
cluster.

A cluster like this one, with its own local control plane, is referred to as
a primary cluster.

Multicluster deployments can also share control plane instances. In this case,
the control plane instances can reside in one or more primary clusters.
Clusters without their own control plane are referred to as
remote clusters.

To support remote clusters in a multicluster mesh, the control plane in
a primary cluster must be accessible via a stable IP (e.g., a cluster IP).
For clusters spanning networks,
this can be achieved by exposing the control plane through an Istio gateway.
Cloud vendors may provide options, such as internal load balancers, for
providing this capability without exposing the control plane on the
public internet. Such an option, if it exists and meets your requirements,
will likely be the best choice.

In multicluster deployments with more than one primary cluster, each primary
cluster receives its configuration (i.e., `Service` and `ServiceEntry`,
`DestinationRule`, etc.) from the Kubernetes API Server residing in the same
cluster. Each primary cluster, therefore, has an independent source of
configuration.
This duplication of configuration across primary clusters does require
additional steps when rolling out changes. Large production
systems may automate this process with tooling, such as CI/CD systems, in
order to manage configuration rollout.

Instead of running control planes in primary clusters inside the mesh, a
service mesh composed entirely of remote clusters can be controlled by an
external control plane. This provides isolated
management and complete separation of the control plane deployment from the
data plane services that comprise the mesh.

A cloud vendor's managed control plane is a
typical example of an external control plane.

For high availability, you should deploy multiple control planes across
clusters, zones, or regions.

This model affords the following benefits:

- Improved availability: If a control plane becomes unavailable, the scope of
  the outage is limited to only workloads in clusters managed by that control plane.

- Configuration isolation: You can make configuration changes in one cluster,
  zone, or region without impacting others.

- Controlled rollout: You have more fine-grained control over configuration
  rollout (e.g., one cluster at a time). You can also canary configuration changes in a sub-section of the mesh
  controlled by a given primary cluster.

- Selective service visibility: You can restrict service visibility to part
  of the mesh, helping to establish service-level isolation. For example, an
  administrator may choose to deploy the `HelloWorld` service to Cluster A,
  but not Cluster B. Any attempt to call `HelloWorld` from Cluster B will
  fail the DNS lookup.

The following list ranks control plane deployment examples by availability:

- One cluster per region (**lowest availability**)
- Multiple clusters per region
- One cluster per zone
- Multiple clusters per zone
- Each cluster (**highest availability**)

### Endpoint discovery with multiple control planes

An Istio control plane manages traffic within the mesh by providing each proxy
with the list of service endpoints. In order to make this work in a
multicluster scenario, each control plane must observe endpoints from the API
Server in every cluster.

To enable endpoint discovery for a cluster, an administrator generates a
`remote secret` and deploys it to each primary cluster in the mesh. The
`remote secret` contains credentials, granting access to the API server in the
cluster.
The control planes will then connect and discover the service endpoints for
the cluster, enabling cross-cluster load balancing for these services.

By default, Istio will load balance requests evenly between endpoints in
each cluster. In large systems that span geographic regions, it may be
desirable to use [locality load balancing](/docs/tasks/traffic-management/locality-load-balancing)
to prefer that traffic stay in the same zone or region.

In some advanced scenarios, load balancing across clusters may not be desired.
For example, in a blue/green deployment, you may deploy different versions of
the system to different clusters. In this case, each cluster is effectively
operating as an independent mesh. This behavior can be achieved in a couple of
ways:

- Do not exchange remote secrets between the clusters. This offers the
  strongest isolation between the clusters.

- Use `VirtualService` and `DestinationRule` to disallow routing between two
  versions of the services.

In either case, cross-cluster load balancing is prevented. External traffic
can be routed to one cluster or the other using an external load balancer.

## Identity and trust models

When a workload instance is created within a service mesh, Istio assigns the
workload an identity.

The Certificate Authority (CA) creates and signs the certificates used to verify
the identities used within the mesh. You can verify the identity of the message sender
with the public key of the CA that created and signed the certificate
for that identity. A **trust bundle** is the set of all CA public keys used by
an Istio mesh. With a mesh's trust bundle, anyone can verify the sender of any
message coming from that mesh.

### Trust within a mesh

Within a single Istio mesh, Istio ensures each workload instance has an
appropriate certificate representing its own identity, and the trust bundle
necessary to recognize all identities within the mesh and any federated meshes.
The CA creates and signs the certificates for those identities. This model
allows workload instances in the mesh to authenticate each other when
communicating.

### Trust between meshes

To enable communication between two meshes with different CAs, you must
exchange the trust bundles of the meshes. Istio does not provide any tooling
to exchange trust bundles across meshes. You can exchange the trust bundles
either manually or automatically using a protocol such as [SPIFFE Trust Domain Federation](https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE_Federation.md).
Once you import a trust bundle to a mesh, you can configure local policies for
those identities.

## Mesh models

Istio supports having all of your services in a
mesh, or federating multiple meshes
together, which is also known as multi-mesh.

### Single mesh

The simplest Istio deployment is a single mesh. Within a mesh, service names are
unique. For example, only one service can have the name `mysvc` in the `foo`
namespace. Additionally, workload instances share a common identity since
service account names are unique within a namespace, just like service names.

A single mesh can span [one or more clusters](#cluster-models) and
[one or more networks](#network-models). Within a mesh,
[namespaces](#namespace-tenancy) are used for [tenancy](#tenancy-models).

### Multiple meshes

Multiple mesh deployments result from mesh federation.

Multiple meshes afford the following capabilities beyond that of a single mesh:

- Organizational boundaries: lines of business
- Service name or namespace reuse: multiple distinct uses of the `default`
  namespace
- Stronger isolation: isolating test workloads from production workloads

You can enable inter-mesh communication with mesh federation. When federating, each mesh can expose a set of services and
identities, which all participating meshes can recognize.

To avoid service naming collisions, you can give each mesh a globally unique
**mesh ID**, to ensure that the fully qualified domain
name (FQDN) for each service is distinct.

When federating two meshes that do not share the same
trust domain, you must federate
identity and **trust bundles** between them. See the
section on [Trust between meshes](#trust-between-meshes) for more details.

## Tenancy models

In Istio, a **tenant** is a group of users that share
common access and privileges for a set of deployed workloads.
Tenants can be used to provide a level of isolation between different teams.

You can configure tenancy models to satisfy the following organizational
requirements for isolation:

- Security
- Policy
- Capacity
- Cost
- Performance

Istio supports three types of tenancy models:

- [Namespace tenancy](#namespace-tenancy)
- [Cluster tenancy](#cluster-tenancy)
- [Mesh tenancy](#mesh-tenancy)

### Namespace tenancy

A cluster can be shared across multiple teams, each using a different namespace.
You can grant a team permission to deploy its workloads only to a given namespace
or set of namespaces.

By default, services from multiple namespaces can communicate with each other,
but you can increase isolation by selectively choosing which services to expose to other
namespaces. You can configure authorization policies for exposed services to restrict
access to only the appropriate callers.

Namespace tenancy can extend beyond a single cluster.
When using [multiple clusters](#multiple-clusters), the namespaces in each
cluster sharing the same name are considered the same namespace by default.
For example, `Service B` in the `Team-1` namespace of cluster `West` and `Service B` in the
`Team-1` namespace of cluster `East` refer to the same service, and Istio merges their
endpoints for service discovery and load balancing.

### Cluster tenancy

Istio supports using clusters as a unit of tenancy. In this case, you can give
each team a dedicated cluster or set of clusters to deploy their
workloads. Permissions for a cluster are usually limited to the members of the
team that owns it. You can set various roles for finer grained control, for
example:

- Cluster administrator
- Developer

To use cluster tenancy with Istio, you configure each team's cluster with its
own control plane, allowing each team to manage its own configuration.
Alternatively, you can use Istio to implement a group of clusters as a single tenant
using remote clusters or multiple
synchronized primary clusters.
Refer to [control plane models](#control-plane-models) for details.

### Mesh Tenancy

In a multi-mesh deployment with mesh federation, each mesh
can be used as the unit of isolation.

Since a different team or organization operates each mesh, service naming
is rarely distinct. For example, a `Service C` in the `foo` namespace of
cluster `Team-1` and the `Service C` service in the `foo` namespace of cluster
`Team-2` will not refer to the same service. The most common example is the
scenario in Kubernetes where many teams deploy their workloads to the `default`
namespace.

When each team has its own mesh, cross-mesh communication follows the
concepts described in the [multiple meshes](#multiple-meshes) model.

title  Deployment Models description  Describes the options and considerations when configuring your Istio deployment  weight  20 keywords      single cluster     multiple clusters     control plane     tenancy     networks     identity     trust     single mesh     multiple meshes aliases       docs concepts multicluster deployments      docs concepts deployment models      docs ops prep deployment models owner  istio wg environments maintainers test  n a      When configuring a production deployment of Istio  you need to answer a number of questions  Will the mesh be confined to a single cluster or distributed across multiple clusters  Will all the services be located in a single fully connected network  or will gateways be required to connect services across multiple networks  Is there a single control plane  potentially shared across clusters  or are there multiple control planes deployed to ensure high availability  HA   Are all clusters going to be connected into a single multicluster service mesh or will they be federated into a multi mesh deployment   All of these questions  among others  represent independent dimensions of configuration for an Istio deployment   1  single or multiple cluster 1  single or multiple network 1  single or multiple control plane 1  single or multiple mesh  In a production environment involving multiple clusters  you can use a mix of deployment models  For example  having more than one control plane is recommended for HA  but you could achieve this for a 3 cluster deployment by deploying 2 clusters with a single shared control plane and then adding the third cluster with a second control plane in a different network  All three clusters could then be configured to share both control planes so that all the clusters have 2 sources of control to ensure HA   Choosing the right deployment model depends on the isolation  performance  and HA requirements for your use case  This guide describes the various options and considerations when configuring your Istio deployment      Cluster models  The workload instances of your application run in one or more clusters  For isolation  performance  and high availability  you can confine clusters to availability zones and regions   Production systems  depending on their requirements  can run across multiple clusters spanning a number of zones or regions  leveraging cloud load balancers to handle things like locality and zonal or regional fail over   In most cases  clusters represent boundaries for configuration and endpoint discovery  For example  each Kubernetes cluster has an API Server which manages the configuration for the cluster as well as serving service endpoint information as pods are brought up or down  Since Kubernetes configures this behavior on a per cluster basis  this approach helps limit the potential problems caused by incorrect configurations   In Istio  you can configure a single service mesh to span any number of clusters       Single cluster  In the simplest case  you can confine an Istio mesh to a single cluster  A cluster usually operates over a  single network   single network   but it varies between infrastructure providers  A single cluster and single network model includes a control plane  which results in the simplest Istio deployment     Single cluster deployments offer simplicity  but lack other features  for example  fault isolation and fail over  If you need higher availability  you should use multiple clusters       Multiple clusters  You can configure a single mesh to include multiple clusters  Using a multicluster deployment within a single mesh affords the following capabilities beyond that of a single cluster deployment     Fault isolation and fail over   cluster 1  goes down  fail over to  cluster 2     Location aware routing and fail over  Send requests to the nearest service    Various  control plane models   control plane models   Support different   levels of availability    Team or project isolation  Each team runs its own set of clusters     Multicluster deployments give you a greater degree of isolation and availability but increase complexity  If your systems have high availability requirements  you likely need clusters across multiple zones and regions  You can canary configuration changes or new binary releases in a single cluster  where the configuration changes only affect a small amount of user traffic  Additionally  if a cluster has a problem  you can temporarily route traffic to nearby clusters until you address the issue   You can configure inter cluster communication based on the  network   network models  and the options supported by your cloud provider  For example  if two clusters reside on the same underlying network  you can enable cross cluster communication by simply configuring firewall rules   Within a multicluster mesh  all services are shared by default  according to the concept of namespace sameness   Traffic management rules   docs ops configuration traffic management multicluster  provide fine grained control over the behavior of multicluster traffic       DNS with multiple clusters  When a client application makes a request to some host  it must first perform a DNS lookup for the hostname to obtain an IP address before it can proceed with the request  In Kubernetes  the DNS server residing within the cluster typically handles this DNS lookup  based on the configured  Service  definitions   Istio uses the virtual IP returned by the DNS lookup to load balance across the list of active endpoints for the requested service  taking into account any Istio configured routing rules  Istio uses either Kubernetes  Service   Endpoint  or Istio  ServiceEntry  to configure its internal mapping of hostname to workload IP addresses   This two tiered naming system becomes more complicated when you have multiple clusters  Istio is inherently multicluster aware  but Kubernetes is not  today   Because of this  the client cluster must have a DNS entry for the service in order for the DNS lookup to succeed  and a request to be successfully sent  This is true even if there are no instances of that service s pods running in the client cluster   To ensure that DNS lookup succeeds  you must deploy a Kubernetes  Service  to each cluster that consumes that service  This ensures that regardless of where the request originates  it will pass DNS lookup and be handed to Istio for proper routing  This can also be achieved with Istio  ServiceEntry   rather than Kubernetes  Service   However  a  ServiceEntry  does not configure the Kubernetes DNS server  This means that DNS will need to be configured either manually or with automated tooling such as the  Address auto allocation   docs ops configuration traffic management dns proxy  address auto allocation  feature of  Istio DNS Proxying   docs ops configuration traffic management dns proxy      There are a few efforts in progress that will help simplify the DNS story      Admiral  https   github com istio ecosystem admiral  is an Istio community   project that provides a number of multicluster capabilities  If you need to support multi network   topologies  managing this configuration across multiple clusters at scale is challenging    Admiral takes an opinionated view on this configuration and provides automatic provisioning and   synchronization across clusters      Kubernetes Multi Cluster Services  https   github com kubernetes enhancements tree master keps sig multicluster 1645 multi cluster services api    is a Kubernetes Enhancement Proposal  KEP  that defines an API for exporting   services to multiple clusters  This effectively pushes the responsibility of   service visibility and DNS resolution for the entire  clusterset  onto   Kubernetes  There is also work in progress to build layers of  MCS  support   into Istio  which would allow Istio to work with any cloud vendor  MCS    controller or even act as the  MCS  controller for the entire mesh       Network models  Istio uses a simplified definition of network to refer to workload instances that have direct reachability  For example  by default all workload instances in a single cluster are on the same network   Many production systems require multiple networks or subnets for isolation and high availability  Istio supports spanning a service mesh over a variety of network topologies  This approach allows you to select the network model that fits your existing network topology       Single network  In the simplest case  a service mesh operates over a single fully connected network  In a single network model  all workload instances can reach each other directly without an Istio gateway   A single network allows Istio to configure service consumers in a uniform way across the mesh with the ability to directly address workload instances  Note  however  that for a single network across multiple clusters  services and endpoints cannot have overlapping IP addresses         Multiple networks  You can span a single service mesh across multiple networks  such a configuration is known as   multi network     Multiple networks afford the following capabilities beyond that of single networks     Overlapping IP or VIP ranges for   service endpoints     Crossing of administrative boundaries   Fault tolerance   Scaling of network addresses   Compliance with standards that require network segmentation  In this model  the workload instances in different networks can only reach each other through one or more  Istio gateways   docs concepts traffic management  gateways   Istio uses   partitioned service discovery   to provide consumers a different view of service endpoints  The view depends on the network of the consumers     This solution requires exposing all services  or a subset  through the gateway  Cloud vendors may provide options that will not require exposing services on the public internet  Such an option  if it exists and meets your requirements  will likely be the best choice    In order to ensure secure communications in a multi network scenario  Istio only supports cross network communication to workloads with an Istio proxy  This is due to the fact that Istio exposes services at the Ingress Gateway with TLS pass through  which enables mTLS directly to the workload  A workload without an Istio proxy  however  will likely not be able to participate in mutual authentication with other workloads  For this reason  Istio filters out of network endpoints for proxyless services       Control plane models  An Istio mesh uses the control plane to configure all communication between workload instances within the mesh  Workload instances connect to a control plane instance to get their configuration   In the simplest case  you can run your mesh with a control plane on a single cluster     A cluster like this one  with its own local control plane  is referred to as a primary cluster   Multicluster deployments can also share control plane instances  In this case  the control plane instances can reside in one or more primary clusters  Clusters without their own control plane are referred to as remote clusters     To support remote clusters in a multicluster mesh  the control plane in a primary cluster must be accessible via a stable IP  e g   a cluster IP   For clusters spanning networks  this can be achieved by exposing the control plane through an Istio gateway  Cloud vendors may provide options  such as internal load balancers  for providing this capability without exposing the control plane on the public internet  Such an option  if it exists and meets your requirements  will likely be the best choice   In multicluster deployments with more than one primary cluster  each primary cluster receives its configuration  i e    Service  and  ServiceEntry    DestinationRule   etc   from the Kubernetes API Server residing in the same cluster  Each primary cluster  therefore  has an independent source of configuration  This duplication of configuration across primary clusters does require additional steps when rolling out changes  Large production systems may automate this process with tooling  such as CI CD systems  in order to manage configuration rollout   Instead of running control planes in primary clusters inside the mesh  a service mesh composed entirely of remote clusters can be controlled by an external control plane  This provides isolated management and complete separation of the control plane deployment from the data plane services that comprise the mesh     A cloud vendor s managed control plane is a typical example of an external control plane   For high availability  you should deploy multiple control planes across clusters  zones  or regions     This model affords the following benefits     Improved availability  If a control plane becomes unavailable  the scope of   the outage is limited to only workloads in clusters managed by that control plane     Configuration isolation  You can make configuration changes in one cluster    zone  or region without impacting others     Controlled rollout  You have more fine grained control over configuration   rollout  e g   one cluster at a time   You can also canary configuration changes in a sub section of the mesh   controlled by a given primary cluster     Selective service visibility  You can restrict service visibility to part   of the mesh  helping to establish service level isolation  For example  an   administrator may choose to deploy the  HelloWorld  service to Cluster A    but not Cluster B  Any attempt to call  HelloWorld  from Cluster B will   fail the DNS lookup   The following list ranks control plane deployment examples by availability     One cluster per region    lowest availability      Multiple clusters per region   One cluster per zone   Multiple clusters per zone   Each cluster    highest availability         Endpoint discovery with multiple control planes  An Istio control plane manages traffic within the mesh by providing each proxy with the list of service endpoints  In order to make this work in a multicluster scenario  each control plane must observe endpoints from the API Server in every cluster   To enable endpoint discovery for a cluster  an administrator generates a  remote secret  and deploys it to each primary cluster in the mesh  The  remote secret  contains credentials  granting access to the API server in the cluster  The control planes will then connect and discover the service endpoints for the cluster  enabling cross cluster load balancing for these services     By default  Istio will load balance requests evenly between endpoints in each cluster  In large systems that span geographic regions  it may be desirable to use  locality load balancing   docs tasks traffic management locality load balancing  to prefer that traffic stay in the same zone or region   In some advanced scenarios  load balancing across clusters may not be desired  For example  in a blue green deployment  you may deploy different versions of the system to different clusters  In this case  each cluster is effectively operating as an independent mesh  This behavior can be achieved in a couple of ways     Do not exchange remote secrets between the clusters  This offers the   strongest isolation between the clusters     Use  VirtualService  and  DestinationRule  to disallow routing between two   versions of the services   In either case  cross cluster load balancing is prevented  External traffic can be routed to one cluster or the other using an external load balancer      Identity and trust models  When a workload instance is created within a service mesh  Istio assigns the workload an identity   The Certificate Authority  CA  creates and signs the certificates used to verify the identities used within the mesh  You can verify the identity of the message sender with the public key of the CA that created and signed the certificate for that identity  A   trust bundle   is the set of all CA public keys used by an Istio mesh  With a mesh s trust bundle  anyone can verify the sender of any message coming from that mesh       Trust within a mesh  Within a single Istio mesh  Istio ensures each workload instance has an appropriate certificate representing its own identity  and the trust bundle necessary to recognize all identities within the mesh and any federated meshes  The CA creates and signs the certificates for those identities  This model allows workload instances in the mesh to authenticate each other when communicating         Trust between meshes  To enable communication between two meshes with different CAs  you must exchange the trust bundles of the meshes  Istio does not provide any tooling to exchange trust bundles across meshes  You can exchange the trust bundles either manually or automatically using a protocol such as  SPIFFE Trust Domain Federation  https   github com spiffe spiffe blob main standards SPIFFE Federation md   Once you import a trust bundle to a mesh  you can configure local policies for those identities        Mesh models  Istio supports having all of your services in a mesh  or federating multiple meshes together  which is also known as multi mesh       Single mesh  The simplest Istio deployment is a single mesh  Within a mesh  service names are unique  For example  only one service can have the name  mysvc  in the  foo  namespace  Additionally  workload instances share a common identity since service account names are unique within a namespace  just like service names   A single mesh can span  one or more clusters   cluster models  and  one or more networks   network models   Within a mesh   namespaces   namespace tenancy  are used for  tenancy   tenancy models        Multiple meshes  Multiple mesh deployments result from mesh federation   Multiple meshes afford the following capabilities beyond that of a single mesh     Organizational boundaries  lines of business   Service name or namespace reuse  multiple distinct uses of the  default    namespace   Stronger isolation  isolating test workloads from production workloads  You can enable inter mesh communication with mesh federation  When federating  each mesh can expose a set of services and identities  which all participating meshes can recognize     To avoid service naming collisions  you can give each mesh a globally unique   mesh ID    to ensure that the fully qualified domain name  FQDN  for each service is distinct   When federating two meshes that do not share the same trust domain  you must federate identity and   trust bundles   between them  See the section on  Trust between meshes   trust between meshes  for more details      Tenancy models  In Istio  a   tenant   is a group of users that share common access and privileges for a set of deployed workloads  Tenants can be used to provide a level of isolation between different teams   You can configure tenancy models to satisfy the following organizational requirements for isolation     Security   Policy   Capacity   Cost   Performance  Istio supports three types of tenancy models      Namespace tenancy   namespace tenancy     Cluster tenancy   cluster tenancy     Mesh tenancy   mesh tenancy       Namespace tenancy  A cluster can be shared across multiple teams  each using a different namespace  You can grant a team permission to deploy its workloads only to a given namespace or set of namespaces   By default  services from multiple namespaces can communicate with each other  but you can increase isolation by selectively choosing which services to expose to other namespaces  You can configure authorization policies for exposed services to restrict access to only the appropriate callers     Namespace tenancy can extend beyond a single cluster  When using  multiple clusters   multiple clusters   the namespaces in each cluster sharing the same name are considered the same namespace by default  For example   Service B  in the  Team 1  namespace of cluster  West  and  Service B  in the  Team 1  namespace of cluster  East  refer to the same service  and Istio merges their endpoints for service discovery and load balancing         Cluster tenancy  Istio supports using clusters as a unit of tenancy  In this case  you can give each team a dedicated cluster or set of clusters to deploy their workloads  Permissions for a cluster are usually limited to the members of the team that owns it  You can set various roles for finer grained control  for example     Cluster administrator   Developer  To use cluster tenancy with Istio  you configure each team s cluster with its own control plane  allowing each team to manage its own configuration  Alternatively  you can use Istio to implement a group of clusters as a single tenant using remote clusters or multiple synchronized primary clusters  Refer to  control plane models   control plane models  for details       Mesh Tenancy  In a multi mesh deployment with mesh federation  each mesh can be used as the unit of isolation     Since a different team or organization operates each mesh  service naming is rarely distinct  For example  a  Service C  in the  foo  namespace of cluster  Team 1  and the  Service C  service in the  foo  namespace of cluster  Team 2  will not refer to the same service  The most common example is the scenario in Kubernetes where many teams deploy their workloads to the  default  namespace   When each team has its own mesh  cross mesh communication follows the concepts described in the  multiple meshes   multiple meshes  model


istio Describes Istio s security model title Security Model owner istio wg security maintainers This document aims to describe the security posture of Istio s various components and how possible attacks can impact the system weight 10 test n a

Answer:
---
title: Security Model
description: Describes Istio's security model.
weight: 10
owner: istio/wg-security-maintainers
test: n/a
---

This document aims to describe the security posture of Istio's various components, and how possible attacks can impact the system.

## Components

Istio comes with a variety of optional components that will be covered here.
For a high level overview, see [Istio Architecture](/docs/ops/deployment/architecture/).
Note that Istio deployments are highly flexible; below, we will primarily assume the worst case scenarios.

### Istiod

Istiod serves as the core control plane component of Istio, often serving the role of the [XDS serving component](/docs/concepts/traffic-management/) as well
as the mesh [mTLS Certificate Authority](/docs/concepts/security/).

Istiod is considered a highly privileged component, similar to that of the Kubernetes API server itself.
* It has high Kubernetes RBAC privileges, typically including `Secret` read access and webhook write access.
* When acting as the CA, it can provision arbitrary certificates.
* When acting as the XDS control plane, it can program proxies to perform arbitrary behavior.

As such, the security of the cluster is tightly coupled to the security of Istiod.
Following [Kubernetes security best practices](https://kubernetes.io/docs/concepts/security/) around Istiod access is paramount.

### Istio CNI plugin

Istio can optionally be deployed with the [Istio CNI Plugin `DaemonSet`](/docs/setup/additional-setup/cni/).
This `DaemonSet` is responsible for setting up networking rules in Istio to ensure traffic is transparently redirected as needed.
This is an alternative to the `istio-init` container discussed [below](#sidecar-proxies).

Because the CNI `DaemonSet` modifies networking rules on the node, it requires an elevated `securityContext`.
However, unlike [Istiod](#istiod), this is a **node-local** privilege.
The implications of this are discussed [below](#node-compromise).

Because this consolidates the elevated privileges required to setup networking into a single pod, rather than *every* pod,
this option is generally recommended.

### Sidecar Proxies

Istio may [optionally](/docs/overview/dataplane-modes/) deploy a sidecar proxy next to an application.

The sidecar proxy needs the network to be programmed to direct all traffic through the proxy.
This can be done with the [Istio CNI plugin](#istio-cni-plugin) or by deploying an `initContainer` (`istio-init`) on the pod (this is done automatically if the CNI plugin is not deployed).
The `istio-init` container requires `NET_ADMIN` and `NET_RAW` capabilities.
However, these capabilities are only present during the initialization - the primary sidecar container is completely unprivileged.

Additionally, the sidecar proxy does not require any associated Kubernetes RBAC privileges at all.

Each sidecar proxy is authorized to request a certificate for the associated Pod Service Account.

### Gateways and Waypoints

Gateways and Waypoints act as standalone proxy deployments.
Unlike [sidecars](#sidecar-proxies), they do not require any networking modifications, and thus don't require any privilege.

These components run with their own service accounts, distinct from application identities.

### Ztunnel

Ztunnel acts as a node-level proxy.
This task requires the `NET_ADMIN`, `SYS_ADMIN`, and `NET_RAW` capabilities.
Like the [Istio CNI Plugin](#istio-cni-plugin), these are **node-local** privileges only.
The Ztunnel does not have any associated Kubernetes RBAC privileges.

Ztunnel is authorized to request certificates for any Service Accounts of pods running on the same node.
Similar to [kubelet](https://kubernetes.io/docs/reference/access-authn-authz/node/), this explicitly does not allow requesting arbitrary
certificates.
This, again, ensures these privileges are **node-local** only.

## Traffic Capture Properties

When a pod is enrolled in the mesh, all incoming TCP traffic will be redirected to the proxy.
This includes both mTLS/HBONE traffic and plaintext traffic.
Any applicable [policies](/docs/tasks/security/authorization/) for the workload will be enforced before forwarding the traffic to the workload.

However, Istio does not currently guarantee that _outgoing_ traffic is redirect to the proxy.
See [traffic capture limitations](/docs/ops/best-practices/security/#understand-traffic-capture-limitations).
As such, care must be taken to follow the [securing egress traffic](/docs/ops/best-practices/security/#securing-egress-traffic) steps if outbound policies are required.

## Mutual TLS Properties

[Mutual TLS](/docs/concepts/security/#mutual-tls-authentication) provides the basis for much of Istio's security posture.
Below explains various properties mutual TLS provides for the security posture of Istio.

### Certificate Authority

Istio comes out of the box with its own Certificate Authority.

By default, the CA allows authenticating clients based on either of the options below:
* A Kubernetes JWT token, with an audience of `istio-ca`, verified with a Kubernetes `TokenReview`. This is the default method in Kubernetes Pods.
* An existing mutual TLS certificate.
* Custom JWT tokens, verified using OIDC (requires configuration).

The CA will only issue certificates that are requested for identities that a client is authenticated for.

Istio can also integrate with a variety of third party CAs; please refer to any of their security documentation for more information on how they behave.

### Client mTLS

In sidecar mode, the client sidecar will [automatically use TLS](/docs/ops/configuration/traffic-management/tls-configuration/#auto-mtls) when connecting to a service
that is detected to support mTLS. This can also be [explicitly configured](/docs/ops/configuration/traffic-management/tls-configuration/#sidecars).
Note that this automatic detection relies on Istio associating the traffic to a Service.
[Unsupported traffic types](/docs/ops/configuration/traffic-management/traffic-routing/#unmatched-traffic) or [configuration scoping](/docs/ops/configuration/mesh/configuration-scoping/) can prevent this.

When [connecting to a backend](/docs/concepts/security/#secure-naming), the set of allowed identities is computed, at the Service level, based on the union of all backend's identities.

In ambient mode, Istio will automatically use mTLS when connecting to any backend that supports mTLS, and verify the identity of the destination matches the identity the workload is expected to be running as.

These properties differ from sidecar mode in that they are properties of individual workloads, rather than of the service.
This enables more fine-grained authentication checks, as well as supporting a wider variety of workloads.

### Server mTLS

By default, Istio will accept mTLS and non-mTLS traffic (often called "permissive mode").
Users can opt-in to strict enforcement by writing `PeerAuthentication` or `AuthorizationPolicy` rules requiring mTLS.

When mTLS connections are established, the peer certificate is verified.
Additionally, the peer identity is verified to be within the same trust domain.
To verify only specific identities are allowed, an `AuthorizationPolicy` can be used.

## Compromise types explored

Based on the above overview, we will consider the impact on the cluster if various parts of the system are compromised.
In the real world, there are a variety of different variables around any security attack:

* How easy it is to execute
* What prior privileges are required
* How often it can exploited
* What the impact is (total remote execution, denial of service, etc).

In this document, we will primarily consider the worst case scenario: a compromised component means an attacker has complete remote code execution capabilities.

### Workload compromise

In this scenario, an application workload (pod) is compromised.

A pod [*may* have access](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#opt-out-of-api-credential-automounting) to its service account token.
If so, a workload compromise can move laterally from a single pod to compromising the entire service account.

In the sidecar model, the proxy is co-located with the pod, and runs within the same trust boundary.
A compromised application can tamper with the proxy through the admin API or other surfaces, including exfiltration of private key material, allowing another agent to impersonate the workload.
It should be assumed that a compromised workload also includes a compromise of the sidecar proxy.

Given this, a compromised workload may:
* Send arbitrary traffic, with or without mutual TLS.
  These may bypass any proxy configuration, or even the proxy entirely.
  Note that Istio does not offer egress-based authorization policies, so there is no egress authorization policy bypass occurring.
* Accept traffic that was already destined to the application. It may bypass policies that were configured in the sidecar proxy.

The key takeaway here is that while the compromised workload may behave maliciously, this does not give them the ability to bypass policies in _other_ workloads.

In ambient mode, the node proxy is not co-located within the pod, and runs in another trust boundary as part of an independent pod.

A compromised application may send arbitrary traffic.
However, they do not have control over the node proxy, which will chose how to handle incoming and outbound traffic.

Additionally, as the pod itself doesn't have access to a service account token to request a mutual TLS certificate, lateral movement possibilities are reduced.

Istio offers a variety of features that can limit the impact of such a compromise:
* [Observability](/docs/tasks/observability/) features can be used to identify the attack.
* [Policies](/docs/tasks/security/authorization/) can be used to restrict what type of traffic a workload can send or receive.

### Proxy compromise - Sidecars

In this scenario, a sidecar proxy is compromised.
Because the sidecar and application reside in the same trust domain, this is functionally equivalent to the [Workload compromise](#workload-compromise).

### Proxy compromise - Waypoint

In this scenario, a [waypoint proxy](#gateways-and-waypoints) is compromised.
While waypoints do not have any privileges for a hacker to exploit, they do serve (potentially) many different services and workloads.
A compromised waypoint will receive all traffic for these, which it can view, modify, or drop.

Istio offers the flexibility of [configuring the granularity of a waypoint deployment](/docs/ambient/usage/waypoint/#useawaypoint).
Users may consider deploying more isolated waypoints if they require stronger isolation.

Because waypoints run with a distinct identity from the applications they serve, a compromised waypoint does not imply the user's applications can be impersonated.

### Proxy compromise - Ztunnel

In this scenario, a [ztunnel](#ztunnel) proxy is compromised.

A compromised ztunnel gives the attacker control of the networking of the node.

Ztunnel has access to private key material for each application running on it's node.
A compromised ztunnel could have these exfiltrated and used elsewhere.
However, lateral movement to identities beyond co-located workloads is not possible; each ztunnel is only authorized to access certificates for workloads running on its node, scoping the blast radius of a compromised ztunnel.

### Node compromise

In this scenario, the Kubernetes Node is compromised.
Both [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/node/) and Istio are designed to limit the blast radius of a single node compromise, such that
the compromise of a single node does not lead to a [cluster-wide compromise](#cluster-api-server-compromise).

However, the attack does have complete control over any workloads running on that node.
For instance, it can compromise any co-located [waypoints](#proxy-compromise---waypoint), the local [ztunnel](#proxy-compromise---ztunnel), any [sidecars](#proxy-compromise---sidecars), any co-located [Istiod instances](#istiod-compromise), etc.

### Cluster (API Server) compromise

A compromise of the Kubernetes API Server effectively means the entire cluster and mesh are compromised.
Unlike most other attack vectors, there isn't much Istio can do to control the blast radius of such an attack.
A compromised API Server gives a hacker complete control over the cluster, including actions such as running `kubectl exec` on arbitrary pods,
removing any Istio `AuthorizationPolicies`, or even uninstalling Istio entirely.

### Istiod compromise

A compromise of Istiod generally leads to the same result as an [API Server compromise](#cluster-api-server-compromise).
Istiod is a highly privileged component that should be strongly protected.
Following the [security best practices](/docs/ops/best-practices/security) is crucial to maintaining a secure cluster.

title  Security Model description  Describes Istio s security model  weight  10 owner  istio wg security maintainers test  n a      This document aims to describe the security posture of Istio s various components  and how possible attacks can impact the system      Components  Istio comes with a variety of optional components that will be covered here  For a high level overview  see  Istio Architecture   docs ops deployment architecture    Note that Istio deployments are highly flexible  below  we will primarily assume the worst case scenarios       Istiod  Istiod serves as the core control plane component of Istio  often serving the role of the  XDS serving component   docs concepts traffic management   as well as the mesh  mTLS Certificate Authority   docs concepts security     Istiod is considered a highly privileged component  similar to that of the Kubernetes API server itself    It has high Kubernetes RBAC privileges  typically including  Secret  read access and webhook write access    When acting as the CA  it can provision arbitrary certificates    When acting as the XDS control plane  it can program proxies to perform arbitrary behavior   As such  the security of the cluster is tightly coupled to the security of Istiod  Following  Kubernetes security best practices  https   kubernetes io docs concepts security   around Istiod access is paramount       Istio CNI plugin  Istio can optionally be deployed with the  Istio CNI Plugin  DaemonSet    docs setup additional setup cni    This  DaemonSet  is responsible for setting up networking rules in Istio to ensure traffic is transparently redirected as needed  This is an alternative to the  istio init  container discussed  below   sidecar proxies    Because the CNI  DaemonSet  modifies networking rules on the node  it requires an elevated  securityContext   However  unlike  Istiod   istiod   this is a   node local   privilege  The implications of this are discussed  below   node compromise    Because this consolidates the elevated privileges required to setup networking into a single pod  rather than  every  pod  this option is generally recommended       Sidecar Proxies  Istio may  optionally   docs overview dataplane modes   deploy a sidecar proxy next to an application   The sidecar proxy needs the network to be programmed to direct all traffic through the proxy  This can be done with the  Istio CNI plugin   istio cni plugin  or by deploying an  initContainer    istio init   on the pod  this is done automatically if the CNI plugin is not deployed   The  istio init  container requires  NET ADMIN  and  NET RAW  capabilities  However  these capabilities are only present during the initialization   the primary sidecar container is completely unprivileged   Additionally  the sidecar proxy does not require any associated Kubernetes RBAC privileges at all   Each sidecar proxy is authorized to request a certificate for the associated Pod Service Account       Gateways and Waypoints  Gateways and Waypoints act as standalone proxy deployments  Unlike  sidecars   sidecar proxies   they do not require any networking modifications  and thus don t require any privilege   These components run with their own service accounts  distinct from application identities       Ztunnel  Ztunnel acts as a node level proxy  This task requires the  NET ADMIN    SYS ADMIN   and  NET RAW  capabilities  Like the  Istio CNI Plugin   istio cni plugin   these are   node local   privileges only  The Ztunnel does not have any associated Kubernetes RBAC privileges   Ztunnel is authorized to request certificates for any Service Accounts of pods running on the same node  Similar to  kubelet  https   kubernetes io docs reference access authn authz node    this explicitly does not allow requesting arbitrary certificates  This  again  ensures these privileges are   node local   only      Traffic Capture Properties  When a pod is enrolled in the mesh  all incoming TCP traffic will be redirected to the proxy  This includes both mTLS HBONE traffic and plaintext traffic  Any applicable  policies   docs tasks security authorization   for the workload will be enforced before forwarding the traffic to the workload   However  Istio does not currently guarantee that  outgoing  traffic is redirect to the proxy  See  traffic capture limitations   docs ops best practices security  understand traffic capture limitations   As such  care must be taken to follow the  securing egress traffic   docs ops best practices security  securing egress traffic  steps if outbound policies are required      Mutual TLS Properties   Mutual TLS   docs concepts security  mutual tls authentication  provides the basis for much of Istio s security posture  Below explains various properties mutual TLS provides for the security posture of Istio       Certificate Authority  Istio comes out of the box with its own Certificate Authority   By default  the CA allows authenticating clients based on either of the options below    A Kubernetes JWT token  with an audience of  istio ca   verified with a Kubernetes  TokenReview   This is the default method in Kubernetes Pods    An existing mutual TLS certificate    Custom JWT tokens  verified using OIDC  requires configuration    The CA will only issue certificates that are requested for identities that a client is authenticated for   Istio can also integrate with a variety of third party CAs  please refer to any of their security documentation for more information on how they behave       Client mTLS    In sidecar mode  the client sidecar will  automatically use TLS   docs ops configuration traffic management tls configuration  auto mtls  when connecting to a service that is detected to support mTLS  This can also be  explicitly configured   docs ops configuration traffic management tls configuration  sidecars   Note that this automatic detection relies on Istio associating the traffic to a Service   Unsupported traffic types   docs ops configuration traffic management traffic routing  unmatched traffic  or  configuration scoping   docs ops configuration mesh configuration scoping   can prevent this   When  connecting to a backend   docs concepts security  secure naming   the set of allowed identities is computed  at the Service level  based on the union of all backend s identities     In ambient mode  Istio will automatically use mTLS when connecting to any backend that supports mTLS  and verify the identity of the destination matches the identity the workload is expected to be running as   These properties differ from sidecar mode in that they are properties of individual workloads  rather than of the service  This enables more fine grained authentication checks  as well as supporting a wider variety of workloads         Server mTLS  By default  Istio will accept mTLS and non mTLS traffic  often called  permissive mode    Users can opt in to strict enforcement by writing  PeerAuthentication  or  AuthorizationPolicy  rules requiring mTLS   When mTLS connections are established  the peer certificate is verified  Additionally  the peer identity is verified to be within the same trust domain  To verify only specific identities are allowed  an  AuthorizationPolicy  can be used      Compromise types explored  Based on the above overview  we will consider the impact on the cluster if various parts of the system are compromised  In the real world  there are a variety of different variables around any security attack     How easy it is to execute   What prior privileges are required   How often it can exploited   What the impact is  total remote execution  denial of service  etc    In this document  we will primarily consider the worst case scenario  a compromised component means an attacker has complete remote code execution capabilities       Workload compromise  In this scenario  an application workload  pod  is compromised   A pod   may  have access  https   kubernetes io docs tasks configure pod container configure service account  opt out of api credential automounting  to its service account token  If so  a workload compromise can move laterally from a single pod to compromising the entire service account     In the sidecar model  the proxy is co located with the pod  and runs within the same trust boundary  A compromised application can tamper with the proxy through the admin API or other surfaces  including exfiltration of private key material  allowing another agent to impersonate the workload  It should be assumed that a compromised workload also includes a compromise of the sidecar proxy   Given this  a compromised workload may    Send arbitrary traffic  with or without mutual TLS    These may bypass any proxy configuration  or even the proxy entirely    Note that Istio does not offer egress based authorization policies  so there is no egress authorization policy bypass occurring    Accept traffic that was already destined to the application  It may bypass policies that were configured in the sidecar proxy   The key takeaway here is that while the compromised workload may behave maliciously  this does not give them the ability to bypass policies in  other  workloads     In ambient mode  the node proxy is not co located within the pod  and runs in another trust boundary as part of an independent pod   A compromised application may send arbitrary traffic  However  they do not have control over the node proxy  which will chose how to handle incoming and outbound traffic   Additionally  as the pod itself doesn t have access to a service account token to request a mutual TLS certificate  lateral movement possibilities are reduced     Istio offers a variety of features that can limit the impact of such a compromise     Observability   docs tasks observability   features can be used to identify the attack     Policies   docs tasks security authorization   can be used to restrict what type of traffic a workload can send or receive       Proxy compromise   Sidecars  In this scenario  a sidecar proxy is compromised  Because the sidecar and application reside in the same trust domain  this is functionally equivalent to the  Workload compromise   workload compromise        Proxy compromise   Waypoint  In this scenario  a  waypoint proxy   gateways and waypoints  is compromised  While waypoints do not have any privileges for a hacker to exploit  they do serve  potentially  many different services and workloads  A compromised waypoint will receive all traffic for these  which it can view  modify  or drop   Istio offers the flexibility of  configuring the granularity of a waypoint deployment   docs ambient usage waypoint  useawaypoint   Users may consider deploying more isolated waypoints if they require stronger isolation   Because waypoints run with a distinct identity from the applications they serve  a compromised waypoint does not imply the user s applications can be impersonated       Proxy compromise   Ztunnel  In this scenario  a  ztunnel   ztunnel  proxy is compromised   A compromised ztunnel gives the attacker control of the networking of the node   Ztunnel has access to private key material for each application running on it s node  A compromised ztunnel could have these exfiltrated and used elsewhere  However  lateral movement to identities beyond co located workloads is not possible  each ztunnel is only authorized to access certificates for workloads running on its node  scoping the blast radius of a compromised ztunnel       Node compromise  In this scenario  the Kubernetes Node is compromised  Both  Kubernetes  https   kubernetes io docs reference access authn authz node   and Istio are designed to limit the blast radius of a single node compromise  such that the compromise of a single node does not lead to a  cluster wide compromise   cluster api server compromise    However  the attack does have complete control over any workloads running on that node  For instance  it can compromise any co located  waypoints   proxy compromise   waypoint   the local  ztunnel   proxy compromise   ztunnel   any  sidecars   proxy compromise   sidecars   any co located  Istiod instances   istiod compromise   etc       Cluster  API Server  compromise  A compromise of the Kubernetes API Server effectively means the entire cluster and mesh are compromised  Unlike most other attack vectors  there isn t much Istio can do to control the blast radius of such an attack  A compromised API Server gives a hacker complete control over the cluster  including actions such as running  kubectl exec  on arbitrary pods  removing any Istio  AuthorizationPolicies   or even uninstalling Istio entirely       Istiod compromise  A compromise of Istiod generally leads to the same result as an  API Server compromise   cluster api server compromise   Istiod is a highly privileged component that should be strongly protected  Following the  security best practices   docs ops best practices security  is crucial to maintaining a secure cluster