Import and export policies
Review how to import and export policies when using Gloo workspaces.
Overview
You can import and export resources across Gloo 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.
In general, Gloo workspaces are set up to give you control of your microservices. When it comes to sharing policies across workspaces, the following rules generally apply after you enable the VirtualDestinationWorkspacePolicyOverride
feature gate:
- Client-side policies that apply to imported virtual destinations keep the original policy from the source workspace, but can be overwritten by client-side policies in the target workspace. This way, each workspace owner can control the client-side policies that are applied to their own destinations.
- Policies that select workloads (
applyToWorkloads
) do not apply across workspaces, even if their underlying services are imported. - Policies that select routes (
applyToRoutes
) or the destinations of routes (applyToRouteDestination
) do still apply across workspaces. This way, you control how your services are accessed via the routes, even if those routes are exported to other workspaces.
Learn more about policy behavior on imported resources by determining:
- Whether the policy is client or server-side.
- What exported resource that the policy applies to.
- For more in-depth information about policies for delegated routes, see Route policy attachment.
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 ingress gateway) before traffic is sent to the workload in the cluster. Client-side policies include the following:
- Active healthcheck
- Client TLS
- CORS
- CSRF
- DLP
- External auth, such as for API keys, LDAP, or OPA policies
- Failover
- Fault injection
- GraphQL allowed query
- GraphQL persisted query cache
- Header manipulation
- HTTP buffer filter
- JWT
- Listener connection
- Load balancer and consistent hash
- Mirroring
- Outlier detection
- Proxy protocol
- Rate limit
- Retry and timeout
- TCP connection
- Transformation
- Gloo Mesh Enterprise (requires a service mesh): Trim proxy config
- Web application firewall (WAF)
Server-side (requires a service mesh): Server-side policies are enforced by the receiving, inbound proxy.
- If you use Gloo Mesh Gateway with Gloo Mesh Enterprise, this proxy is the sidecar proxy for your workloads.
- In a standalone Gloo Mesh Gateway deployment, your workloads do not have sidecar proxies and server-side policies are not supported.
Gloo Mesh Enterprise 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. Review the following sections for more information about how policy behavior changes based on the kind of resource that you import and export. To check the policies that are applied in your environment, you can review the translated Istio resources such as VirtualServices and DestinationRules that Gloo creates, such as in the Gloo UI.
Route tables
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.
For an overview of how delegated routes impact policy import and export, see Route table management.
Kubernetes services
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
Imported virtual destinations still keep their client-side policies. However, if you enable the VirtualDestinationWorkspacePolicyOverride
feature gate, then 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 for the following policies:
- ClientTLSPolicy
- ConnectionPolicy for TCP
- FailoverPolicy
- LoadBalancerPolicy
- OutlierDetectionPolicy
For ActiveHealthCheckPolicy and AdaptiveRequestConcurrencyPolicy, imported virtual destinations do not keep the client-side policies from the source workspace. You can still apply these client-side policies in the target workspace. Keep in mind that some client-side policies such as FaultInjectionPolicy do not support virtual destination selectors, and so these import guidelines do not apply to those policies.
This way, each team can set its own policies for the virtual destination within their own workspace, but share the virtual destination configuration across teams.
To enable the feature gate, see the Feature gates reference docs. Note that when you first enable this feature, virtual destinations with client-side policies experience dropped traffic until the configuration updates are propagated across clusters. Also, you cannot disable this feature after enabling.
Imported virtual destination summary:
- ✅ The source workspace’s client-side policies apply.
- ✅ The target workspace’s policies that apply to routes backed by the destinations do apply.
- ✅ If you enable the
VirtualDestinationWorkspacePolicyOverride
feature gate, then the target workspace’s client-side policies can override the imported source workspace’s client-side policies.
External services
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.