Implement custom authorization by using an ingress gateway - Alibaba Cloud Service Mesh

This topic describes how to implement custom authorization by using an ingress gateway. A productpage application is used in the example.

Prerequisites

Background information

When a user initiates a service request, the backend needs to verify the validity of the user request. For example, the backend checks whether the user has permissions to access the requested resources. If the user passes the authentication, the message returned contains some additional information. For example, the service version number and user ID are added in the response header.

Service Mesh (ASM) allows you to define custom authorization services to meet the preceding requirements. The authentication process is implemented by using an ingress gateway to ensure that only authorized users can access key services.

Custom authorization is an advanced security feature of ASM. Use this feature if you have special security requirements. If your security requirements are common, see Configure a blacklist or whitelist for an ingress gateway or the Authorization policies section in the Overview of zero trust security topic.

Configuration description

You can customize authorization services based on your business needs. In this example, a custom authorization service is deployed for an ingress gateway to authenticate requests that are routed to the ingress gateway. The requests are allowed or denied based on the authentication results.

You need to specify the following configurations:

The information that is required for the ingress gateway to connect with the custom authorization service
The requests that need to be authenticated by using the custom authorization service

Step 1: Deploy a custom authorization service

Deploy a custom authorization service in a Container Service for Kubernetes (ACK) cluster. This service must comply with the API specifications of Istio for custom authentication services and support HTTP and gRPC protocols. The sample authorization service provided in this topic specifies that only requests with the x-ext-authz: allow header can pass the authentication.

Note

You can create a custom authorization service based on the sample code in this topic. For more information, see extauthz.

Use kubectl to connect to the ACK cluster. For more information, see Connect to ACK clusters by using kubectl.

Create an ext-authz.yaml file that contains the following content:

# Copyright Istio Authors
#
#   Licensed under the Apache License, Version 2.0 (the "License");
#   you may not use this file except in compliance with the License.
#   You may obtain a copy of the License at
#
#       http://www.apache.org/licenses/LICENSE-2.0
#
#   Unless required by applicable law or agreed to in writing, software
#   distributed under the License is distributed on an "AS IS" BASIS,
#   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#   See the License for the specific language governing permissions and
#   limitations under the License.

# Example configurations for deploying ext-authz server separately in the mesh.

apiVersion: v1
kind: Service
metadata:
  name: ext-authz
  labels:
    app: ext-authz
spec:
  ports:
  - name: http
    port: 8000
    targetPort: 8000
  - name: grpc
    port: 9000
    targetPort: 9000
  selector:
    app: ext-authz
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ext-authz
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ext-authz
  template:
    metadata:
      labels:
        app: ext-authz
    spec:
      containers:
      - image: istio/ext-authz:0.6
        imagePullPolicy: IfNotPresent
        name: ext-authz
        ports:
        - containerPort: 8000
        - containerPort: 9000
---

Run the following command to deploy the authorization service in the ACK cluster:
```
kubectl apply -f ext-authz.yaml
```

Run the following command to query the pod status:

kubectl get pod

Expected output:

NAME                READY  STATUS  RESTARTS      AGE
ext-authz-6d458d5f8f-bh2m9        2/2     Running   0              1m

Run the following command to check whether the ext-authz application works as expected.

kubectl logs "$(kubectl get pod -l app=ext-authz -n default -o jsonpath={.items..metadata.name})" -n default -c ext-authz

Expected output:

2022/08/07 22:55:47 Starting HTTP server at [::]:8000
2022/08/07 22:55:47 Starting gRPC server at [::]:9000

If the preceding result is returned, the application works properly and the authorization service is deployed.

Obtain the gRPC and HTTP ports of the ext-authz service.
1. Log on to the ACK console and click Clusters in the left-side navigation pane.
2. On the Clusters page, click the name of a cluster and choose Network > Services in the left-side navigation pane.
3. On the Services page, click ext-authz.
  In the Endpoint section, you can see that the port of the gRPC protocol is 9000 and the port of the HTTP protocol is 8000. Therefore, the gRPC address used to access the service is ext-authz.default.svc.cluster.local:9000 and the HTTP address is ext-authz.default.svc.cluster.local:8000.

