Shulou(Shulou.com)06/03 Report--

Abstract

Access control between microservices can be easily realized by using Istio. This article demonstrates two methods of using Denier adapter to deny access and Listchecker adapter to implement blacklist and whitelist.

Working with scen

Sometimes it is necessary to control the mutual access between microservices, such as enabling microservices that meet certain conditions (such as versions) to (or cannot) invoke specific microservices.

Access control belongs to the policy category and is implemented by Mixer components in Istio.

Mixer Topology Diagram, official source document

As shown in the figure above, the external request for the service is intercepted by Envoy, and each request passing through Envoy calls Mixer, providing Mixer with a set of properties that describe the request and its surrounding environment. Mixer performs pre-condition check and quota check, calls the corresponding adapter for processing, and returns the corresponding results. Envoy analyzes the results and decides whether to execute the request or reject the request. Thus the policy control is realized.

Environmental preparation

Deploy Istio on a Kubernetes cluster

Deploy the Bookinfo sample application

Configure destinationrule and virtualservice for each microservice of the Bookinfo application. The destinationrule and virtualservice configurations of reviews service are as follows:

After configuring according to the figure above, for reviews service requests, requests from user "kokokobe" will be routed to v2 version, and requests from other users will be routed to v3 version.

Simple access control using Denier adapters

When using Istio for access control of microservices, you can use any attribute in Mixer. This is a simple access control based on rejecting requests under certain conditions through Mixer selectors.

For example, ratings services in Bookinfo applications described above are accessed by multiple versions of reviews services. In the following example, we will cut off the call to the ratings service from the v3 version of the reviews service.

Open Bookinfo's productpage (http://$GATEWAY_URL/productpage) with a browser

As shown in the figure above, if you log in with the user of "kokokobe", you can see the black stars under each review, indicating that the ratings service is called by the v2 version of the reviews service at this time.

As you can see from the above two figures, if you log in with other users (or are not logged in), you can see the red stars under each review, indicating that the ratings service is called by the v3 version of the reviews service at this time.

Create a denier adapter to reject calls to ratings services from v3 versions of reviews services

Edit the mixer-rule-deny-label.yaml as follows:

This is also the standard configuration format of Mixer's adapter, which generally requires the configuration of three types of resources:

Configure a set of handler. Handler is an instance of a configured adapter, and adapter encapsulates the interface between Mixer and the back end of a particular infrastructure.

Configure a set of instance based on template. Instance defines how to map the request attributes provided by Envoy to the input of adapter.

Configure a set of rules. These rules describe when to invoke specific handler and instance.

Here you define a rule called denyreviewsv3, a handler of type denier, and an instance of a template of type checknothing.

In the denyreviewsv3 rule, the conditional expression in the box matches a request from a reviews service with a version of v3 and a target ratings service. This rule uses the denier adapter to reject requests from the v3 version of the reviews service.

This denier adapter rejects requests that meet the above rules. You can pre-specify the status code and message for the denier adapter, as shown in the box.

Then execute the following command to create the denier adapter for the above rule:

Refresh the productpage page in the browser

If you have logged out or logged in as a user other than "kokokobe", you will no longer see the red star because the v3 version of the reviews service has been denied access to the ratings service.

On the contrary, if you log in with the "kokokobe" user, you can still see the black stars. Because the user is using the v2 version of the reviews service, it does not meet the criteria for rejection.

Implement blacklist and whitelist through listchecker adapter

Istio also supports attribute-based blacklists and whitelists. The following whitelist configuration is equivalent to the denier configuration in the previous section, denying requests from the v3 version of the reviews service.

Delete the denier rule configured in the previous section

Browse Bookinfo's productpage (http://$GATEWAY_URL/productpage) in logout state

The red star icon can be seen at this point. After completing the following steps, you will not see the star icon until you log in with the identity of "kokokobe".

Create a listchecker adapter that contains a v2 whitelist

Edit the whitelist-handler.yaml as follows:

The list of blacklists and whitelists is usually maintained externally, and then the providerUrl parameter is specified for asynchronous fetching. In this example, we use the overrides field to provide a static blacklist and whitelist.

Then run the following command to create the listchecker adapter:

Create an instance of a listentry template

The Listentry template can be used to determine whether a string exists in a list, and in this case we use it to determine whether the version label exists in the whitelist.

Edit the appversion-instance.yaml as follows:

Then run the following command:

Enable whitelist inspection for the ratings service

Edit the checkversion-rule.yaml as follows:

Then run the following command:

Refresh the productpage page in the browser

If you have logged out or logged in as a user other than "kokokobe", you will not see a star icon; if you log in with a "kokokobe" user, you can still see black stars.

Summary

From the above example, we can find that it is very convenient to use Istio to implement access control between microservices. You can use denier adapters to implement simple access control, or you can use listchecker adapters to implement more complex blacklists and whitelists.

For related services, please visit https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.