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

When to use custom authorization

Custom authorization is an advanced security feature of Service Mesh (ASM). Choose the approach that best fits your requirements:

How it works

ASM encapsulates the custom authorization feature of Istio. The request flow is:

1. A client sends a request to the ingress gateway.

2. The ingress gateway forwards the request to the custom authorization service for evaluation.

3. The authorization service returns an allow or deny decision.

4. If allowed, the ingress gateway routes the request to the backend service. The response may contain additional information, such as the service version number and user ID in the response header. If denied, the gateway returns an HTTP 403 response.

Step 1: Deploy the external authorization service

Deploy a custom authorization service in an ACK cluster. The service must comply with the Istio ext-authz API specification and support both HTTP and gRPC protocols.

The sample service used here allows only requests that include the x-ext-authz: allow header. To build your own authorization service, see the Istio ext-authz sample code.

1. Create a file named ext-authz.yaml with the following content:

   Show the ext-authz.yaml file

      # 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.
   
      # Deploys the ext-authz service as a standalone service 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

2. Apply the manifest:

      kubectl apply -f ext-authz.yaml

3. Verify the pod is running: Expected output:

      kubectl get pod

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

4. Check the logs to confirm the ext-authz service started: Expected output: Both the HTTP server (port 8000) and gRPC server (port 9000) should be running.

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

      2023/12/12 10:01:31 Starting HTTP server at [::]:8000
      2023/12/12 10:01:31 Starting gRPC server at [::]:9000

5. Record the service addresses for the next step. The ext-authz service exposes two endpoints in the default namespace: You can also verify these ports in the ACK console: go to Clusters > select your cluster > Network > Services > ext-authz, and check the Endpoint section.

   Protocol	Port	Service address
   HTTP	8000	ext-authz.default.svc.cluster.local:8000
   gRPC	9000	ext-authz.default.svc.cluster.local:9000

Step 2: Configure the ingress gateway to use the authorization service

Connect the ext-authz service to the ingress gateway through the ASM console and define which requests require authorization.

1. Log on to the ASM console.

2. In the left-side navigation pane, choose Service Mesh > Mesh Management.

3. On the Mesh Management page, click the name of the ASM instance.

4. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.

5. Click the target ingress gateway.

6. In the left-side navigation pane, choose Gateway Security > Custom Authorization Service.

7. In the Custom Authorization Service Configuration step, turn on Enable Gateway Custom Authorization Service.

8. Configure the authorization service using one of the following methods, and then click Next.

   Method 1: Create a new authorization service

   On the Custom authorization service (HTTP or gRPC protocol) implemented based on envoy.ext_authz tab, specify the protocol, service address, and port. For parameter details, see Implement custom authorization by using the HTTP protocol.

   Method 2: Import an existing authorization service

   On the Import existing Custom Authorization Service tab, select a previously configured authorization service.

9. In the Match Rules step, specify which requests require authorization, and then click Submit. For example, to authorize all requests to the /productpage path, set the path match accordingly. After the configuration is saved, the message Gateway Custom Authorization Service Created successfully appears.

   

Step 3: Verify the setup

Test the authorization service with three scenarios to confirm it works as expected. Replace <ingress-gateway-ip> with the IP address of your ingress gateway. To get this IP, see Substep 1 in Step 3 in Use Istio resources to route traffic to different versions of a service.

Scenario 1: Non-matching paths bypass authorization

Send a request to /api/v1/products, a path not covered by the match rules:

curl -I http://<ingress-gateway-ip>/api/v1/products

Expected output:

HTTP/1.1 200 OK
server: istio-envoy
date: Wed, 13 Dec 2023 02:41:20 GMT
content-type: application/json
content-length: 395
x-envoy-upstream-service-time: 1

The request succeeds because /api/v1/products is not configured for custom authorization. Only requests matching the paths defined in the match rules are sent to the ext-authz service.

Scenario 2: Unauthorized requests are denied

Send a request to /productpage with the x-ext-authz: deny header:

curl -I -H "x-ext-authz: deny" http://<ingress-gateway-ip>/productpage

Expected output:

HTTP/1.1 403 Forbidden
x-ext-authz-check-result: denied
date: Wed, 13 Dec 2023 02:42:59 GMT
server: istio-envoy
transfer-encoding: chunked

The request is denied because the path /productpage matches the authorization policy, and the ext-authz service rejects requests without the x-ext-authz: allow header. The x-ext-authz-check-result: denied header in the response is added by the authorization service.

Scenario 3: Authorized requests are allowed

Send a request to /productpage with the x-ext-authz: allow header:

curl -I -H "x-ext-authz: allow" http://<ingress-gateway-ip>/productpage

Expected output:

HTTP/1.1 200 OK
server: istio-envoy
date: Wed, 13 Dec 2023 02:50:38 GMT
content-type: text/html; charset=utf-8
content-length: 5290
x-envoy-upstream-service-time: 47

The request succeeds. The response contains the x-ext-authz-check-result: allowed header added by the authorization service. After the authentication is successful, the ingress gateway also forwards the request to the backend application with the x-ext-authz-check-result: allowed header attached.

See also

• Configure a blacklist or whitelist for an ingress gateway: Reject or allow requests by IP address, domain name, or port.

• Configure OIDC-based SSO on an ingress gateway: Authenticate users through identity providers that comply with the OpenID Connect (OIDC) protocol.