Cloud Service Mesh by example: Authorization

Note: This guide only supports Cloud Service Mesh with Istio APIs and doesnot support Google Cloud APIs. For more information see,Cloud Service Mesh overview.

In this tutorial, you will learn what authorization is, and how to enable itwith Cloud Service Mesh on a sample application to learn how to enableauthorization policies to your microservices. You will create anAuthorizationPolicy toDENY access to a microservice, then create anAuthorizationPolicy toALLOW specific access to a microservice.

What is authorization?

Authentication verifies an identity -- is this service who they say they are?Authorization verifies the permission - is this service allowed to do that?Identity is fundamental to this idea. With Cloud Service Mesh,AuthorizationPolicies allow for workload-to-workload communication in yourmesh to be controlled for improved security and access.

In a microservice architecture, where calls are made across network boundaries,IP-based firewall rules are often not adequate to secure access betweenworkloads. With Cloud Service Mesh, you can set authorization rules to:

  • Control access to workloads within your mesh, either workload-to-workload orend-user-to-workload
  • Broadly or granularly define policies depending on your needs.

To see an in-depth explanation on configuring policies and best practices, seeAuthorization with Cloud Service Mesh.

Costs

This tutorial uses the following billable components of Google Cloud:

When you finish this tutorial, you can avoid ongoing costs by deleting theresources you created. For more information, seeClean up.

Before you begin

Deploy an ingress gateway

  1. Set the current context forkubectl to the cluster:

    Note: Use--region instead of--zone, if the cluster is a regionalcluster.
    gcloud container clusters get-credentialsCLUSTER_NAME  \--project=PROJECT_ID \--zone=CLUSTER_LOCATION

  2. Create a namespace for your ingress gateway:

    kubectl create namespace asm-ingress

  3. Enable the namespace for injection. The steps depend on yourcontrol plane implementation.

    Managed (TD)

    Apply the default injection label to the namespace:

    kubectllabelnamespaceasm-ingress\istio.io/rev-istio-injection=enabled--overwrite

    Managed (Istiod)

    Recommended: Run the following command to apply the default injection label to the namespace:

    kubectllabelnamespaceasm-ingress\istio.io/rev-istio-injection=enabled--overwrite

    If you are an existing user with the Managed Istiod control plane:We recommend that you use default injection, but revision-based injection issupported. Use the following instructions:

    1. Run the following command to locate the available release channels:

      kubectl-nistio-systemgetcontrolplanerevision

      The output is similar to the following:

      NAME                AGEasm-managed-rapid   6d7h
      Note: If two control plane revisions appear in the earlier list, remove one. Having multiple control plane channels in the cluster is not supported.

      In the output, the value under theNAME column is the revision label that corresponds to the availablerelease channel for the Cloud Service Mesh version.

    2. Apply the revision label to the namespace:

      kubectllabelnamespaceasm-ingress\istio-injection-istio.io/rev=REVISION_LABEL--overwrite

    In-cluster

    Recommended: Run the following command to apply the default injection label to the namespace:

    kubectllabelnamespaceasm-ingress\istio.io/rev-istio-injection=enabled--overwrite

    We recommend that you use default injection, but revision-based injection is supported:Use the following instructions:

    1. Use the following command to locate the revision label onistiod:

      kubectlgetdeploy-nistio-system-lapp=istiod-o\jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

    2. Apply the revision label to the namespace. In the following command,REVISION_LABEL is the value of theistiod revisionlabel that you noted in the previous step.

      kubectllabelnamespaceasm-ingress\istio-injection-istio.io/rev=REVISION_LABEL--overwrite

  4. Deploy the example gateway in theanthos-service-mesh-samples repo:

    kubectl apply -n asm-ingress \-f docs/shared/asm-ingress-gateway

    Expected output:

    serviceaccount/asm-ingressgateway configuredservice/asm-ingressgateway configureddeployment.apps/asm-ingressgateway configuredgateway.networking.istio.io/asm-ingressgateway configured

Deploy the Online Boutique sample application

  1. If you haven't, set the current context forkubectl to the cluster:

    gcloud container clusters get-credentialsCLUSTER_NAME  \--project=PROJECT_ID \--zone=CLUSTER_LOCATION

  2. Create the namespace for the sample application:

    kubectl create namespace onlineboutique

  3. Label theonlineboutique namespace to automatically inject Envoy proxies. Follow the stepsto enable automatic sidecar injection.

  4. Deploy the sample app, theVirtualService for the frontend, and service accounts for the workloads. For this tutorial, you will deployOnline Boutique, a microservice demo app.

    kubectl apply \-n onlineboutique \-f docs/shared/online-boutique/virtual-service.yamlkubectl apply \-n onlineboutique \-f docs/shared/online-boutique/service-accounts

