Chapter 7. Security

Istio’s security capabilities are evolving quickly, and as of this writing, the Access Control List (ACL) is one of the primary tools to inject security constructs into the application with zero impact to the actual programming logic. In this chapter, we explore the concepts of blacklist and whitelist.

Blacklist

Let’s begin with the concept of the blacklist, conditionally denying requests using Mixer selectors. The blacklist is explicit denials of particular invocation paths. In the example that follows, we want to explicitly close the route from customer to preference. In this case, any requests from the customer to preference would return the HTTP error 403 Forbidden. Establishing this requires the use of three different kinds of Istio-mixer configurations: denier, checknothing, and rule:

apiVersion: "config.istio.io/v1alpha2"
kind: denier
metadata:
  name: denycustomerhandler
spec:
  status:
    code: 7
    message: Not allowed
---
apiVersion: "config.istio.io/v1alpha2"
kind: checknothing
metadata:
  name: denycustomerrequests
spec:
---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: denycustomer
spec:
  match: destination.labels["app"] == "preference" &&
   source.labels["app"]=="customer"
  actions:
  - handler: denycustomerhandler.denier
    instances: [ denycustomerrequests.checknothing ]

You use istioctl to establish the denier-checknothing-rule:

istioctl create -f istiofiles/acl-blacklist.yml -n tutorial

Next, attempt to curl the customer endpoint:

curl customer-tutorial.$(minishift ip).nip.io

The result will be a 403 from the preference microservice:

customer => 403 PERMISSION_DENIED:denycustomerhandler.denier.tutorial:
Not allowed

Clean up:

istioctl delete -f istiofiles/acl-blacklist.yml -n tutorial

Whitelist

The whitelist is a deny everything rule, except for approved invocation paths. In this example, we are approving only the route of recommendations > preferences which means the customer who normally talks to preference can no longer even see it. The whitelist configuration uses the Mixer kinds of: listchecker, listentry, rule.

apiVersion: "config.istio.io/v1alpha2"
kind: listchecker
metadata:
  name: preferencewhitelist
spec:
  overrides: ["recommendation"]
  blacklist: false
---
apiVersion: "config.istio.io/v1alpha2"
kind: listentry
metadata:
  name: preferencesource
spec:
  value: source.labels["app"]
---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: checkfromcustomer
spec:
  match: destination.labels["app"] == "preference"
  actions:
  - handler: preferencewhitelist.listchecker
    instances:
    - preferencesource.listentry

Using the istioctl tool, create the blacklist components:

istioctl create -f istiofiles/acl-whitelist.yml -n tutorial

Then, hit the customer end point using the curl command:

curl customer-tutorial.$(minishift ip).nip.io

Which results in the following:

customer => 404 NOT_FOUND:preferencewhitelist.listchecker.tutorial:
customer is not whitelisted

Clean up:

istioctl delete -f istiofiles/acl-whitelist.yml -n tutorial

The Red Hat team will be exploring more interesting and advanced security use cases at the istio-tutorial as the Istio open source project matures.

Conclusion

You have now taken a tour through some of the capabilities of Istio service mesh. You saw how this service mesh can solve distributed-systems problems in cloud-native environments, whether developing microservices architectures or monoliths or anything in between. You have seen how Istio concepts like observability, resiliency and chaos injection can be immediately beneficial to your current application. Although we focused on services running on Kubernetes/OpenShift and deployed in containers, Istio is not tied to any of these environments and can be used on bare metal, VM, and other deployment platforms.

Moreover, Istio has capabilities beyond those we discussed in this report. If you’re interested, we suggest that you explore more on the following topics:

  • End-user authentication

  • Policy enforcement

  • Mesh expansion

  • Hybrid deployments

  • Phasing in Istio to an existing environment

  • Gateway/Advanced ingress

  • Latest evolution of RouteRules/resources

Istio is also evolving at a rapid rate. To keep up with the latest developments, we suggest that you keep an eye on the upstream community project as well as Red Hat’s evolving istio-tutorial.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.65.247