About proxy trimming

Service isolation discovers and creates a lot of Istio resources pretty quickly. By default, the Istio sidecar proxies have configuration information such as the hosts of all the other destinations in the service mesh. As such, you might notice performance impacts. For large environments, you can trim all the Istio sidecar proxy configs within the workspace to eliminate all outbound destinations (the entries in the spec.egress.hosts field of the Sidecar resource).

What happens when I trim all proxy configuration?

Without the outbound destination config, the Istio sidecar proxies do not have the hosts for other destinations in the workspace by default. Then, you can add back in the proxy config for only the destinations that you want the sidecar proxies to communicate with. This way, you reduce the size of the proxy config to improve performance.

Is proxy trimming the same as access control?

No. Without the proxy configuration for workloads in the Istio sidecar proxy, workloads cannot communicate with each other via the Istio sidecar proxy. However, this setting does not prevent future communication across workloads. For example, you might later apply a TrimProxyConfigPolicy resource that restores the proxy config for select workloads. If you inadvertently use a large selector for that policy, you might re-enable communication for workloads that you did not intend to.

Instead, use an access policy alongside proxy trimming, to enforce zero-trust networking.

How are imported destinations treated?

When you import destinations to a workspace, these destinations become available to the Istio sidecar proxies of all the destinations in the workspace by default. If you enable proxy trimming in your workspace, these imported destinations are treated the same as other destinations. For example, their hosts are removed from the entries in the spec.egress.hosts field of the Sidecar resource just like with “native” destinations in the workspace. If you notice unexpected behavior, double check that you import and export the destinations correctly across workspaces.

What workloads can trim the proxies for?

You can trim the Istio sidecar proxies for standard Kubernetes workloads, such as Deployments, DaemonSets, and StatefulSets. Proxy trimming is not supported for workloads from other tooling providers’ custom resource definitions (CRDs), such as DeploymentConfigs in OpenShift.

Options for proxy trimming

You enable proxy trimming in two main ways:

  • In the workspaceSettings resource with the following fields:
    • The trimAllProxyConfig field to remove all Istio sidecar proxy configurations within the workspace; and,
    • The serviceIsolation.trimProxyConfig field to add back in all of the destinations within the workspace (including imported destinations). Note that this field also requires you to enable service isolation.
  • In the TrimProxyConfigPolicy resource with a workload selector.

In general, the policy can accomplish the same effect as the workspace settings fields and is more flexible. Therefore, you typically want to use the policy instead the workspace settings.

Using both workspace settings and policy

You can use these options in combination with each other. For example, you might enable the trimAllProxyConfig workspace setting to trim all proxy configuration in the workspace by default. You do not need to enable service isolation or the serviceIsolation.trimProxyConfig setting.

Next, you apply the TrimProxyConfigPolicy resource to add back in the proxy config for select workloads that you want to enable mesh communications for.

If you use both the serviceIsolation.trimProxyConfig workspace setting and the policy, the proxy configs for all of the selected destinations are allowed.

Using only the workspace settings

To use only the workspace settings, you must enable both trimAllProxyConfig and serviceIsolation.trimProxyConfig settings. You might use this option if you need proxy trimming at only the workspace level, such as if you have many workspaces with fine-grained import and export rules. However, this approach is not as flexible as the TrimProxyConfigPolicy resource and requires you to enable service isolation.

Using only the policy

You can use only the TrimProxyConfigPolicy resource without the workspace-level setting. By using only the policy, you get several additional benefits:

  1. The workspace settings method requires you to enable service isolation. With the policy, you can still trim proxy configs when you don’t need service isolation. For example, you might not want to limit or explicitly allowlist all of the services within your workspace.
  2. The workspace settings method trims the proxy configs only at the workspace level. With the policy, you can fine-tune the proxy config even within the workspace. For example, you might have one or two workspaces with thousands of services, and want to trim the proxies to select services within the workspace. However, you can also use the policy to accomplish the same thing as the workspace settings, by creating a TrimProxyConfigPolicy resource that selects all workloads and includes all destinations in a workspace.
  3. You can start with a zero-trust, “allow none” approach. Instead of having configuration for all destinations in the sidecar, you can use the policy to specify only allowed destinations one at a time.