Access

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.

For more information, see the following resources.

• Gloo Mesh API docs
• Getting started guide for service isolation
• Istio docs for authorization policy

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 Platform CLI, meshctl, 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 destination or workload level. For more information, see Applying policies.

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

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

apiVersion: security.policy.gloo.solo.io/v2
kind: AccessPolicy
metadata:
  name: ratings-access
  namespace: bookinfo
spec:
  applyToDestinations:
  - port:
      number: 9080
    selector:
      labels:
        app: ratings
  config:
    authn:
      tlsMode: STRICT
    authz:
      allowedClients:
      - serviceAccountSelector:
          labels:
            account: productpage
      allowedPaths:
      - /ratings*
      match:
        request:
          headers:
            X-Test-Header:
              notValues:
              - noMatch
              - partial-blocked
              values:
              - match
              - partial*

apiVersion: security.policy.gloo.solo.io/v2
kind: AccessPolicy
metadata:
  name: ratings-access
  namespace: bookinfo
spec:
  applyToWorkloads:
  - selector:
      labels:
        app: ratings
  config:
    authn:
      tlsMode: STRICT
    authz:
      allowedIpBlocks:
      - 112.114.230.1
      allowedPaths:
      - /ratings*

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

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.
   

   • Kubernetes 1.22 or earlier
   • Kubernetes 1.23 or later

   Create a temporary curl pod in the bookinfo namespace, so that you can test the app setup. You can also use this method in Kubernetes 1.23 or later, but an ephemeral container might be simpler, as shown in the other tab.

   1. Create the curl pod.

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

   2. Send a request to the ratings app.

      curl http://ratings:9080/ratings/1 -w "${http_code}"
      

      Example output:

      {"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}200
      

   3. Exit the temporary pod. The pod deletes itself.

      exit
      

   Use the kubernetes debug command to create an ephemeral curl container in the deployment. This way, the curl container inherits any permissions from the app that you want to test. If you don't run Kubernetes 1.23 or later, you can deploy a separate curl pod or manually add the curl container as shown in the other tab.

   kubectl --context ${REMOTE_CONTEXT1} -n bookinfo debug -i pods/$(kubectl get pod --context ${REMOTE_CONTEXT1} -l app=reviews -A -o jsonpath='{.items[0].metadata.name}') --image=curlimages/curl -- curl -v http://ratings:9080/ratings/1
   

   Example output:

   HTTP/1.1 200 OK
   ...
   {"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}
   

   If the output has an error about EphemeralContainers, see Ephemeral containers don’t work when testing Bookinfo.

2. Apply one of the access policies. The access policy allows access to the ratings app from only 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.

   • Kubernetes 1.22 or earlier
   • Kubernetes 1.23 or later

   Create a temporary curl pod in the bookinfo namespace, so that you can test the app setup. You can also use this method in Kubernetes 1.23 or later, but an ephemeral container might be simpler, as shown in the other tab.

   1. Create the curl pod.

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

   2. Send a request to the ratings app.

      curl http://ratings:9080/ratings/1 -w "${http_code}"
      

      Example output:

      RBAC: access denied
      

   3. Exit the temporary pod. The pod deletes itself.

      exit
      

   Use the kubernetes debug command to create an ephemeral curl container in the deployment. This way, the curl container inherits any permissions from the app that you want to test. If you don't run Kubernetes 1.23 or later, you can deploy a separate curl pod or manually add the curl container as shown in the other tab.

   kubectl --context ${REMOTE_CONTEXT1} -n bookinfo debug -i pods/$(kubectl get pod --context ${REMOTE_CONTEXT1} -l app=productpage -A -o jsonpath='{.items[0].metadata.name}') --image=curlimages/curl -- curl -v http://ratings:9080/ratings/1
   

   If the output has an error about EphemeralContainers, see Ephemeral containers don’t work when testing Bookinfo.

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.

   • Kubernetes 1.22 or earlier
   • Kubernetes 1.23 or later

   Add a curl container to your app deployment so that you can test the app setup. You can also use this method in Kubernetes 1.23 or later, but an ephemeral container might be simpler, as shown in the other tab.

   1. Create the curl container.

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

   2. Verify that requests now succeed. You get back a 200 response.

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

   3. Exit the temporary pod. The pod deletes itself.

      exit
      

   Use the kubernetes debug command to create an ephemeral curl container in the deployment. This way, the curl container inherits any permissions from the app that you want to test. If you don't run Kubernetes 1.23 or later, you can deploy a separate curl pod or manually add the curl container as shown in the other tab.

   kubectl --context ${REMOTE_CONTEXT1} -n bookinfo debug -i pods/$(kubectl get pod --context ${REMOTE_CONTEXT1} -l app=productpage -A -o jsonpath='{.items[0].metadata.name}') --image=curlimages/curl -- curl -v http://ratings:9080/ratings/1
   

   Example output:

   HTTP/1.1 200 OK
   ...
   {"id":1,"ratings":{"Reviewer1":5,"Reviewer2":4}}
   

Cleanup

You can optionally clean up the resources that you created.

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