DocsICP FilingConsole
官方文档
首页

Use custom authorization on an ASM ingress gateway

更新时间：
复制 MD 格式
产品详情
我的收藏

To customize access control policies, such as authorizing requests based on HTTP hostnames, paths, or methods, you can use a custom authorization service on an ASM ingress gateway. This ensures that only authorized users can access your critical services.

Prerequisites

Overview

When a client sends a request, the backend needs to verify its validity, for example, by checking if the user has permission to access the requested resource. After successful authorization, you might also need to add information to the response that was not in the original request, such as a service version number or a user ID in the header. ASM provides a custom authorization service. You can add an authorization flow on an ASM ingress gateway to ensure that critical services can be accessed only with proper authorization.

A custom authorization service is a service you develop. This topic uses a simple, pre-built authorization service as an example. It directs specific requests that arrive at the ingress gateway to the custom authorization service, which then decides whether to allow or deny the request. The ingress gateway enforces that decision. You must configure the following two parts:

  • The integration details between the ingress gateway and the custom authorization service.

  • The rules that specify which requests require custom authorization.

A custom authorization service is an advanced security feature of the Service Mesh. If you have simple requirements, consider using a gateway blacklist/whitelist or a standard authorization policy. For more complex logic, follow the steps in this topic.

Implementation flow

ASM encapsulates Istio's custom authorization feature. If you want to understand the native Istio implementation, you can inspect the native Istio resources that ASM generates. The implementation flow for an ASM custom authorization service is as follows:

  1. Define a custom authorization service in ASM and associate it with the service deployed in Step 1. This allows ASM to use the service for authorization.

  2. In ASM, create an authorization policy to configure the application that requires custom authorization and direct authorization to the custom authorization service configured in Step 2.

基于ASM实现应用请求认证授权

Step 1: Deploy the custom authorization service

Deploy a custom authorization service in your ACK cluster. The service must comply with the Istio custom authorization service API specification and support both HTTP and gRPC protocols to implement custom logic. The example service used in this topic requires that requests include the x-ext-authz: allow header to pass authorization.

Note

This topic provides an example of a custom authorization service. You can use its code as a reference to create your own. For more information, see Custom authorization.

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

    View ext-authz.yaml

    # 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, 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
---

  2. Run the following command to deploy the custom authorization service in your cluster.

    To learn how to manage clusters and applications with kubectl, see Connect to a cluster by using kubectl.

    kubectl apply -f ext-authz.yaml

  3. Run the following command to check the pod status.

    kubectl get pod

    Expected output:

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

  4. Run the following command to verify that the application is running correctly.

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

    Expected output:

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

    This output confirms that the service is running correctly.

  5. Obtain the gRPC and HTTP ports of the ext-authz authorization service.

    1. Log on to the ACK console. In the left navigation pane, click Clusters.

    2. On the Clusters page, click the name of your cluster. In the left navigation pane, click Network > Services.

    3. On the Services page, click ext-authz.

      In the Endpoint section, you can see that the gRPC port is 9000 and the HTTP port is 8000. Therefore, the gRPC service address is ext-authz.default.svc.cluster.local:9000, and the HTTP service address is ext-authz.default.svc.cluster.local:8000.

Step 2: Configure an HTTP custom authorization service

You can configure the custom authorization capabilities of the ASM ingress gateway in the ASM console.

  1. Log on to the ASM console. In the left-side navigation pane, choose Service Mesh > Mesh Management.

  2. On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose ASM Gateways > Ingress Gateway.

  3. On the Ingress Gateway page, click the name of the target gateway.

  4. On the gateway overview page, click Gateway Security > Custom Authorization Service in the navigation pane.

  5. In the Custom Authorization Service Configuration wizard, turn on the Enable Gateway Custom Authorization Service switch, configure the service by using one of the following methods, and then click Next.

    Method 1: Create a new custom authorization service

    On the Custom authorization service (HTTP or gRPC protocol) implemented based on envoy.ext_authz tab, configure the parameters. For a description of the parameters, see Connect to a custom authorization service that uses the HTTP protocol. Configure the following required parameters in the form: set Protocol to HTTP, Service Address to ext-authz.default.svc.cluster.local, Service Port to 8000 (valid range: 1–65535), and Timeout to 10 seconds. Turn on Include headers in the authorization request (includeRequestHeadersInCheck) and add the original request headers to be forwarded, including cookie, x-forwarded-access-token, x-forwarded-user, x-forwarded-email, authorization, x-forwarded-proto, proxy-authorization, user-agent, x-forwarded-host, from, x-forwarded-for, accept, and x-ext-authz (a custom extended header). Turn on Override headers on allow (headersToUpstreamOnAllow) and add the following headers: authorization, cookie, path, x-auth-request-access-token, x-forwarded-access-token, and x-ext-authz-check-result. Turn on Override headers on deny (headersToDownstreamOnDeny) and add the following headers: content-type, set-cookie, and x-ext-authz-check-result. The x-ext-authz-check-result header is a key header that must be configured in both lists. Click Next.

    Method 2: Import an existing custom authorization service

    On the Import existing Custom Authorization Service tab, select an Existing Custom Authorization Service.

  6. In the Matching Rules wizard, configure the following settings and then click Submit.

    Requests that match this rule will trigger custom authorization. Set Match Mode to Selected requests must be authorized and Match Rule to Custom match rules. Turn on the HTTP Path switch and enter /productpage. Leave the other rule options (HTTP Hostname, HTTP Method, and Port) turned off.

    When the configuration is complete, a message confirms that the Gateway Custom Authorization Service Created successfully.

Step 3: Verify the custom authorization service

  1. Run the following command to access the resource at the /api/v1/products path on the gateway.

    To learn how to obtain the gateway address, see Obtain the IP address of an ingress gateway.

    curl -I http://{YOUR_ASM_GATEWAY_ADDRESS}/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

    This result indicates that authorization was not triggered. The access path is /api/v1/products, not the configured /productpage, so the request does not match the authorization policy.

  2. Run the following command to access the /productpage path with a x-ext-authz: deny header.

    curl -I -H "x-ext-authz: deny" http://{YOUR_ASM_GATEWAY_ADDRESS}/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

    This result shows that authorization was triggered but failed. The response includes the newly defined header x-ext-authz-check-result: denied. Because the access path is /productpage, it matches the authorization policy.

  3. Run the following command to access the /productpage path with an x-ext-authz: allow header.

    curl -I -H "x-ext-authz: allow" http://{YOUR_ASM_GATEWAY_ADDRESS}/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

    This result confirms that the request was successfully authorized. The example custom authorization service adds this header to its response, and the gateway is configured to forward it to the upstream application on successful authorization.

Related documentation

Previous：Configure a blacklist or whitelist for an ingress gatewayNext：Configure OIDC SSO on an ASM gateway