Installing Istio Authorizer

This article provides instructions on how to install ACP's Istio Authorizer in Kubernetes to enforce access control for services and APIs deployed behind the Istio Service Mesh.

Installation alternative

As an alternative to this procedure, you can install both Istio Service Mesh and Istio Authorizer using the ACP on k8s repository which provides simple deployment commands you can use out of the box.


  • Kubernetes version 1.14 or subsequent

  • Kubernetes cluster is set up.

Setting up k8s cluster

You can set up a Kubernetes cluster locally using kind.

GO111MODULE="on" go get && kind create cluster
  • Istio version 1.9 or subsequent is installed and up and running.

  • Istio Sidecar is installed.

    Injecting Istio Sidecar

    To configure Istio proxies, you need to inject Istio Sidecar to pods running in your Istio Service Mesh. It can be done either automatically at pod creation and using admission controller, or manually at any given time.

    Cloudentity recommends using automatic sidecar injection and setting the istio-injection flag to enabled for any namespace that contains the services you wish to protect with Istio Authorizer.

  • Helm version 3.0 or subsequent

Create Istio Authorizer in ACP

  1. In the workspace of your choice, select go to ENFORCEMENT > AUTHORIZERS > CREATE GATEWAY.

  2. Select Istio, enter the name and the description for your authorizer, and select NEXT.

  3. In the Gateway Management view, go to the QUICK START tab and proceed as follows:

    1. Install Istio Authorizer using Helm chart:

      helm repo add acp && helm repo update
      helm upgrade --install istio-authorizer acp/istio-authorizer \
        --set clientCredentials.clientID={yourClientIdentifier} \
        --set clientCredentials.clientSecret={yourClientSecret} \
        --set issuerURL={yourIssuerURL} \
        --set "discovery.namespaces={default}" \
        --namespace acp-istio-authorizer \

      You can find this command with the arguments filled for you in the QUICKSTART view for your authorizer instance.

      The clientCredentials.clientID, clientCredentials.clientSecret, and issuerURL parameters are used in the client credentials OAuth grant type to authenticate your authorizer’s requests to, for example, fetch authorization policies from ACP.

      The clientCredentials.clientID argument should point to the client identifier of the client application created for your authorizer in the System workspace of your tenant. You can find the client identifier in the Settings view for your authorizer.

      The clientCredentials.clientSecret argument should point to the client secret of the client application created for your authorizer in the System workspace of your tenant. You can find the client secret in the Settings view for your authorizer.

      Credentials security

      For production environments, you should create Kubernetes secrets manually that are responsible for storing your credentials values.

      To increase security of secrets stored in your repository, it is recommended to encrypt your Kubernetes secrets. You can use tools like Mozilla SOPS or Bitnami Sealed Secrets to encrypt your secrets.

      When the secrets are applied to your Kubernetes deployment, the secrets are visible as plain text. Anyone who is authorized to create a Pod in a namespace can read any secret in that namespace; this includes indirect access such as the ability to create a Deployment. To mitigate the risks, Kubernetes recommends to:

      • Enable encryption at Rest for secrets.

      • Enable or configure RBAC rules that restrict reading data in secrets.

      • Where appropriate, use mechanisms such as RBAC to limit which principals are allowed to create or replace secrets.

      To learn more, visit Kubernetes secrets documentation.

      The issuerURL argument should point to the issuer URL of your Istio Authorizer client application created within the System workspace of your tenant. You can find the issuer URL in the Settings view for your authorizer. If you are using a vanity domain for your ACP tenant and it is impossible to retrieve the tenant’s and server’s identifier from the URL, provide values for the tenantID and serverID parameters in your values.yaml file.

      The discovery.namespaces={default} parameter is responsible for providing the namespaces where Istio Authorizer performs the service discovery. By default, Istio Authorizer performs discovery only in the default namespace. You can add a comma-separated list of namespaces as the value for the discovery.namespaces parameter provided that those namespaces already exist, for example, discovery.namespaces={default,example1,example2}. If you wish to know more, see the Discovering APIs on Istio article.

      Configuration reference

      If you need to change your Istio Authorizer settings, see configuration reference.


      Istio Authorizer scans deployments in configured namespaces and funnels information about discovered APIs to ACP. Note that if you didn’t deploy any services yet, there’s nothing to discover. To quickly deploy a sample HTTP/gPRC service, follow:

Add Istio Authorizer as extension provider to Istio

To delegate access control enforcement to your Istio Authorizer, you need to define it as an external authorization provider for your Istio Service Mesh.

  1. Edit the mesh configuration using the following command:

    kubectl edit configmap istio -n istio-system
  2. Define ACP Authorizer using extension providers, for example:

      mesh: |-
        - name: "acp-authorizer"
            service: "istio-authorizer.acp-istio-authorizer.{cluster-name}"
            port: "9001"    

    The {cluster-name} variable should point to your cluster name, for example, svc.cluster.local.

  3. Restart Istio to apply the changes:

    kubectl rollout restart deployment/istiod -n istio-system

Deploy and protect services

With Istio Authorizer installed and attached to Istio Service Mesh as an external authorization provider, you can:

Parsing request bodies

For HTTP services, ACP supports parsing request bodies. It can be used, for example, to write an authorization policy that checks request bodies.

If you wish to parse request bodies, you need to set the parseBody.enabled flag to true in the values.yaml file for your authorizer.

Having created a k8s cluster with Istio, you can