About policies

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:

• CORS
• External auth, such as for API keys, LDAP, or OPA policies
• Failover
• Fault injection
• Header manipulation
• Mirroring
• 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
• CSRF
• GraphQL allowed queries
• GraphQL query caching
• HTTP buffer filter
• JWT
• Proxy protocol
• Transformation
• 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:

• Access
• Access log
• Web Assembly (Wasm)

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.