Enabling Simple Access Control

This task shows how to use Istio to control access to a service.

Before you begin

  • Setup Istio by following the instructions in the Installation guide.

  • Deploy the BookInfo sample application.

  • Initialize the application version routing to direct reviews service requests from test user “jason” to version v2 and requests from any other user to v3.

    istioctl create -f samples/apps/bookinfo/route-rule-reviews-test-v2.yaml
istioctl create -f samples/apps/bookinfo/route-rule-reviews-v3.yaml

    Note: if you have conflicting rule that you set in previous tasks, use istioctl replace instead of istioctl create.

Access control using denials

Using Istio you can control access to a service based on any attributes that are available within Mixer. This simple form of access control is based on conditionally denying requests using Mixer selectors.

Consider the BookInfo sample application where the ratings service is accessed by multiple versions of the reviews service. We would like to cut off access to version v3 of the reviews service.

  1. Point your browser at the BookInfo productpage (http://$GATEWAY_URL/productpage).

    If you log in as user “jason”, you should see black ratings stars with each review, indicating that the ratings service is being called by the “v2” version of the reviews service.

    If you log in as any other user (or logout) you should see red ratings stars with each review, indicating that the ratings service is being called by the “v3” version of the reviews service.

  2. Explicitly deny access to version v3 of the reviews service.

    istioctl mixer rule create global ratings.default.svc.cluster.local -f samples/apps/bookinfo/mixer-rule-ratings-denial.yaml

    This command sets configuration for subject=ratings.default.svc.cluster.local. You can display the current configuration with the following command:

    istioctl mixer rule get global ratings.default.svc.cluster.local

    which should produce:

    rules:
- aspects:
  - kind: denials
  selector: source.labels["app"]=="reviews" && source.labels["version"] == "v3"

    This rule uses the denials aspect to deny requests coming from version v3 of the reviews service. The denials aspect always denies requests with a pre-configured status code and message. The status code and the message is specified in the DenyChecker adapter configuration.

  3. Refresh the productpage in your browser.

    If you are logged out or logged in as any user other than “jason” you will no longer see red ratings stars because the reviews:v3 service has been denied access to the ratings service. Notice, however, that if you log in as user “jason” (the reviews:v2 user) you continue to see the black ratings stars.

Access control using whitelists

Istio also supports attribute-based white and blacklists. Using a whitelist is a two step process.

  1. Add an adapter definition for the genericListChecker adapter that lists versions v1, v2:

    - name: versionList
  impl: genericListChecker
  params:
    listEntries: ["v1", "v2"]

  2. Enable whitelist checking by using the lists aspect:

    rules:
  aspects:
  - kind: lists
    adapter: versionList
    params:
      blacklist: false
      checkExpression: source.labels["version"]

    checkExpression is evaluated and checked against the list [v1, v2]. The check behavior can be changed to a blacklist by specifying blacklist: true. The expression evaluator returns the value of the version label as specified by the checkExpression key.

The current version of istioctl does not yet support pushing adapter configurations like the one in step 1. There is, however, a workaround that you can use if you want to try it out anyway.

Cleanup

  • Remove the mixer configuration rule:

    istioctl mixer rule delete global ratings.default.svc.cluster.local

  • Remove the application routing rules:

    istioctl delete -f samples/apps/bookinfo/route-rule-reviews-test-v2.yaml
istioctl delete -f samples/apps/bookinfo/route-rule-reviews-v3.yaml

What’s next