Tetrate Service ExpressVersion: LatestTetrate Glossary and Definitions
Tetrate Concepts
Organization
The 'Organization' is the root of the object hierarchy. The Organization contains a hierarchy of tenants, users, teams, clusters and workspaces. The Organization is also the location where TSB-wide settings are defined.
In TSB, you can define the name and attributes of the root Organization to reflect your Enterprise hierarchy.
In TSE, the Organization name is hard-coded to tse and is not editable.
Organization Users
Organizations are tied to an Identity Provider (IdP). Users and teams, representing the organizational structure, are periodically synchronized from the IdP you provide, in order to make them available for access policy configuration.
TSB lets you define multiple Teams, with associated fine-grained Roles, and then map users to team membership.
TSE operates with a default tse-admin user, and a single team and role. Additional users can be synchronized from the IdP, and they all inherit the single team membership and role.
Tenant
A Tenant is a self-contained entity within an organization in the Service Bridge object hierarchy. Tenants can be business units, organization units, or any logical grouping that matches a corporate structure.
Whereas TSB supports multiple tenants and a rich organizational hierarchy, TSE provides a single tse tenant and a flat hierarchy.
Workspace
A workspace is a set of one or more namespaces, and is defined by the Platform Owner. The namespaces may span multiple K8s clusters.
A user can assign configurations or policies to a Workspace, and TSB/TSE then translates these into Istio per-namespace configurations internally. Workspaces provide a convenient higher-level abstraction that align with an organization’s applications, which typically span multiple namespaces and/or clusters.
Group
In the context of a workspace, a Group is a collection of related Istio configuration types. For example, a ‘Security Group’ contains all of the configuration relating to access control, authentication and authorization for the Workspace. Traffic Groups and Gateway Groups similarly contain configuration relating to traffic management and ingress gateways respectively.
A Group-in-a-Workspace is typically the smallest, self-contained configuration set that can be managed independently.
- Security Group: A Security Group contains all security-related Istio configurations for a Workspace. This includes mTLS and authentication policies.
- Traffic Group: A Traffic Group contains all traffic management-related Istio configurations for a Workspace. This includes rate limiting, canary and traffic splitting configurations.
- Gateway Group: A Gateway Group defines the Ingress Gateway policies for a workspace. These policies are applied to the Ingress Gateways that manage traffic to services in that workspace.
Direct and Bridged Mode
A Workspace-and-Group is configured in either Direct or Bridged mode.
- In Direct mode, the user configures the Workspace-and-Group using Istio configuration of the appropriate type. For example, a user can assign Istio security configuration to a Workspace and its Security Group. This configuration is then validated and deployed to the underlying mesh instances.
- In Bridged mode, the user configures the Workspace-and-Group exclusively using Tetrate's higher-level abstractions. These abstractions are designed to be simpler and better aligned with the common use cases, such as defining Ingress for services in a workspace. These abstractions are translated into Istio configuration and deployed to the underlying mesh instances.
Direct and Bridged mode are applied at a fine-grained level. For example, for a given Workspace, the Security and Traffic Groups could operate in Direct mode, and the Gateway Group in Bridged mode. This is possible because the Workspace's configuration is fully covered by the three Groups, and the Groups do not overlap or interfere with each other.
Services and Applications
Service
A Service is a network servable/addressable destination that is identifiable and independently authenticated. This destination is served by a set of Service Instances - individual workloads that host the service.
In Kubernetes, a Service corresponds to the Service resource type. Outside of Kubernetes, a Service can identify other addressable workloads, such as a VM-based workload or a third-party API.
Services have the following properties:
- Identity: Multiple instances of a service may run across different nodes to provide a scalable service in aggregate. All instances are verified and validated with the same service identity. The Service Identity is a SPIFFE SVID.
- Endpoint: The Service Endpoint is a FQDN, URI path or a class with a collection of methods.
- Endpoint Method: Services that host the endpoints could be of different protocol. These define the set of verbs that are specific to the protocol that the service delivers. For example, HTTP verbs for each endpoint could be methods to express the CRUD operations, for gRPC it would be the methods that is part of the protobuf class.
- Hostname: The Service can be discovered using a well-known hostname, via the local DNS service
- Network/API Endpoint: The target (destination) for traffic submitted to the service
- Kind: The Service Kind is the type or class of service. The Kind is declared as a tuple {Protocol, Internal|External}, such as {HTTP, Internal} or {SQL, Internal}, or {grpc, External}. 'External' means that the service is consumed via a Gateway hop.
- Visibility: The Visibility takes the values Private, Shared, or Public, and controls how the service is presented through the Service Registry
Service Authentication uses mTLS and SPIFFE standards. Service Authorization is a permission decision, based on the authentication of both parties in a transaction and the security policies that define permitted actions. Authorization is centrally defined and evaluated locally for each transaction. Service Access Control is the access decision, based on the permission (an operation is allowed) and additional policies, such as rate limiting or quotas.
Workload
A workload is an individual, addressable service component.
In Kubernetes, a workload corresponds to an individual pod. In other environments, a 'workload' may refer to a single VM or an application running within that VM.
Service Registry
The Service Registry is a machine–readable list of running available services that are callable from another service or by a user. These services are Discoverable, Addressable, Routable, and Controllable.
The Tetrate-managed mesh uses the service registry dynamically to discover service instances, determine how to route traffic, and to understand additional access control parameters.
Application
An Application is a logical grouping of Services which are accessible through one or more APIs.
An Application resource is a convenience in TSE to define a set of services and the APIs that they expose, that can be consumed by end-users or other services. The contents of the Application, like an 'object', are opaque.
API
An API is an endpoint that serves a feature provided by an Application.
An API is a resource similar to an Ingress Resource. The API Resource wraps an OAS definition, decorated with Tetrate-specific annotations if needed. The API Resource also contains the Application resource (application) that contains the API, the Ingress Gateway that exposes the API, and the Kubernetes service that implements the API.
An API Resource presents a convenient way for an Application Owner to expose APIs that are implemented by an Application.
Architectural Components
More information can be found in the TSB Architecture page or the TSE Architecture page.
Management Plane
The Management Plane is the primary access point to everything within your Tetrate-managed environment. It configures networking, security, and observability, exposing a UI, CLI and API to make updates and changes. It provides centralized control in a multi control plane service mesh.
Central Control Plane
The central Control Plane is part of the Management Plane. Its role is to take the "configuration intent" provided by the Management Plane and the "runtime state" provided by each managed mesh, and reconcile these into Istio configuration. It then distributes the configuration reliably to each remote mesh.
Control Plane
The edge Control Plane is deployed in each managed Kubernetes cluster. It takes responsibility for deploying an Istio instance in that cluster, for receiving and applying Istio configuration from the central Control Plane, and for collecting and forwarding telemetry and other runtime data to the Management Plane.
Istio
Istio is the leading service mesh implementation. The edge Control Plane deploys an Istio instance into each cluster that is managed (has been "onboarded"), and uses Istio as the local point of control within the cluster to manage network activities.
Istio provides encryption, security, traffic management and more by actively configuring the mesh dataplane in the cluster.
Dataplane
Powered by Envoy, the mesh dataplane intercepts and controls network traffic within a cluster, operating at layer 7. It interoperates with various gateways which handle Ingress (into the cluster) and Egress (out of the cluster) transactions. The dataplane is implemented as a set of Sidecar Proxies.
Sidecar Proxy
A Sidecar Proxy is an instance of Envoy, deployed beside an instance of your application. It transparently intercepts traffic into and out of the application, allowing the service mesh to implement its traffic management, security, and observability features. This is in contrast to a Load Balancer or Gateway which are deployed separately from your application.
Gateways
A Gateway is a proxy operating at the edge of a mesh, receiving incoming or outgoing HTTP/TCP connections. Gateways are typically implemented using L7 proxies (Envoy) and perform security and traffic management functions (authentication, TLS termination, load balancing, etc). They are key points of control for policy enforcement.
In a Tetrate deployment, there are several types of Gateway to be found.
Ingress (or App) Gateway
An Ingress (or App) Gateway is deployed at the boundary of a workload environment such as a mesh. The purpose of the Ingress Gateway is to receive traffic destined for services within the environment, to apply security and traffic management policies, and to forward each request to the target service.
An Ingress Gateway is typically deployed in each Kubernetes / Mesh cluster, handling external traffic (e.g. from the public internet) for services within that single cluster.
Edge Gateway
An Edge Gateway (sometimes referred to as a 'Tier-1 Gateway') is deployed at the external boundary of customer-operated infrastructure. The purpose of the Edge Gateway is to receive traffic destined for services within the infrastructure, to apply policies, and then to forward each request to the next hop within the infrastructure.
An Edge Gateway is typically deployed in front of multiple workload environments, such as multiple EKS clusters. It load-balances incoming traffic across these clusters, achieving high-availability and load distribution.
EastWest Gateway
An EastWest Gateway is deployed at the boundary of a workload environment such as a mesh. Unlike an Ingress Gateway, its purpose is not to handle external traffic; rather, an EastWest Gateway handles traffic from peer environments such as other meshes.
An EastWest gateway can be used to connect internal mesh networks so that services in one cluster can access services in another, without exposing any of these services to public access. It is used in Tetrate’s high-availability solution for internal services.
Egress Gateway
An Egress Gateway is deployed at the boundary of a workload environment such as a mesh. Its purpose is to handle traffic leaving the mesh, from internal services that wish to consume external (e.g. public) services and APIs.
An Egress Gateway provides a point of control when accessing external services. It may be used to apply policies such as access control, or to add authentication tokens necessary to use the external service.
Transit Gateway
A Transit Gateway is located next to non-mesh workloads, such as virtual machines. It is used to extend the mesh boundary closer to the external workload.
API Gateway
An API Gateway is a form of Ingress Gateway that is configured for the purposes of delivering API traffic. API Gateways are typically configured using API specifications (e.g. OpenAPI Spec) rather than FQDN-and-path, and they often allow users to configure API-specific policies such as rate-limiting, authentication and CORS Header management.
Unified Gateway
As of the 1.9.0 release, Tetrate solutions use a single Gateway implementation, called a 'Unified Gateway'. The Unified Gateway can take on the roles of Ingress (App), Edge, East-West, Egress and Transit gateways.
Security Domains
A Security Domain is a free-structured collection of configuration constructs: Tenants, Workspaces and Security Groups, taken from anywhere in the configuration hierarchy. For example, a Security Domain may represent "trusted internal sources of traffic" or "PCI services".
You can define security rules using security domains as sources or targets of traffic.
Security Domains allow for a resource-centric way of defining security policies. For example, when you add a new resource (e.g. a Workspace), you do not need to identify every rule that it may require and update or create copies of each. Instead, you can add that resource to a pre-existing Security Domain (“my new resource is one of these”) and Tetrate Service Bridge will update all applicable rules.
Security Domains are only supported in Tetrate Service Bridge. They are not available in Tetrate Service Express.
Resource Naming Constraints
As of the 1.8.0 release, Tetrate resource names must follow the DNS label standard as defined in RFC 1123. Resource names must:
- contain at most 63 characters
- contain only lowercase alphanumeric characters or '-'
- start with an alphanumeric character
- end with an alphanumeric character
This validation is enforced only when creating new resources; existing resources that do not conform to these standards can still be updated and deleted.