For example, you might want to enforce a “zero trust” network model for all of your services. In your workspace settings, you can enable service isolation so that only services within the same workspace (or imported workspaces) can communicate with each other. For even more control, you can set up access policies. With access policies, you can deny all access to a specific destination except for the clients that you explicitly allow.

This guide shows you how to set up Gloo access policies to restrict incoming or outgoing traffic on Layer 4 for an endpoint to a specific port and protocol. For example, you can allow incoming TCP traffic on port 3000 only. Note that if you use the Solo distribution of the Cilium CNI, Gloo access policies are automatically translated into Cilium network policies for you.

For more information, see the following resources.

Before you begin

  1. Complete the multicluster getting started guide to set up the following testing environment.

    • Three clusters along with environment variables for the clusters and their Kubernetes contexts.
    • The Gloo meshctl CLI, along with other CLI tools such as kubectl and istioctl.
    • The Gloo management server in the management cluster, and the Gloo agents in the workload clusters.
    • Istio installed in the workload clusters.
    • A simple Gloo workspace setup.
  2. Install Bookinfo and other sample apps.

Configure access policies

You can apply an access policy at the workload or destination level. For more information, see Applying policies.

Review the following table to understand this configuration. For more information, see the API docs.

applyToDestinations or applyToWorkloadsConfigure which destinations to apply the policy to, by using labels. Destinations can be a Kubernetes service, VirtualDestination, or ExternalService. If you do not specify any destinations or routes, the policy applies to all destinations in the workspace by default. If you do not specify any destinations but you do specify a route, the policy applies to the route but to no destinations. Note that for security reasons, applyToWorkloads is preferred. However, the applyToWorkloads selector does not work if you enable service isolation in your workspace.
authnFor authentication, set the type of TLS policy to enforce when connecting to the workload. STRICT secures connections to the upstream workload with mTLS by presenting client certificates for authentication. If you set up service isolation for the workspace, this setting is always set to STRICT. Other modes include PERMISSIVE to allow both TLS-secured and plain text connections to the upstream endpoint, or DISABLE to not set up a TLS connection to the upstream endpoint.
authzListConfigure how clients are allowed to access the workload. You can have multiple allowed clients in the same access policy, as well as multiple configurations for the same client. A request is allowed when it matches at least one of the entries in this authzList field (logically OR’d together).
allowedClientsConfigure which clients are permitted to access the workload. In this example, the allowed clients are restricted to the product page app, as selected by the label of its Kubernetes service account.
allowedIpBlocksSpecify the IP address or IP address CIDR that you want to allow access to the workload.
allowedPathsOptionally, you can restrict which path to allow. For HTTP paths, exact match, prefix match, and suffix match are supported. In this example, requests are restricted to the suffix match path /ratings*.
allowedMethodsOptionally, you can restrict the HTTP methods to allow, such as GET or POST. If the request is made via gRPC, this value is ignored because the method is always POST. In this example, no method is set, so all methods are allowed by default.
matchDefine the requirements that must be met to match the request and enforce the policy.
request.headersSpecify the request headers that must be sent to allow or deny communication between the allowedClients and the workload that you specified. If a header is sent that is specified in the values section, the header is matched and the request is allowed. Headers in the notValues section are not allowed, and requests that include this header are denied.

Verify access policies

  1. Create a temporary curl or debug pod and send a request to the ratings app from your local machine. The communication from your local machine to the ratings app is allowed as no access policy is applied yet.

  2. Apply one of the access policies. The access policy allows access to the ratings app from the product page app. Requests from all other clients are denied.

      kubectl apply -f policy.yaml
  3. Verify that requests from a temporary curl or debug pod are now blocked. You get back a 403 Forbidden response.

  4. Verify that the productpage app can access the ratings app. Note that if you created an access policy with request header matching, you must provide the X-Test-Header: <header-value> in your curl request.

  5. Check the metrics to verify that the policy allowed or blocked requests.

    1. Open the Prometheus expression browser.
    2. Open your browser and connect to localhost:9091/.
    3. In the Expression search bar, enter rate(hubble_drop_total{destination_workload_id=~"ratings.+"}[5m]), then click Execute.
    4. Verify that you can see requests from the temporary curl pod to the ratings app that were dropped because of the access policy.


You can optionally remove the resources that you set up as part of this guide.

  kubectl --context $REMOTE_CONTEXT1 -n bookinfo delete accesspolicy ratings-access