istio.io/content/docs/tasks/security/basic-access-control/index.md

title	description	weight	keywords	aliases
Basic Access Control	Shows how to control access to a service using the Kubernetes labels.	20	security access-control	/docs/tasks/basic-access-control.html

This task shows how to control access to a service using the Kubernetes labels.

Before you begin

• Set up Istio on Kubernetes by following the instructions in the Installation guide.

• Deploy the Bookinfo sample application.

• The Bookinfo sample deploys multiple versions of each microservice, so you will start by creating destination rules that define the service subsets corresponding to each version.

  {{< text bash >}} $ istioctl create -f @samples/bookinfo/networking/destination-rule-all.yaml@ {{< /text >}}

  If you enabled mutual TLS, please run the following instead

  {{< text bash >}} $ istioctl create -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@ {{< /text >}}

  You can display the destination rules with the following command:

  {{< text bash >}} $ istioctl get destinationrules -o yaml {{< /text >}}

  Since the subset references in virtual services rely on the destination rules, wait a few seconds for destination rules to propagate before adding virtual services that refer to these subsets.

• 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.

  {{< text bash >}} $ istioctl create -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@ {{< /text >}}

  and then run the following command:

  {{< text bash >}} $ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml@ {{< /text >}}

  If you have conflicting rules that you set in previous tasks, use istioctl replace instead of istioctl create.

  If you are using a namespace other than default, use istioctl -n namespace ... to specify the namespace.

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 rating 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 rating 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.

   Run the following command to set up the deny rule along with a handler and an instance.

   {{< text bash >}} $ istioctl create -f @samples/bookinfo/policy/mixer-rule-deny-label.yaml@ Created config denier/default/denyreviewsv3handler at revision 2882105 Created config checknothing/default/denyreviewsv3request at revision 2882106 Created config rule/default/denyreviewsv3 at revision 2882107 {{< /text >}}

   Notice the following in the denyreviewsv3 rule:

   {{< text plain >}} match: destination.labels["app"] == "ratings" && source.labels["app"]=="reviews" && source.labels["version"] == "v3" {{< /text >}}

   It matches requests coming from the service reviews with label v3 to the service ratings.

   This rule uses the denier adapter to deny requests coming from version v3 of the reviews service. The adapter always denies requests with a preconfigured status code and message. The status code and the message is specified in the denier 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. In contrast, 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 whitelists and blacklists. The following whitelist configuration is equivalent to the denier configuration in the previous section. The rule effectively rejects requests from version v3 of the reviews service.

1. Remove the denier configuration that you added in the previous section.

   {{< text bash >}} $ istioctl delete -f @samples/bookinfo/policy/mixer-rule-deny-label.yaml@ {{< /text >}}

2. Verify that when you access the Bookinfo productpage (http://$GATEWAY_URL/productpage) without logging in, you see red stars. After performing the following steps you will no longer be able to see stars unless you are logged in as "jason".

3. Create configuration for the list adapter that lists versions v1, v2. Save the following YAML snippet as whitelist-handler.yaml:

   {{< text yaml >}} apiVersion: config.istio.io/v1alpha2 kind: listchecker metadata: name: whitelist spec:

   providerUrl: ordinarily black and white lists are maintained

   externally and fetched asynchronously using the providerUrl.

   overrides: ["v1", "v2"] # overrides provide a static list blacklist: false {{< /text >}}

   and then run the following command:

   {{< text bash >}} $ istioctl create -f whitelist-handler.yaml {{< /text >}}

4. Extract the version label by creating an instance of the listentry template. Save the following YAML snippet as appversion-instance.yaml:

   {{< text yaml >}} apiVersion: config.istio.io/v1alpha2 kind: listentry metadata: name: appversion spec: value: source.labels["version"] {{< /text >}}

   and then run the following command:

   {{< text bash >}} $ istioctl create -f appversion-instance.yaml {{< /text >}}

5. Enable whitelist checking for the ratings service. Save the following YAML snippet as checkversion-rule.yaml:

   {{< text yaml >}} apiVersion: config.istio.io/v1alpha2 kind: rule metadata: name: checkversion spec: match: destination.labels["app"] == "ratings" actions:

   • handler: whitelist.listchecker instances:
     • appversion.listentry {{< /text >}}

   and then run the following command:

   {{< text bash >}} $ istioctl create -f checkversion-rule.yaml {{< /text >}}

6. Verify that when you access the Bookinfo productpage (http://$GATEWAY_URL/productpage) without logging in, you see no stars. Verify that after logging in as "jason" you see black stars.

Cleanup

• Remove the mixer configuration:

  {{< text bash >}} $ istioctl delete -f checkversion-rule.yaml $ istioctl delete -f appversion-instance.yaml $ istioctl delete -f whitelist-handler.yaml {{< /text >}}

• Remove the application routing rules:

  {{< text bash >}} $ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@ {{< /text >}}

• Remove the application destination rules:

  {{< text bash >}} $ istioctl delete -f @samples/bookinfo/networking/destination-rule-all.yaml@ {{< /text >}}

  If you enabled mutual TLS, please run the following instead

  {{< text bash >}} $ istioctl delete -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@ {{< /text >}}

• If you are not planning to explore any follow-on tasks, refer to the Bookinfo cleanup instructions to shutdown the application.