Activity: Implement Least Privilege with Authorization Policies

Module 2

As it stands, the microservices in the travel-agency namespace can currently communicate freely. While this makes the development cycle easier, it poses security risks especially for services like discounts which applies proprietary pricing logic and handles sensitive data.

travel agency namespace initial

In this section, you’ll apply an Istio AuthorizationPolicy to enforce a least privilege model, allowing access to discounts only from the allowed backend services (hotels, cars, flights and insurance services), and not from the travels REST API.

Review current access of discounts service

  1. Run the following command in the upper terminal to verify that you are indeed able to access the discounts service directly from all the services in the travel-agency name space.
    This command calls the discounts service directly from the pods of the services.

    oc rsh -n travel-agency $(oc get pod -l app=travels -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-travels

oc rsh -n travel-agency $(oc get pod -l app=flights -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-flights

oc rsh -n travel-agency $(oc get pod -l app=insurances -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-insurances

oc rsh -n travel-agency $(oc get pod -l app=cars -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-cars

oc rsh -n travel-agency $(oc get pod -l app=hotels -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-hotels

  2. The output verifies access of discounts service directly from travels REST API, and other services such as cars and hotels.

    {"user":"hello-from-travels","discount":0.05}
{"user":"hello-from-flights","discount":0.05}
{"user":"hello-from-insurances","discount":0.05}
{"user":"hello-from-cars","discount":0.05}
{"user":"hello-from-hotels","discount":0.05}

Restrict access to discounts service

Your goal is to restrict access to the discounts service so that only specific backend services can access it, while preventing access from the travels REST API. This is achieved using an Istio Custom Resource (CR) AuthorizationPolicy.

  1. Click the (+) button on the top navigation bar of {ocp_cluster_openshift_cluster_console_url}[OpenShift Console^, window="console"] to create a new resource. Log in with username admin and password {ocp_cluster_openshift_cluster_admin_password} if prompted.

    create yaml

  2. In the YAML editor, copy the following AuthorizationPolicy CR, and click Create.

    apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-only-trusted-services
  namespace: travel-agency
spec:
  selector:
    matchLabels:
      app: discounts
      version: v1
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/travel-agency/sa/discount-access-sa

    A brief description of the above AuthorizationPolicy

    • the selector specifies the workload which is the discounts service in this case

    • the action ALLOWs traffic based on the rules set

    • the rules allows requests from workloads using the service account named discount-access-sa

    The discount-access-sa service account has already been created and added to the allowed backend services as part of the workshop set up.

Test the AuthorizationPolicy

  1. Run the following command in the upper terminal to ensure the travels REST API is no longer able to access the discounts service.

    oc rsh -n travel-agency $(oc get pod -l app=travels -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-travels && echo

  2. You should no longer be able to access discounts service but instead get an access denied response.

    RBAC: access denied
    It may take a few seconds for the AuthorizationPolicy to take effect. Please retry if you still see a success response.

  3. Verify that the allowed services can still access the discounts service by running the following command in the upper terminal.

    oc rsh -n travel-agency $(oc get pod -l app=flights -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-flights

oc rsh -n travel-agency $(oc get pod -l app=insurances -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-insurances

oc rsh -n travel-agency $(oc get pod -l app=cars -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-cars

oc rsh -n travel-agency $(oc get pod -l app=hotels -n travel-agency -o jsonpath='{.items[0].metadata.name}') \
  curl http://discounts.travel-agency.svc.cluster.local:8000/discounts/hello-from-hotels

    Output:

    {"user":"hello-from-flights","discount":0.05}
{"user":"hello-from-insurances","discount":0.05}
{"user":"hello-from-cars","discount":0.05}
{"user":"hello-from-hotels","discount":0.05}

Summary:

In this section, you applied an Istio AuthorizationPolicy to secure service-to-service communication within the travel-agency namespace to demonstrate how Red Hat OpenShift Service Mesh allows you to enforce fine-grained access control using a simple, declarative policy model.

Next steps

In the next section you will leverage Red Hat OpenShift Service Mesh to shape and manage traffic flows using techniques like canary rollouts to safely introduce new service versions.