View your services

  1. View the pods in theonlineboutique namespace:

    kubectl get pods -n onlineboutique

    Expected output:

    NAME                                     READY   STATUS    RESTARTS   AGEadservice-85598d856b-m84m6               2/2     Running   0          2m7scartservice-c77f6b866-m67vd              2/2     Running   0          2m8scheckoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10scurrencyservice-59bc889674-jhk8z         2/2     Running   0          2m8semailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10sfrontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9sloadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8spaymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9sproductcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114srecommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9sredis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7sshippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s

    All of the pods for your application should be up and running, with a2/2 in theREADY column. This indicates that the pods have an Envoy sidecar proxy injected successfully. If it does not show2/2 after a couple of minutes, visit theTroubleshooting guide.

  2. Get the external IP, and set it to a variable:

    kubectl get services -n asm-ingressexport FRONTEND_IP=$(kubectl --namespace asm-ingress \get service --output jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' \)

    You see output similar to the following:

    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGEasm-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

  3. Visit theEXTERNAL-IP address in your web browser. You should expect to seethe Online Boutique shop in your browser.

    online boutique frontend

DenyAll Authorization for a workload

This section adds anAuthorizationPolicy to deny all incoming traffic to thecurrency service.AuthorizationPolicies work by transformingAuthorizationPolicies into Envoy-readable configs, and applying the configs toyour sidecar proxies. This enables the Envoy proxy to authorize or deny incomingrequests to a service.

  1. Apply anAuthorizationPolicy to thecurrencyservice. Notice the match on the labelcurrencyservice in the YAML file.

    kubectl apply -f docs/authorization/currency-deny-all.yaml -n onlineboutique
    apiVersion:security.istio.io/v1beta1kind:AuthorizationPolicymetadata:name:currency-policyspec:selector:matchLabels:app:currencyservice

  2. Try accessing your gateway'sEXTERNAL-IP to view Online Boutique in the webbrowser. You should see an authorization error (500 Internal Service Error)fromcurrency service.

    authz rbac 500 error

Observe your sidecar proxy logs

To see what is occurring in the sidecar proxy, you can review the logs in thepod.

  1. Get the name of yourcurrencyservice pod:

    CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')

  2. Set the Envoy proxy to allow for trace level logs. By default, blocked authorization calls are not logged:

    kubectl debug --image istio/base --target istio-proxy -it $CURRENCY_POD -n onlineboutique -- curl -X POST "http://localhost:15000/logging?level=trace"

    Expected output:none {:.devsite-disable-click-to-copy}active loggers:admin: tracealternate_protocols_cache: trace...tracing: traceupstream: traceudp: tracewasm: trace

  3. Usecurl to send traffic to yourEXTERNAL_IP to generate logs:

    for i in {0..10}; docurl -s -I $FRONTEND_IP ; done

  4. View the role-based access control (RBAC) related logs in your istio-proxy:

    kubectl logs -n onlineboutique $CURRENCY_POD -c istio-proxy | grep -m5 rbac

    Expected output:

    2022-07-08T14:19:20.442920Z     debug   envoy rbac      checking request: requestedServerName: outbound_.7000_._.currencyservice.onlineboutique.svc.cluster.local, sourceIP: 10.8.8.5:34080, directRemoteIP: 10.8.8.5:34080, remoteIP: 10.8.8.5:34080,localAddress: 10.8.0.6:7000, ssl: uriSanPeerCertificate: spiffe://christineskim-tf-asm.svc.id.goog/ns/onlineboutique/sa/default, dnsSanPeerCertificate: , subjectPeerCertificate: OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US, headers: ':method', 'POST'2022-07-08T14:19:20.442944Z     debug   envoy rbac      enforced denied, matched policy none2022-07-08T14:19:20.442965Z     debug   envoy http      [C73987][S13078781800499437460] Sending local reply with details rbac_access_denied_matched_policy[none]  ```

You should see anenforced denied message in the logs, showing thatcurrencyservice is set to block inbound requests.

Allow Restricted Access

Instead of aDENYALL policy, you can set access to be allowed for certainworkloads. This will be relevant in a microservice architecture where you wantto ensure that only authorized services can communicate with each other.

In this section, you will enable thefrontend andcheckout service theability to communicate with thecurrency service.

  1. In the following file, see that a specificsource.principal(client) isallowed to accesscurrencyservice:
apiVersion:security.istio.io/v1beta1kind:AuthorizationPolicymetadata:name:currency-policyspec:selector:matchLabels:app:currencyservicerules:-from:-source:principals:["cluster.local/ns/onlineboutique/sa/frontend"]-from:-source:principals:["cluster.local/ns/onlineboutique/sa/checkoutservice"]

  1. Apply the policy:

    kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique

  2. Visit theEXTERNAL-IP in your web browser, you should now be able to accessOnline Boutique.

Clean up

To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources.

To avoid incurring continuing charges to your Google Cloud account forthe resources used in this tutorial, you can eitherdelete the project or deletethe individual resources.

Delete the project

Caution: Deleting a project has the following effects:
  • Everything in the project is deleted. If you used an existing project for this tutorial, when you delete it, you also delete any other work you've done in the project.
  • Custom project IDs are lost. When you created this project, you might have created a custom project ID that you want to use in the future. To preserve the URLs that use the project ID, such as an appspot.com URL, delete selected resources inside the project instead of deleting the whole project.

In Cloud Shell, delete the project:

gcloud projects deletePROJECT_ID

Delete the resources

  • If you want to keep your cluster and remove the Online Boutique sample:

    1. Delete the application namespaces:

      kubectl delete namespace onlineboutique

      Expected output:

      namespace "onlineboutique" deleted

    2. Delete the Ingress Gateway namespace:

      kubectl delete namespace asm-ingress

      Expected output:

      amespace "asm-ingress" deleted

  • If you want to prevent additional charges, delete the cluster:

    gcloud container clusters deleteCLUSTER_NAME  \--project=PROJECT_ID \--zone=CLUSTER_LOCATION

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2026-02-19 UTC.