Navigation :

Control network traffic with policies

Use Gloo Network access policies to control which workloads can send requests to other workloads in your cluster.

By default, services within a cluster can communicate with each other. However, you might want to enforce a “zero trust” network model for all of your services. In zero trust, communication is prevented by default unless otherwise permitted. You can enable Gloo service isolation with workspaces, and use Gloo access policies to enforce zero trust in your cluster.

This guide walks you through how to set up Gloo Network access policies to restrict incoming or outgoing traffic for an endpoint to a specific port and protocol. For example, you can allow incoming TCP traffic on port 3000 only. Gloo access policies are automatically translated into Cilium network policies.

To create advanced Layer 7 policies, such as to enable fault injection, outlier detection, retries, and more, consider using Gloo Network in a service mesh that is managed by Gloo Mesh Enterprise. This setup helps you implement a defense-in-depth architecture where policies are enforced on multiple layers of the OSI network model. If one layer is compromised, your apps are still protected by policies in other layers. In addition, all traffic in the service mesh is encrypted by default and you get deep visibility into the traffic between your apps with the built-in Gloo observability tools. For more information, see the benefits of using a Gloo Mesh-managed service mesh and how you accelerate the eBPF data path with Gloo Network.

Before you begin

Complete the following tasks in the getting started tutorial:

Configure access policies

You can apply an access policy at the destination level. The following example is for an access policy that allows only the product page app to access the reviews app on port 9080 and matching /reviews* paths.

apiVersion: security.policy.gloo.solo.io/v2
kind: AccessPolicy
metadata:
  name: reviews-access
  namespace: bookinfo
spec:
  applyToDestinations:
  - port:
      number: 9080
    selector:
      labels:
        app: reviews
  config:
    authn:
      tlsMode: STRICT
    authz:
      allowedClients:
      - serviceAccountSelector:
          labels:
            account: productpage
      allowedPaths:
      - /reviews*

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

Setting	Description
`applyToDestinations`	Configure which destinations to apply the policy to, by using labels. Destinations can be a Kubernetes service, or Gloo VirtualDestination and ExternalService if you use Gloo Network in a service mesh that is managed by Gloo Mesh Enterprise. If you do not specify any destinations, the policy applies to all destinations in the workspace by default. In this example, traffic from only the `product` app is allowed to the `reviews` app.
`port`	In this example, traffic is further restricted to port 9080.
`authn`	For authentication, set the type of TLS policy to enforce when connecting to the destination. `STRICT` secures connections to the destination with mTLS (which requires a Gloo Mesh license in addition to Gloo Network) 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.
`authz`	Set up which clients are permitted to access the destination.
`allowedClients`	Configure which clients are permitted to access the destination. In this example, the allowed clients are restricted to the product page app, as selected by the label of its Kubernetes service account.
`allowedPaths`	Optionally, 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 `/reviews*`.

Verify access policies

Create a temporary curl client in your cluster and verify that you can access the reviews app.

Create the curl pod.

kubectl run -it -n bookinfo curl \
  --image=curlimages/curl:7.73.0 --rm  -- sh

Send a request to the reviews app.

curl http://reviews:9080/reviews/1 -v

Example output:

< HTTP/1.1 200 OK
< X-Powered-By: Servlet/3.1
< Content-Type: application/json
< Date: Mon, 19 Sep 2022 14:05:16 GMT
< Content-Language: en-US
< Content-Length: 358
< 
* Connection #0 to host reviews left intact
{"id": "1","podname": "reviews-v1-55b668fc65-p5b82","clustername": "null","reviews": [{  "reviewer": "Reviewer1",  "text": "An extremely entertaining play by Shakespeare. The slapstick humour is refreshing!"},{  "reviewer": "Reviewer2",  "text": "Absolutely fun and entertaining. The play lacks thematic depth when compared to other plays by Shakespeare."}]}

Exit the temporary pod. The pod deletes itself.
```
exit
```

Add a curl container inside the product page app and verify that you can access the reviews app.

Create the curl container.

kubectl apply -f https://raw.githubusercontent.com/solo-io/gloo-mesh-use-cases/main/policy-demo/productpage-with-curl.yaml

kubectl exec $(kubectl get pod -l app=productpage -A -o jsonpath='{.items[0].metadata.name}') -n bookinfo -c curl -- curl -v http://reviews:9080/reviews/1

Create a Gloo Network access policy that allows only the product page to access the reviews app. After you create this access policy, all other clients, including the temporary curl pod, are not allowed to access the reviews app anymore.

kubectl apply -f - << EOF
apiVersion: security.policy.gloo.solo.io/v2
kind: AccessPolicy
metadata:
  name: reviews-access
  namespace: bookinfo
spec:
  applyToDestinations:
  - port:
      number: 9080
    selector:
      labels:
        app: reviews
  config:
    authn:
      tlsMode: STRICT
    authz:
      allowedClients:
      - serviceAccountSelector:
          labels:
            account: productpage
      allowedPaths:
      - /reviews*
EOF

Re-create the temporary curl client in your cluster and verify that you cannot access the reviews app anymore.
1. Create the curl pod.
```
kubectl run -it -n bookinfo curl \
  --image=curlimages/curl:7.73.0 --rm  -- sh
```
2. Send a request to the reviews app. Note that no response is returned as request packets are dropped before they reach the reviews app.
```
curl http://reviews:9080/reviews/1 -v
```
3. Exit the temporary pod. The pod deletes itself.
```
exit
```

kubectl exec $(kubectl get pod -l app=productpage -A -o jsonpath='{.items[0].metadata.name}') -n bookinfo -c curl -- curl -v http://reviews:9080/reviews/1

Check the metrics to verify that the policy allowed or blocked requests.
1. Open the Prometheus expression browser.
  - meshctl
  - kubectl
```
  For more information, see the [CLI documentation](
```
  /gloo-network/latest/reference/cli/meshctl_proxy/ ). shell meshctl proxy prometheus
```
  Port-forward the `prometheus-server` deployment on 9091.
  ```shell
    kubectl -n gloo-mesh port-forward deploy/prometheus-server 9091
  ```
```
2. Open your browser and connect to localhost:9091/.
3. In the Expression search bar, enter rate(hubble_drop_total{destination_workload_id=~"reviews.+"}[5m]), then click Execute.
4. Verify that you can see requests from the temporary curl pod to the reviews app that were dropped because of the access policy.