With traffic policies, you can specify how you want to manipulate and respond to incoming requests in your service mesh. For example, you might want to add or remove header information before forwarding the request to your service, implement retries, timeouts, and failover scenarios, or ensure that services use mutual TLS (mTLS) when communicating with each other.
For an overview of supported traffic policies in Gloo, see Supported policies.
Apply policies to resources
Policies might apply to the following resources:
- Destinations: Destinations determine where incoming requests are routed to. A destination can be a Kubernetes Service, a Gloo VirtualDestination in a multi-cluster setup, or a Gloo ExternalService custom resource that you use to reach endpoints that are outside your service mesh.
- Listeners: Listeners are the virtual gateways and ports that a gateway workload listens for incoming traffic on. You must apply a listener policy to a Gloo VirtualGateway custom resource, not the gateway workload directly.
- Route: Routes define how to match an incoming request, and what actions you want to perform on a matched request. For example, you can decide to forward the request to a destination in the service mesh, directly respond to the request without forwarding, or manipulate and redirect requests. Routes are defined in a Gloo RouteTable custom resource.
- Workloads: A workload represents the app that responds to incoming request. For example, you can have Kubernetes workloads such as Deployments or StatefulSets. Or, you can use an Istio WorkloadEntry that might run in a bare metal or virtual machine outside your Kubernetes cluster.
You can apply the policies by using Kubernetes labels and selectors that match the route table, virtual destination, or workload. Remember, all of these resources must be in the same workspace for the policy to apply the resource. To see what resources a policy might select, check the Kubernetes labels such as with the following commands.
kubectl get <KIND> <RESOURCE> -n <NAMESPACE> -l <KEY=VALUE> kubectl get all -A -l env=prod
Import and export policies to other workspaces
To federate Gloo resources across namespaces within a workspace, Gloo creates copies of the translated resources in each namespace. You can create the Gloo resource directly within the “source” workspace, or export the resource to another “target” workspace.
To understand policy behavior on imported resources, determine two factors:
- Whether the policy is client or server-side.
- What exported resource that the policy applies to.
Client and server-side policies
Policies are server or client-side, depending on which proxy enforces the policy.
Client-side: Client-side policies are enforced by the sending, outbound proxy (the workload's sidecar) before traffic is sent to the target workload. Client-side policies include the following:
- External auth, such as for API keys, LDAP, or OPA policies
- Fault injection
- Header manipulation
- Outlier detection
- Rate limit
- Retry and timeout
- TCP connection
Ingress client-side: If you use Gloo Mesh with Gloo Gateway, you can also apply the following ingress client-side policies:
- Client TLS
- GraphQL allowed queries
- GraphQL query caching
- HTTP buffer filter
- Proxy protocol
- Web application firewall (WAF)
Server-side: Server-side policies are enforced by the receiving, inbound proxy. In Gloo Mesh, this proxy is the sidecar proxy of the target workload. The policies are created in the namespace of the backing Kubernetes service. Server-side policies include the following:
Exported resources that policies can apply to
You cannot import or export policies across workspaces. However, policies might still apply to Gloo resources that you import and export to other workspaces. Flip through the following tabs for more information about how policy behavior changes based on the kind of resource that you import and export.
Routes that are exported via a route table keep their policies from the source workspace. Policies in the new, target workspace do not apply to imported routes. This way, the original resource owner can control how the host is accessed.
If you as the target workspace owner want to change the behavior of a route, you have two choices:
- Ask the original owner to add a policy in the source workspace.
- Create another route table in your current workspace.
Imported route table summary:
- ✅ The source workspace's policies still apply.
- ❌ The target workspace's policies do not apply.
Kubernetes services that are exported keep their server-side destination policies from the source workspace. In the target workspace, you can only apply client-side route policies to imported services. This way, the original resource owner can control access to the source service with server-side policies. But you as the target workspace owner can control the client-side behavior, such as to inject faults for resilience testing or manipulate headers.
Imported Kubernetes service summary:
- ✅ The source workspace's server-side policies still apply.
- ❌ The source workspace's client-side policies no longer apply.
- ❌ The target workspace's server-side policies do not apply.
- ✅ The target workspace's client-side policies do apply.
Virtual destinations that are exported do not keep any policies from the source workspace. Instead, you as the target workspace owner can apply your own client-side policies to the virtual destination or routes that are backed by the virtual destination. You can also apply your own server-side policies to the Kubernetes services that back the virtual destination.
This way, each team can set its own client and server-side policies for the virtual destination within their own workspace, but share the virtual destination configuration across teams.
Imported virtual destination summary:
- ❌ Neither the source workspace's server-side nor client-side policies apply.
- ✅ The target workspace's server-side policies do apply to the backing Kubernetes service of the imported virtual destination in the target workspace.
- ✅ The target workspace's client-side policies do apply.
Similar to virtual destinations, external services that are exported do not keep any policies from the source workspace. Instead, you as the target workspace owner can apply your own client-side policies to the external service or routes that are backed by the external service. You can also apply your own server-side policies to the external service.
This way, each team can set its own client and server-side policies for the external service within their own workspace, but share the external service configuration across teams.
Imported external service summary:
- ❌ The source workspace's policies no longer apply.
- ✅ The target workspace's policies do apply.