Declarative configuration import for ACP

To learn about declarative configuration import for ACP configuration, see the Declarative configuration import for ACP article.

Prerequisites

1. All prerequisites for Declarative configuration import for ACP are met.

2. Istio version 1.9 or subsequent is installed and up and running.

3. Istio Authorizer is added as an extension provider for your Istio Service Mesh.

   For instructions on how to define Istio Authorizer as an external authorization provider for Istio, see Installing Istio Authorizer guide.

4. Service of your choice deployed in your Kubernetes cluster

   You need to deploy a service in order to be able to import APIs to your ACP instance and apply access control to protect them.

   Tip

   If you do not have a deployment-ready service at hand, you can deploy, for example, a httpbin service which can be found in the acp-on-k8s GitHub repository. For more instructions regarding protecting HTTP services, see Deploying and protecting HTTP services article.

Import Istio Authorizer

1. Edit your acp-cd Helm Chart’s values.yaml file and provide your configuration definition for Istio Authorizer and its client application.

   Importing authorizers

   To learn how to import authorizers to ACP, see Authorizers section of the Declarative configuration import for ACP article.

   data:
     gateways:
       - tenant_id: {tid}
         authorization_server_id: {aid}
         id: sample-istio-authorizer
         client_id: istio-authorizer-client
         client_secret: cf53caab-fb55-40a7-8c63-620ce11102e2
         name: Sample Istio Authorizer
         description: Sample imported Istio Authorizer
         type: istio
         create_and_bind_services_automatically: true
     clients:
       - tenant_id: {tid}
         authorization_server_id: system
         client_id: istio-authorizer-client
         client_secret: cf53caab-fb55-40a7-8c63-620ce11102e2
         token_endpoint_auth_method: client_secret_basic
         system: false
         trusted: false
         client_name: Istio Authorizer client
         application_type: web
         grant_types:
           - client_credentials
         response_types:
           - code
         scopes:
           - introspect_tokens
           - push_gateway_requests
           - read_gateway_configuration
           - write_gateway_configuration
   

2. Upgrade your Helm Chart.

Result

Your Istio Authorizer is imported to ACP and a client application for the authorizer is created in the System workspace of your tenant.

Install Istio Authorizer in k8s

Install Istio Authorizer using its Helm Chart and adjust its configuration to your needs. You do not need to manually create your authorizer in ACP’s UI as you had already imported the authorizer in the previous step of this guide.

Import API groups and services

To learn how to import API groups and services and to know what are the possible scenarios that differ between your authorizer configuration for service discovery, get familiar with the API groups and services section of the Declarative configuration import for ACP article.

For Istio Authorizer, API group identifier and service identifiers are Base64 URL encoded SPIFFE IDs which are built being based on the service account of the protected pod. To avoid using long and unreadable API groups identifiers, ACP supports Base64 encoding of SPIFFE IDs.

You can define your API group identifier using the encSpiffeID function as shown below:

gateway_api_groups:
  - id: "{{ encSpiffeID \"spiffe://{domain}/ns/{namespace}/sa/{service_account}" }}"

You can define your service identifier using the encServiceID function as shown below:

services:
  - id: "{{ encServiceID \"spiffe://{domain}/ns/{namespace}/sa/{service_account}" }}"

1. Prepare your values.yaml file.

   If you disabled service discovery for your authorizer, an import example can look like the following:

   data:
     gateway_api_groups:
       - tenant_id: {tid}
         server_id: {aid}
         id: {{ encSpiffeID "spiffe://cluster.local/ns/default/sa/httpbin" }}
         service_id: httpbin-service
         gateway_id: sample-istio-authorizer
         name: default/httpbin_api_group
         apis:
           - method: GET
             path: /deny
           - method: GET
             path: /anything
     services:
       - id: httpbin-service
         tenant_id: {tid}
         authorization_server_id: {aid}
         gateway_id: sample-istio-authorizer
         name: default/httpbin_service
         apis:
           - method: GET
             path: /deny
             can_have_policy: true
             policy_id: block_api
           - method: GET
             path: /anything
             can_have_policy: true
             policy_id: block_api
   

   You can see that in the example above, the service identifier is not encoded. When you encode your API group identifier, you do not need to encode the service ID. You can encode it if you wish, but then, in the service_id parameter of the gateway_api_groups object, you need to provide the encoded service identifier as well.

   If the service discovery setting is enabled for your authorizer, an import example can look like the following:

   data:
     services:
       - id: {{ encServiceID "spiffe://cluster.local/ns/default/sa/httpbin" }}
         tenant_id: corelia
         authorization_server_id: test-authz
         gateway_id: sample-istio-authorizer
         name: default/httpbin_service
         apis:
           - method: GET
             path: /deny
             can_have_policy: true
             policy_id: block_api
           - method: GET
             path: /anything
             can_have_policy: true
             policy_id: block_api
   

   You can see that to avoid long and unreadable service ID, it is encoded using the {{ encServiceID }} function.

   Policies assignment

   The above example includes policies already assigned to your APIs. You can assign policies when importing services as long as they already exist within ACP or are imported as a part of the same values.yaml file.

2. Upgrade your Helm Chart.

Result

Your API groups and services are imported to ACP and visible in the APIs view.

If you imported the definition for services with policies assigned, your APIs are already protected. If not, you can assign them manually.