Alibaba Cloud Service Mesh：在ASM網關中使用數位憑證管理服務提供的SSL認證

前提條件

• 已在數位憑證管理服務中購買或上傳可用的SSL認證。

• 已部署httpbin應用。

步驟一：為數位憑證管理服務授予指定許可權

數位憑證管理服務會使用AliyunCASDefaultRole訪問並操作ACK叢集，需要提前為該角色進行授權。

1. 登入Container Service管理主控台，在左側導覽列選擇授權管理。

2. 選擇RAM 角色頁簽，在輸入框中輸入AliyunCASDefaultRole，單擊系統管理權限。

   若提示AliyunCASDefaultRole 不存在，請先為數位憑證管理服務建立RAM角色並授權。

3. 在許可權管理彈框中單擊+ 添加許可權，在叢集列的下拉框中選擇要操作的叢集名稱，在命名空間列的下拉框中選擇istio-system，在許可權管理列的下拉框中選擇受限使用者。

4. 單擊提交授權。

步驟二：部署認證到ACK叢集

本文使用的認證網域名稱為test.com，您可以根據實際需要進行修改。

1. 部署認證。

   1. 登入數位憑證管理服務控制台。

   2. 在左側導覽列，選擇認證管理 > SSL認證管理。

   3. 在SSL證書管理頁面，單擊對應的認證頁簽，並在認證列表的操作列，單擊部署。

      通過私人CA服務簽發的認證會同步至上傳認證頁簽，您可以在該頁簽進行操作。

   4. 在創建任務頁面的選擇資源引導頁，選擇或調整對應的雲產品和資源（支援選擇一個或多個雲產品及對應資源），單擊預覽並提交。

      • 系統會根據您選擇的SSL認證智能匹配已經配置過SSL認證的雲產品資源，您可以在智能匹配提示對話方塊，單擊確定，系統會將匹配到的雲產品資源添加到已選擇資源地區，隨後您可以根據需求對已選擇的雲產品資源進行調整。

        

      • 系統會自動識別並拉取所有雲產品中的資源，如果您在對應的雲產品中未找到目標資源，請您確認以下事項：

        • 在資源總數地區確認資源是否已完成同步，如果資源正在同步中（如圖示灰色狀態），請您耐心等待資源同步完成。資源同步時間取決於您的當前雲產品的資源數。

          

        • 如果雲產品資源同步完成後仍然沒有找到對應資源，請您確認是否滿足認證部署前提條件。

   5. 在任務預覽面板，確認部署的認證執行個體和雲產品資源資訊，如無問題，單擊提交。

      預覽頁面會顯示對應雲產品匹配的認證個數和消耗的部署次數。認證匹配個數為0表示您選擇的認證與雲產品資源不匹配，會導致部署失敗，請您仔細核對選擇的認證。

2. 擷取Secret資訊。

   kubectl -n istio-system get secret -l alibabacloud.com/ssl-certificate-identifier=${SSL認證的CertIdentifier}

   預期輸出：

   NAME                TYPE                DATA   AGE
   cas-cert-305xxx76   kubernetes.io/tls   2      10m

步驟三：更新網關規則

更新部署httpbin應用時建立的網關規則，增加host和上一步建立的Secret。

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: httpbin
  namespace: default
spec:
  selector:
    istio: ingressgateway
  servers:
    - hosts:
        - '*'
      port:
        name: test
        number: 80
        protocol: HTTP
    - hosts:
        - 'test.com'
      port:
        name: https
        number: 443
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: ${上一步擷取到的Secret名稱}
EOF

步驟四：測試訪問

1. 擷取網關IP。

   export GATEWAY_IP=$(kubectl get service istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}' )

2. 發起測試請求。

   curl -vk --resolve test.com:443:${GATEWAY_IP} https://test.com/status/418

   預期輸出：

   * Added test.com:443:47.xx.xxx.146 to DNS cache
   * Hostname test.com was found in DNS cache
   *   Trying 47.xx.xxx.146...
   * TCP_NODELAY set
   * Connected to test.com (47.xx.xxx.146) port 443 (#0)
   * ALPN, offering h2
   * ALPN, offering http/1.1
   * successfully set certificate verify locations:
   *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
     CApath: none
   ...
   * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
   * ALPN, server accepted to use h2
   * Server certificate:
   *  subject: CN=test.com; O=myexample organization
   *  start date: Jul 28 09:19:32 2025 GMT
   *  expire date: Jul 28 09:19:32 2026 GMT
   *  issuer: O=myexample Inc.; CN=test.com
   *  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
   * Using HTTP2, server supports multi-use
   * Connection state changed (HTTP/2 confirmed)
   * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
   ...
   > GET /status/418 HTTP/2
   > Host: test.com
   > User-Agent: curl/7.61.1
   > Accept: */*
   > 
   ...
   < HTTP/2 418 
   < server: istio-envoy
   < date: Tue, 29 Jul 2025 08:45:10 GMT
   < x-more-info: http://tools.ietf.org/html/rfc2324
   < access-control-allow-origin: *
   < access-control-allow-credentials: true
   < content-length: 135
   < x-envoy-upstream-service-time: 5
   < 
   
       -=[ teapot ]=-
   
          _...._
        .'  _ _ `.
       | ."` ^ `". _,
       \_;`"---"`|//
         |       ;/
         \_     _/
           `"""`
   * Connection #0 to host test.com left intact

   可以看到，請求返回的資訊包括了TLS相關資訊以及正常的418響應。