This page provides brief definitions and links to more information of terms that are used in the Anthos Service Mesh documentation.


Anthos Workload Identity
a tuple of trust domain, namespace, and service account. It has a SPIFFE identity format of spiffe://<workload_identity_pool>/ns/<namespace>/sa/<serviceaccount> in Anthos workload x509 certificates. For other credential types (e.g., OIDC tokens), the format may vary.


Canonical Service
A label applied to workloads in Anthos Service Mesh that allows you to group one or more workloads as a logical service within the service mesh. A workload belongs to exactly one canonical service, whereas it can belong to multiple Kubernetes services. A canonical service is identified by a name and a namespace, and can be further divided into one or more canonical revisions.
control plane

A control plane is a set of system services that configure the mesh or a subset of the mesh to manage the communication between the workload instances within. Anthos Service Mesh 1.9 and later provides two control planes:

  • Google-managed control plane: This is a fully-managed Google Cloud service that you only need to configure, while Google handles its reliability, upgrades, scaling and security for you.

  • In-cluster control plane: This is a Google-supported distribution of istiod that you install on your cluster. When you install Anthos Service Mesh with istiod, you are responsible for upgrading and for configuring security and scaling.

Although the control plane distributes its configuration to the sidecar proxies, the control plane does not directly participate in handling traffic for workloads in the mesh.


data plane
The data plane is the part of the mesh that directly handles communication between workload instances. Anthos Service Mesh's data plane uses proxies deployed as sidecars to mediate and control all TCP traffic that your mesh services send and receive.


A fleet (formerly known as an environ) lets you organize clusters to make multi-cluster management easier. Registering your clusters in a fleet simplifies the management of a multi-cluster mesh by introducing the concept of "sameness" for identity, namespaces and services. If you have clusters in different projects, you need to register the clusters with the fleet host project rather than the project that the cluster was created in. To learn more about fleets, see Introducing fleets.



Identity is a fundamental security infrastructure concept. The Anthos Service Mesh identity model is based on a first-class workload identity. At the beginning of service-to-service communication, the two parties exchange credentials with their identity information for mutual authentication purposes.

Clients check the server's identity against their secure naming information to determine if the server is authorized to run the service.

Servers check the client's identity to determine what information the client can access. Servers decide whether to allow the access based on the configured authorization policies.

Using identity, servers can audit the time information was accessed and what information was accessed by a specific client. They can also charge clients based on the services they use and reject any clients that failed to pay their bill from accessing the services.

The Anthos Service Mesh identity model is flexible and granular enough to represent a human user, an individual service, or a group of services. On platforms without first-class service identity, Anthos Service Mesh can use other identities that can group service instances, such as service names.

Anthos Service Mesh supports the following service identities on different platforms:

  • Kubernetes: Kubernetes service account

  • Google Kubernetes Engine: Google Cloud service account

  • Google Cloud: Google Cloud service account

ingress gateway

An ingress gateway represents a load balancer to handle incoming traffic entering from outside the mesh. You use Istio Gateway resources to configure the load balancer and you create virtual services and authentication policies to control how incoming traffic is secured and routed to your workloads.


istiod (the "d" is for "daemon)" is the consolidated monolithic binary that provides control plane services. Before Anthos Service Mesh 1.5, the control plane services were provided by separate components called Pilot, Citadel, Mixer, and Galley.


A custom resource that you use to configure the in-cluster control plane. For more information, see Enabling optional features.


Managed Instance Group (MIG)
Lets you operate applications on multiple identical VMs, starting with a minimum MIG size of one VM. You can make your workloads scalable and highly available by taking advantage of automated MIG services, including: autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating. For more information, see managed instance groups (MIGs).
Mesh CA
The name of the Google-managed certificate authority that manages mTLS certificates. Mesh CA is installed by default when you install Anthos Service Mesh.
mutual TLS
Anthos Service Mesh uses mutual TLS (mTLS) for authentication and encryption between services in the mesh. mTLS makes it possible for workloads to verify each other's identities and authenticate with each other. You might be familiar with simple TLS through its use in HTTPS to allow browsers to trust web servers and to encrypt the data that is exchanged. When simple TLS is used, the client establishes that the server can be trusted by validating its certificate. mTLS is an implementation of TLS in which both client and server present certificates to each other and verify each other's identities.


Anthos Service Mesh uses a simplified definition of network based on general connectivity. Workload instances are on the same network if they are able to communicate directly, without a gateway.


overlay file
A YAML file containing an IstioOperator custom resource (CR). You use overlay files to configure the control plane. You can override the default control plane configuration and enable Supported optional features in a YAML file that you pass to istioctl install or to the install_asm script. You can layer on more overlays, and each overlay file overrides the configuration on the previous layers. See Enabling optional features for the YAML that you can use to enable features that aren't enabled by default.


primary cluster
A primary cluster is a cluster with a control plane. A single mesh can have more than one primary cluster for high availability or to reduce latency. In the Istio 1.7 documentation, a multi-primary deployment is referred to as a replicated control plane.


remote cluster
A remote cluster is a cluster that connects to a control plane residing outside of the cluster. A remote cluster can connect to a control plane running in a primary cluster or to an external control plane.
A revision represents a snapshot-in-time of application code version and configuration. When you install or upgrade Anthos Service Mesh, a When you install or upgrade Anthos Service Mesh, a revision label is added to the control plane. To enable automatic sidecar injection, you add the revision label to your namespaces and restart your Pods. The revision label associates the Pods in a namespace with a particular control plane revision.
revision-based upgrade
Migrations from OSS Istio and upgrades follow the revision-based upgrade process (referred to as "canary upgrades" in the Istio documentation). With a revision-based upgrade, the new revision of the control plane is installed alongside the existing control plane. You then move some of your workloads to the new revision, which lets you monitor the effect of the upgrade with a small percentage of the workloads before migrating all of the traffic to the new revision.


secure naming
Server identities are encoded in certificates, but service names are retrieved through the discovery service or DNS. The secure naming information maps the server identities to the service names. A mapping of identity A to service name B means "A is authorized to run service B". The control plane watches the apiserver, generates the secure naming mappings, and distributes them securely to the sidecar proxies.
service mesh
A service mesh or simply mesh is an infrastructure layer that enables managed, observable and secure communication between workload instances.
A pattern for running a utility or helper alongside a workload. If you are using Kubernetes, sidecars run alongside the workload container in a pod. When discussing service mesh, the word "sidecar" is often used to refer to the proxy.


trust domain

Trust domain corresponds to the root of trust of a system and is part of a workload identity.

Anthos Service Mesh uses a trust domain to create all identities within a mesh. For example, in the SPIFFE ID spiffe://, the substring specifies that the workload is from a trust domain called

When using the Mesh CA, the trust domain is automatically generated by Anthos Service Mesh. It is based on the cluster's workload pool.

You can have one or more trust domains in a multi-cluster mesh, as long as the clusters share the same root of trust.


A workload is a containerized application, service, or other program such as a batch job or daemon running on a platform. The platform could be a Kubernetes cluster, virtual machine, or another environment such as Google Distributed Cloud Virtual for Bare Metal. Workloads have names, namespaces, and unique ids. On Kubernetes, a workload typically corresponds to a Deployment, but there are other types of workloads, such as a StatefulSet.
allows you to describe non-Kubernetes-Pod endpoints that should be part of the mesh, and treat them the same as a Kubernetes Pod. In our case, each VM is registered as a WorkloadEntry in the mesh. For more information, see
describes a collection of workload instances. See WorkloadGroup.
Workload Identity pool
The trust boundary, also known as a trust domain of an Anthos Service Mesh.