Supported policies in Gloo Mesh

Gloo Mesh supports a variety of policies to ensure network resiliency, traffic control, security, and observability for the microservices in your service mesh. Flip through the cards to learn about what policies are supported, why you want to use them, and what Gloo Mesh resource the policy can be applied to. To see an example policy setup, simply follow the links.

Type of policy Description Applied to
Failover Use a failover policy to reroute traffic to a different service in case of failure. For example, you can set up a failover policy to route traffic from one availability zone or region to another if that zone or region becomes unavailable. Destination
Fault injection Test the resilience of your apps by injecting delays and connection failures. With fault injections, you intentionally introduce errors, such as a failure of an upstream dependency to see how your app behaves and if it can recover from such an event. Route
Outlier detection Track the status of each upstream destination so that you can temporarily remove unhealthy destinations. An outlier can be any upstream app instance that is performing differently than other instances that back the Kubernetes service, Gloo Mesh virtual destination, or external service. For example, if an app instance responds with a 5xx HTTP error code most of the time, it is excluded from the Gloo Mesh load balancing. Destination
Retry Use retry settings to specify the maximum number of times a service mesh proxy can attempt to call a service in the mesh after the initial call failed. Route
Timeout With timeouts, you can specify how long the service mesh proxy waits for a service or host to respond before it is considered unavailable. Route
Type of policy Description Applied to
Mirroring Duplicate outgoing traffic, to test a new app. Mirroring, also referred to as shadowing, can be very useful if you want to send live traffic to a different version of your app to verify the app's behavior or set up canary testing. Route
Rate limiting Control the rate of requests to a destination or route. With rate limits, you can specify how many requests you want to allow to be passed to a particular service in a certain timeframe. For example, you might want to limit your service to receive only one request per second. Route or destination
Transformation Alter a request before matching and routing, such as with an Inja header template. For example, you might want to add or remove certain headers from the request or response that is routed in your service mesh. Route
Type of policy Description Applied to
Access policies Control access for workloads in your service mesh. Destination
CORS Enforce client-site access controls with cross-origin resource sharing (CORS). CORS is a browser mechanism that allows a client web app to access resources that are located outside of a specific domain. Route
CSRF Apply a CSRF filter to the gateway to help prevent cross-site request forgery attacks. A cross-site request forgery attack is a web security vulnerability where the attacker induces an authenticated user to perform an unwanted action on a trusted site. Route
External authentication and authorization Set up an external authentication and authorization, such as with basic, passthrough, API key, OAuth, OPA, or LDAP auth. Route or destination
Type of policy Description
Certificate Authority options Create a policy for custom CA certificates.
Vault Create a policy for Vault-managed certificates.
Type of policy Description Applied to
Access logs Configure how access logs are recorded for your services. Workload
Type of policy Description Applied to
WASM Add a Wasm filter to the Envoy sidecar proxy, for use cases such as customizing the endpoints and thresholds for your workloads. Workload