Setting up Secure Access Control

This task shows how to securely control access to a service, using the service accounts provided by Istio authentication.

When Istio mutual TLS authentication is enabled, the server authenticates the client according to its certificate, and obtains the client’s service account from the certificate. The service account is in the source.user attribute. For the format of the service account in Istio, please refer to the Istio auth identity.

Before you begin

  • Set up Istio on auth-enabled Kubernetes by following the instructions in the quick start. Note that authentication should be enabled at step 5 in the installation steps.

  • Deploy the BookInfo sample application.

  • Run the following command to create service account bookinfo-productpage, and redeploy the service productpage with the service account.

    kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo-add-serviceaccount.yaml)

    You can expect to see the output similar to the following:

    serviceaccount "bookinfo-productpage" created
deployment "productpage-v1" configured

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

Access control using denials

In the BookInfo sample application, the productpage service is accessing both the reviews service and the details service. We would like the details service to deny the requests from the productpage service.

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

    You should see the “Book Details” section in the lower left part of the page, including type, pages, publisher, etc. The productpage service obtains the “Book Details” information from the details service.

  2. Explicitly deny the requests from productpage to details.

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

    istioctl create -f samples/bookinfo/kube/mixer-rule-deny-serviceaccount.yaml

    You can expect to see the output similar to the following:

    Created config denier/default/denyproductpagehandler at revision 2877836
Created config checknothing/default/denyproductpagerequest at revision 2877837
Created config rule/default/denyproductpage at revision 2877838

    Notice the following in the denyproductpage rule:

    match: destination.labels["app"] == "details" && source.user == "cluster.local/ns/default/sa/bookinfo-productpage"

    It matches requests coming from the serivce account “cluster.local/ns/default/sa/bookinfo-productpage” on the details service.

    Note: If you are using a namespace other than default, replace the default with your namespace in the value of source.user.

    This rule uses the denier adapter to deny these requests. The adapter always denies requests with a pre-configured status code and message. The status code and message are specified in the denier adapter configuration.

  3. Refresh the productpage in your browser.

    You will see the message

    “Error fetching product details! Sorry, product details are currently unavailable for this book.”

    in the lower left section of the page. This validates that the access from productpage to details is denied.

Cleanup

  • Remove the mixer configuration:

    istioctl delete -f samples/bookinfo/kube/mixer-rule-deny-serviceaccount.yaml

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

What’s next