Step 2: Configure a custom authorization service that uses the HTTP protocol for an ingress gateway

ASM integrates the custom authorization capability. You can configure a custom authorization service in the ASM console.

Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.
On the Ingress Gateway page, click the ingress gateway for which you want to configure a custom authorization service.
In the left-side navigation pane, choose Mesh Security Center > Custom Authorization Service.
In the first step of the configuration wizard, turn on Enable Gateway Custom Authorization Service, use one of the following methods to configure a custom authorization service, and then click Next.
- Method 1: No custom authorization service is created
  On the Custom authorization service (HTTP or gRPC protocol) implemented based on envoy.ext_authz tab, configure the parameters. For more information about the parameters, see Implement custom authorization by using the HTTP protocol.
- Method 2: A custom authorization service is available
  On the Import existing Custom Authorization Service tab, select the existing custom authorization service.
In the Match Rules step of the configuration wizard, configure the parameters and click Submit.
Requests that match this rule will be authenticated by using the authorization service.
After the configuration is complete, a message appears, indicating that the ASM security policy is created.

Step 3: Verify that custom authorization can be implemented by using the ingress gateway

Run the following command to access http://{IP address of the ingress gateway}/api/v1/products:
```
 curl -I http://{IP address of the ingress gateway}/api/v1/products
```
Expected output:
```
HTTP/1.1 200 OK
content-type: application/json
content-length: 395
server: istio-envoy
date: Fri, 23 Dec 2022 02:58:47 GMT
x-envoy-upstream-service-time: 2
```
The preceding result indicates that custom authorization is not triggered. The reason is that the path is /api/v1/products instead of /productpage configured in the preceding step.
Run the following command to use a request with the x-ext-authz: deny header to access http://{IP address of the ingress gateway}/productpage:
```
curl -I -H "x-ext-authz: deny" http://{IP address of the ingress gateway}/productpage
```
Expected output:
```
HTTP/1.1 403 Forbidden
x-ext-authz-check-result: denied
content-length: 76
content-type: text/plain; charset=utf-8
date: Fri, 23 Dec 2022 03:00:43 GMT
server: istio-envoy

denied by ext_authz for not found header `x-ext-authz: allow` in the request%
```
The preceding result indicates that custom authorization is triggered but the authentication fails. The returned result contains the newly added response header x-ext-authz-check-result: denied. The reason why custom authorization is triggered is that the path is /productpage defined in the authorization policy.
Run the following command to use a request with the x-ext-authz: allow header to access http://{IP address of the ingress gateway}/productpage:
```
curl -I -H "x-ext-authz: allow" http://{IP address of the ingress gateway}/productpage
```
Expected output:
```
TP/1.1 200 OK
content-type: text/html; charset=utf-8
content-length: 4294
server: istio-envoy
date: Fri, 23 Dec 2022 03:02:28 GMT
x-envoy-upstream-service-time: 17
```
The preceding result indicates that custom authorization is triggered and the authentication is successful. The returned result contains the newly added response header x-ext-authz-check-result: allowed. After the authentication is successful, the request forwarded by the ingress gateway to the application carries the x-ext-authz-check-result: allowed header, which meets expectations.

Implementation process of custom authorization

ASM encapsulates the custom authorization feature of Istio. For more information about how the custom authorization feature of Istio is implemented, see the native Istio resources that are generated after you configure the custom authorization service. The following example shows how custom authorization is implemented in ASM:

Define a custom authorization service and associate the service with the ingress gateway in ASM. This way, ASM can use the custom authorization service to perform authentication. For more information about how to define a custom authorization service, see Step 1.
Create an authorization policy in ASM, configure an application that requires authorization, and then perform authentication by using the custom authorization service that you configured in Step 2.