Glossary

Adapters are plug-ins to Mixer, Istio’s policy and telemetry component, which enable it to interface with an open-ended set of 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.

Learn more about adapters.

Annotation refers to a Kubernetes annotation attached to a resource, for example a pod. For a list of valid Istio-specific annotations, see Resource Annotations.

Attributes control the runtime behavior of services running in the mesh. Attributes are named and typed pieces of metadata describing ingress and egress traffic and the environment this traffic occurs in. An Istio attribute carries a specific piece of information such as the error code of an API request, the latency of an API request, or the original IP address of a TCP connection. For example:

request.path: xyz/abc
request.size: 234
request.time: 12:34:56.789 04/17/2017
source.ip: 192.168.0.1
destination.workload.name: example

Attributes are used by Istio’s policy and telemetry features.

A cluster is set of compute nodes that run containerized applications. Typically, the compute nodes comprising a cluster can reach each other directly. Clusters limit external access through rules or policies.

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. All instances of a control plane in a single mesh share the same configuration source.

Custom resource definitions (CRDs) are extensions of the default Kubernetes API. Istio uses the Kubernetes CRD API for configuration, even for non-Kubernetes Istio deployments.

The data plane is the part of the mesh that directly controls communication between workload instances. Istio’s data plane uses intelligent Envoy proxies deployed as sidecars to mediate and control all traffic that your mesh services send and receive.

A remote service that Envoy interacts with on behalf of a source workload.

The high-performance proxy that Istio uses to mediate inbound and outbound traffic for all services in the service mesh. Learn more about Envoy.

A failure domain is a physical or logical section of the computing environment that is negatively affected when a critical device or service experiences problems.

For an Istio deployment, failure domains could encompass multiple availability zones of your platform.

Identity is a fundamental security infrastructure concept. The Istio 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 base that determination 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 Istio 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, Istio can use other identities that can group service instances, such as service names.

Istio supports the following service identities on different platforms:

• Kubernetes: Kubernetes service account

• GKE/GCE: GCP service account

• GCP: GCP service account

• AWS: AWS IAM user/role account

• On-premises (non-Kubernetes): user account, custom service account, service name, Istio service account, or GCP service account. The custom service account refers to the existing service account just like the identities that the customer’s Identity Directory manages.

Typically, the trust domain specifies the mesh the identity belongs to.

The Istiod component is the consolidated monolithic control plane binary that encapsulates the functions of Pilot, Citadel, Mixer, and Galley.

Learn more about Istiod.

A managed control plane is a control plane that cloud providers manage for their customers. Managed control planes reduce the complexity of user deployments and typically guarantee some level of performance and availability.

Mesh federation is the act of exposing services between meshes and enabling communication across mesh boundaries. Each mesh may expose a subset of its services to enable one or more other meshes to consume the exposed services. You can use mesh federation to enable communication between meshes in a multi-mesh deployment.

Micro-segmentation is a security technique that creates secure zones in cloud deployments and allows organizations to isolate workloads from one another and secure them individually.

The Istio component is responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from Envoy and other services. Learn more about Mixer.

Handlers represent fully configured Mixer adapters. A single binary adapter can be used with different configurations, each such configuration is known as a handler. At runtime, Mixer routes instances to one or more handlers.

An instance represents a chunk of Mixer data that is produced by inspecting a set of request attributes and applying the operator-supplied configuration. Instances are delivered to individual handlers, on their way to infrastructure backends.

Multi-mesh is a deployment model that consists of two or more service meshes. Each mesh has independent administration for naming and identities but you can expose services between meshes through mesh federation. The resulting deployment is a multi-mesh deployment.

Multicluster is a deployment model that consists of a mesh with multiple clusters.

Mutual TLS provides strong service-to-service authentication with built-in identity and credential management. Learn more about mutual TLS authentication.

Operators are a method of packaging, deploying and managing a Kubernetes application. For more information, see Operator pattern.

The Istio component that programs the Envoy proxies, responsible for service discovery, load balancing, and routing.

A Pod is a group of one or more containers (such as Docker containers), with shared storage and network, and a specification for how to run the containers. Pods are the workload instances in a Kubernetes deployment of Istio.

Routing rules, which you configure in a virtual service, define the paths that requests follow within the service mesh. With routing rules, you can define conditions to route traffic addressed to the virtual service’s host to specific destination workloads. Routing rules let you control traffic for tasks like A/B testing, canary rollouts, and staged rollouts with percentage-based traffic splits.

Provides a mapping between a service name and the workload instance principals that are authorized to run the workload instances implementing a service.

A delineated group of related behaviors within a service mesh. Services are identified using a service name, and Istio policies such as load balancing and routing are applied using these names. A service is typically materialized by one or more service endpoints, and may consist of multiple service versions.

The agent that is using a service.

The network-reachable manifestation of a service. Workload instances expose service endpoints but not all services have service endpoints.

A service mesh or simply mesh is an infrastructure layer that enables managed, observable and secure communication between workload instances.

Service names combined with a namespace are unique within a mesh. In a multicluster mesh, for example, the bar service in the foo namespace in cluster-1 is considered the same service as the bar service in the foo namespace in cluster-2.

Since identities are shared within the service mesh, workload instances can authenticate communication with any other workload instance within the same service mesh.

A name that uniquely identifies a service within the service mesh. A service may not be renamed while maintaining its identity. A service may have multiple versions, but a service name is version-independent.

The agent that manages a service within a service mesh by manipulating configuration state and monitoring the service’s health via a variety of dashboards.

The agent that creates a service.

Istio maintains an internal service registry containing the set of services, and their corresponding service endpoints, running in a service mesh. Istio uses the service registry to generate Envoy configuration.

Istio does not provide service discovery, although most services are automatically added to the registry by Pilot adapters that reflect the discovered services of the underlying platform (Kubernetes, Consul, plain DNS). Additional services can also be registered manually using a ServiceEntry configuration.

Distinct variants of a service, typically backed by different versions of a workload binary. Common scenarios where multiple service versions may be used include A/B testing and canary rollouts.

The downstream client of the Envoy proxy. Within the service mesh a source is typically a workload, but the source for ingress traffic may include other clients such as a browser or mobile app.

The Secure Production Identity Framework For Everyone (SPIFFE) Project defines a framework and a set of standards for identifying and securing communications between web-based services.

Learn more about SPIFFE.

TLS origination occurs when an Istio proxy (sidecar or egress gateway) is configured to accept unencrypted internal HTTP connections, encrypt the requests, and then forward them to HTTPS servers that are secured using simple or mutual TLS. This is the opposite of TLS termination where an ingress proxy accepts incoming TLS connections, decrypts the TLS, and passes unencrypted requests on to internal mesh services.

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

Istio uses a trust domain to create all identities within a mesh. Every mesh has an exclusive trust domain.

For example in spiffe://mytrustdomain.com/ns/default/sa/myname the substring identifying the mesh is: mytrustdomain.com. This substring is the trust domain of the mesh.

The process of changing the trust domain of an Istio mesh.

A binary deployed by operators to deliver some function of a service mesh application. Workloads have names, namespaces, and unique ids. These properties are available in policy and telemetry configuration using the following attributes:

• source.workload.name, source.workload.namespace, source.workload.uid
• destination.workload.name, destination.workload.namespace, destination.workload.uid

In Kubernetes, a workload typically corresponds to a Kubernetes deployment, while a workload instance corresponds to an individual pod managed by the deployment.

A single instantiation of a workload’s binary. A workload instance can expose zero or more service endpoints, and can consume zero or more services.

Workload instances have a number of properties:

• Name and namespace
• Unique ID
• IP Address
• Labels
• Principal

These properties are available in policy and telemetry configuration using the many source.* and destination.* attributes.

The verifiable authority under which a workload instance runs. Istio’s service-to-service authentication is used to produce the workload principal. By default workload principals are compliant with the SPIFFE ID format.

Workload instance principals are available in policy and telemetry configuration using the source.principal and destination.principal attributes.