安全是一個(gè)非常重要的話題，但也是平時(shí)容易被忽略的一個(gè)話題，我們?cè)陂_發(fā)應(yīng)用的時(shí)候，往往會(huì)忽略安全，但是當(dāng)應(yīng)用上線后，安全問(wèn)題就會(huì)暴露出來(lái)，這時(shí)候就會(huì)造成很大的損失。Istio 通過(guò)在服務(wù)之間注入 Sidecar 代理，來(lái)實(shí)現(xiàn)對(duì)服務(wù)之間的流量進(jìn)行控制和監(jiān)控，從而實(shí)現(xiàn)服務(wù)之間的安全通信。

接下來(lái)我們將從證書管理、認(rèn)證、授權(quán)等幾個(gè)方面來(lái)學(xué)習(xí) Istio 的安全機(jī)制。

安全概述

將單一應(yīng)用程序拆分為微服務(wù)可提供各種好處，包括更好的靈活性、可伸縮性以及服務(wù)復(fù)用的能力。但是，微服務(wù)也有特殊的安全需求：

• 為了抵御中間人攻擊，需要流量加密。
• 為了提供靈活的服務(wù)訪問(wèn)控制，需要雙向 TLS 和細(xì)粒度的訪問(wèn)策略。
• 要確定誰(shuí)在什么時(shí)候做了什么，需要審計(jì)工具。

Istio 嘗試提供全面的安全解決方案來(lái)解決所有這些問(wèn)題，Istio 安全性可以減輕針對(duì)你的數(shù)據(jù)、端點(diǎn)、通信和平臺(tái)的內(nèi)外威脅。

安全概述

Istio 為微服務(wù)提供了無(wú)侵入，可插拔的安全框架。應(yīng)用不需要修改代碼，就可以利用 Istio 提供的雙向 TLS 認(rèn)證實(shí)現(xiàn)服務(wù)身份認(rèn)證，并基于服務(wù)身份信息提供細(xì)粒度的訪問(wèn)控制。Istio 安全的高層架構(gòu)如下圖所示：

安全架構(gòu)

上圖展示了 Istio 中的服務(wù)認(rèn)證和授權(quán)兩部分。服務(wù)認(rèn)證是通過(guò)控制面和數(shù)據(jù)面一起實(shí)現(xiàn)的：

• 控制面：Istiod 中實(shí)現(xiàn)了一個(gè) CA （Certificate Authority，證書機(jī)構(gòu)） 服務(wù)器。該 CA 服務(wù)器負(fù)責(zé)為網(wǎng)格中的各個(gè)服務(wù)簽發(fā)證書，并將證書分發(fā)給數(shù)據(jù)面的各個(gè)服務(wù)的邊車代理。
• 數(shù)據(jù)面：在網(wǎng)格中的服務(wù)相互之間發(fā)起 plain HTTP/TCP 通信時(shí)，和服務(wù)同一個(gè) pod 中的邊車代理會(huì)攔截服務(wù)請(qǐng)求，采用證書和對(duì)端服務(wù)的邊車代理進(jìn)行雙向 TLS 認(rèn)證并建立一個(gè) TLS 連接，使用該 TLS 連接來(lái)在網(wǎng)絡(luò)中傳輸數(shù)據(jù)。

Istio 的授權(quán)功能為網(wǎng)格中的工作負(fù)載提供網(wǎng)格、命名空間和工作負(fù)載級(jí)別的訪問(wèn)控制，這種控制層級(jí)提供了許多優(yōu)點(diǎn)：

• 工作負(fù)載到工作負(fù)載以及最終用戶到工作負(fù)載的授權(quán)。
• 一個(gè)簡(jiǎn)單的 API：它包括一個(gè)單獨(dú)的并且很容易使用和維護(hù)的 AuthorizationPolicy CRD。
• 靈活的語(yǔ)義：運(yùn)維人員可以在 Istio 屬性上定義自定義條件，并使用 DENY 和 ALLOW 動(dòng)作。
• 高性能：Istio 授權(quán)是在 Envoy 本地強(qiáng)制執(zhí)行的。
• 高兼容性：原生支持 HTTP、HTTPS 和 HTTP2，以及任意普通 TCP 協(xié)議。

授權(quán)策略對(duì)服務(wù)器端 Envoy 代理的入站流量實(shí)施訪問(wèn)控制。每個(gè) Envoy 代理都運(yùn)行一個(gè)授權(quán)引擎，該引擎在運(yùn)行時(shí)授權(quán)請(qǐng)求。當(dāng)請(qǐng)求到達(dá)代理時(shí)，授權(quán)引擎根據(jù)當(dāng)前授權(quán)策略評(píng)估請(qǐng)求上下文，并返回授權(quán)結(jié)果 ALLOW 或 DENY。運(yùn)維人員可以通過(guò) YAML 資源清單文件來(lái)指定 Istio 授權(quán)策略。

授權(quán)策略

證書簽發(fā)流程

默認(rèn)情況下，Istio CA 生成自簽名根證書和密鑰，并使用它們來(lái)簽署工作負(fù)載證書。為了保護(hù)根 CA 密鑰，我們應(yīng)該使用在安全機(jī)器上離線運(yùn)行的根 CA（比如使用 Hashicorp Vault 進(jìn)行管理），并使用根 CA 向每個(gè)集群中運(yùn)行的 Istio CA 頒發(fā)中間證書。Istio CA 可以使用管理員指定的證書和密鑰對(duì)工作負(fù)載證書進(jìn)行簽名，并將管理員指定的根證書作為信任根分發(fā)給工作負(fù)載。

CA

簽發(fā)證書

當(dāng)我們有了 Istio CA 根證書后就可以使用它來(lái)簽發(fā)工作負(fù)載證書了，那么整個(gè)的證書簽發(fā)流程又是怎樣的呢？如下圖所示：

證書簽發(fā)流程

• Envoy 向 pilot-agent 發(fā)起一個(gè) SDS (Secret Discovery Service) 請(qǐng)求（啟動(dòng)的時(shí)候），要求獲取自己的證書和私鑰。
• pilot-agent 生成私鑰和 CSR 證書簽名請(qǐng)求，向 Istiod 發(fā)送證書簽發(fā)請(qǐng)求，請(qǐng)求中包含 CSR 和該 Pod 中服務(wù)的身份信息。
• Istiod 提供 gRPC 服務(wù)以接受證書簽名請(qǐng)求，根據(jù)請(qǐng)求中服務(wù)的身份信息（如果是 Kubernetes 則使用 Service Account）為其簽發(fā)證書，將證書返回給 pilot-agent。
• pilot-agent 將證書和私鑰通過(guò) SDS 接口返回給 Envoy。
• pilot-agent 還會(huì)監(jiān)控工作負(fù)載證書的過(guò)期時(shí)間，上述過(guò)程會(huì)定期重復(fù)進(jìn)行證書和密鑰輪換。

這個(gè)流程和我們自己用手動(dòng)方式去進(jìn)行證書簽發(fā)是一樣的，所以我們需要先了解下證書簽發(fā)的流程。Istio CA 根證書就是一個(gè)證書頒發(fā)機(jī)構(gòu)，平時(shí)如果要為我們自己的網(wǎng)站申請(qǐng) HTTPS 證書我們也是去一些正規(guī)的 CA 機(jī)構(gòu)進(jìn)行申請(qǐng)，而這個(gè)申請(qǐng)的信息就是生成的 CSR 證書簽名請(qǐng)求，然后我們將這個(gè) CSR 和身份信息提交給 CA 機(jī)構(gòu)，CA 機(jī)構(gòu)根據(jù)這些信息為我們簽發(fā)證書，然后我們就可以使用這個(gè)證書了，只是我們這里在不同的組件上來(lái)執(zhí)行這些操作，整體流程是一樣的。

身份認(rèn)證

另外要通過(guò)服務(wù)證書來(lái)實(shí)現(xiàn)網(wǎng)格中服務(wù)的身份認(rèn)證，必須首先確保服務(wù)從控制面獲取自身證書的流程是安全的。Istio 通過(guò) Istiod 和 pilog-agent 之間的 gRPC 通道傳遞 CSR 和證書，因此在這兩個(gè)組件進(jìn)行通信時(shí)，雙方需要先驗(yàn)證對(duì)方的身份，以避免惡意第三方偽造 CSR 請(qǐng)求或者假冒 Istiod CA 服務(wù)器。Istio 中主要包含下面兩種認(rèn)證方式：

• Istiod 身份認(rèn)證

• Istiod 采用其內(nèi)置的 CA 服務(wù)器為自身簽發(fā)一個(gè)服務(wù)器證書，并采用該服務(wù)器證書對(duì)外提供基于 TLS 的 gPRC 服務(wù)。
• Istiod 調(diào)用 Kubernetes APIServer 生成一個(gè)名為 istio-ca-root-cert 的 ConfigMap 對(duì)象， 在該 ConfigMap 中放入了 Istiod 的 CA 根證書。
• 該 ConfigMap 被 Mount 到 istio-proxy 容器中，被 pilot-agent 用于驗(yàn)證 Istiod 的服務(wù)器證書。
• 在 pilot-agent 和 Istiod 建立 gRPC 連接時(shí)，pilot-agent 采用標(biāo)準(zhǔn)的 TLS 服務(wù)器認(rèn)證流程對(duì) Istiod 的服務(wù)器證書進(jìn)行認(rèn)證。

• pilot-agent 身份認(rèn)證

• 在 Kubernetes 中可以為每一個(gè) Pod 關(guān)聯(lián)一個(gè) ServiceAccount，以表明該 Pod 中運(yùn)行的服務(wù)的身份信息。

• Kubernetes 會(huì)為該 ServiceAccount 生成一個(gè) jwt token，并將該 token 通過(guò) secret 加載到 pod 中的一個(gè)文件。

• pilot-agent 在向 Istiod 發(fā)送 CSR 時(shí)，將其所在 Pod 的 service account token 也隨請(qǐng)求發(fā)送給 Istiod。

• Istiod 調(diào)用 Kube-apiserver 接口驗(yàn)證請(qǐng)求中附帶的 service account token，以確認(rèn)請(qǐng)求證書的服務(wù)身份是否合法。

這里需要注意的是不同版本的 Kubernetes 集群下面的 ServiceAccount Token 生成方式并不一樣，但最終都是通過(guò)改 Token 來(lái)進(jìn)行身份認(rèn)證的。

• 1.20（含 1.20）之前的版本，在創(chuàng)建 sa 時(shí)會(huì)自動(dòng)創(chuàng)建一個(gè) secret，然后這個(gè)會(huì)把這個(gè) secret 通過(guò)投射卷掛載到 pod 里，該 secret 里面包含的 token 是永久有效的。
• 1.21~1.23 版本，在創(chuàng)建 sa 時(shí)也會(huì)自動(dòng)創(chuàng)建 secret，但是在 pod 里并不會(huì)使用 secret 里的 token，而是由 kubelet 到 TokenRequest API 去申請(qǐng)一個(gè) token，該 token 默認(rèn)有效期為一年，但是 pod 每一個(gè)小時(shí)會(huì)更新一次 token。
• 1.24 版本及以上，在創(chuàng)建 sa 時(shí)不再自動(dòng)創(chuàng)建 secret 了，只保留由 kubelet 到 TokenRequest API 去申請(qǐng) token。

認(rèn)證

Istio 提供兩種類型的認(rèn)證用于管控網(wǎng)格服務(wù)間的雙向 TLS 和終端用戶的身份認(rèn)證。：

• 對(duì)等認(rèn)證：用于服務(wù)到服務(wù)的認(rèn)證，以驗(yàn)證建立連接的客戶端。Istio 提供雙向 TLS 作為傳輸認(rèn)證的全棧解決方案，無(wú)需更改服務(wù)代碼就可以啟用它。這個(gè)解決方案：

• 為每個(gè)服務(wù)提供代表其角色的強(qiáng)大身份，以實(shí)現(xiàn)跨集群和云的互操作性。
• 確保服務(wù)間通信的安全。
• 提供密鑰管理系統(tǒng)，以自動(dòng)進(jìn)行密鑰和證書的生成、分發(fā)和輪換。

• 請(qǐng)求認(rèn)證：用于終端用戶認(rèn)證，以驗(yàn)證附加到請(qǐng)求的憑據(jù)。Istio 使用 JSON Web Token（JWT）驗(yàn)證啟用請(qǐng)求級(jí)認(rèn)證，并使用自定義認(rèn)證實(shí)現(xiàn)或任何 OpenID Connect 的認(rèn)證實(shí)現(xiàn)來(lái)簡(jiǎn)化的開發(fā)人員體驗(yàn)。

對(duì)等認(rèn)證

下面我們來(lái)創(chuàng)建幾個(gè)示例服務(wù)來(lái)對(duì)認(rèn)證配置進(jìn)行測(cè)試。這里我們將在 foo 和 bar 命名空間下各自創(chuàng)建帶有 Envoy 代理（Sidecar）的 httpbin 和 sleep 服務(wù)。還將在 legacy 命名空間下創(chuàng)建不帶 Envoy 代理（Sidecar）的 httpbin 和 sleep 服務(wù)：

$ kubectl create ns foo
$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
$ kubectl create ns bar
$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n bar
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n bar
$ kubectl create ns legacy
$ kubectl apply -f samples/httpbin/httpbin.yaml -n legacy
$ kubectl apply -f samples/sleep/sleep.yaml -n legacy

現(xiàn)在可以在 foo、bar 或 legacy 三個(gè)命名空間下的任意 sleep Pod 中使用 curl 向 httpbin.foo、httpbin.bar 或 httpbin.legacy 發(fā)送 HTTP 請(qǐng)求來(lái)驗(yàn)證部署結(jié)果，所有請(qǐng)求都應(yīng)該成功并返回 HTTP 200。

例如驗(yàn)證 sleep.bar 到 httpbin.foo 可達(dá)性如下：

$ kubectl exec "$(kubectl get pod -l app=sleep -n bar -o jsnotallow={.items..metadata.name})" -c sleep -n bar -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
200

也可以使用一行指令檢查所有可能的組合：

$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsnotallow={.items..metadata.name})" -c sleep -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
sleep.foo to httpbin.foo: 200
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 200
sleep.legacy to httpbin.bar: 200
sleep.legacy to httpbin.legacy: 200

這樣保證了我們的服務(wù)之間是可以互相訪問(wèn)的，接下來(lái)我們就來(lái)看下如何對(duì)服務(wù)進(jìn)行認(rèn)證。

默認(rèn)情況下，在 Istio 網(wǎng)格內(nèi)部的服務(wù)之間的所有流量都是通過(guò)雙向 TLS 進(jìn)行加密的，不需要做額外的操作，當(dāng)使用雙向 TLS 時(shí)，代理會(huì)將 X-Forwarded-Client-Cert 這個(gè) Header 頭注入到后端的上游請(qǐng)求，這個(gè)頭信息的存在就是啟用雙向 TLS 的證據(jù)。例如：

$ kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsnotallow={.items..metadata.name})" -c sleep -n foo -- curl -s http://httpbin.foo:8000/headers -s
{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.foo:8000",
    "User-Agent": "curl/7.81.0-DEV",
    "X-B3-Parentspanid": "a59be7609a15c41f",
    "X-B3-Sampled": "1",
    "X-B3-Spanid": "034af52cfc2286b4",
    "X-B3-Traceid": "eb07847c5c14c17fa59be7609a15c41f",
    "X-Envoy-Attempt-Count": "1",
    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=bb907e90c93bc3f1dd22763f952746e7d2b8c5ad7903ecbcc64324f3b5e55179;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"
  }
}

可以看到上面我們的請(qǐng)求中包含了 X-Forwarded-Client-Cert 這個(gè) Header 頭，這就是啟用雙向 TLS 的證據(jù)，得到的這個(gè)值是一個(gè) spiffe:// 開頭的字符串，這個(gè)字符串就是 SPIFFE ID，這個(gè) SPIFFE ID 就是用來(lái)表示服務(wù)的身份的，后面我們會(huì)詳細(xì)介紹 SPIFFE。

零信任架構(gòu)下，需要嚴(yán)格區(qū)分工作負(fù)載的識(shí)別和信任，而簽發(fā) X.509 證書是推薦的一種認(rèn)證方式，在 Kubernetes 集群中，服務(wù)間是通過(guò) DNS 名稱互相訪問(wèn)的，而網(wǎng)絡(luò)流量可能被 DNS 欺騙、BGP/路由劫持、ARP 欺騙等手段劫持，為了將服務(wù)名稱（DNS 名稱）與服務(wù)身份強(qiáng)關(guān)聯(lián)起來(lái)，Istio 使用置于 X.509 證書中的安全命名（Secure naming）機(jī)制。

SPIFFE 是 Istio 所采用的安全命名的規(guī)范，它也是云原生定義的一種標(biāo)準(zhǔn)化的、可移植的工作負(fù)載身份規(guī)范。Secure Production Identity Framework For Everyone (SPIFFE) 是一套服務(wù)之間相互進(jìn)行身份識(shí)別的標(biāo)準(zhǔn)，主要包含以下內(nèi)容：

• SPIFFE ID 標(biāo)準(zhǔn)，SPIFFE ID 是服務(wù)的唯一標(biāo)識(shí)，具體實(shí)現(xiàn)使用 URI 資源標(biāo)識(shí)符。
• SPIFFE Verifiable Identity Document (SVID) 標(biāo)準(zhǔn)，將 SPIFFE ID 編碼到一個(gè)加密的可驗(yàn)證的數(shù)據(jù)格式中。
• 頒發(fā)與撤銷 SVID 的 API 標(biāo)準(zhǔn)。

SPIFFE ID 規(guī)定了形如 spiffe://<trust domain>/<workload identifier> 的 URI 格式，作為工作負(fù)載（Workload）的唯一標(biāo)識(shí)。Istio 使用形如 spiffe://<trust_domain>/ns/<namespace>/sa/<service_account> 格式的 SPIFFE ID 作為安全命名，注入到 X.509 證書的 subjectAltName 擴(kuò)展中。其中的 trust domain 參數(shù)通過(guò) Istiod 環(huán)境變量 TRUST_DOMAIN 注入，用于在多集群環(huán)境中交互，比如我們這里就是 cluster.local，所以其實(shí)最終在 Envoy 的配置中可以看到匹配證書的 subjectAltName 值也是這個(gè)格式：

{
  "combined_validation_context": {
    "default_validation_context": {
      "match_subject_alt_names": [
        {
          "exact": "spiffe://cluster.local/ns/istio-system/sa/istiod"
        }
      ]
    },
    "validation_context_sds_secret_config": {
      "name": "ROOTCA",
      "sds_config": {
        "api_config_source": {
          "api_type": "GRPC",
          "grpc_services": [
            {
              "envoy_grpc": {
                "cluster_name": "sds-grpc"
              }
            }
          ],
          "set_node_on_first_message_only": true,
          "transport_api_version": "V3"
        },
        "initial_fetch_timeout": "0s",
        "resource_api_version": "V3"
      }
    }
  }
}

當(dāng)服務(wù)器沒(méi)有 Sidecar 時(shí)，X-Forwarded-Client-Cert 這個(gè) Header 頭將不會(huì)存在，這意味著請(qǐng)求是明文的，比如我們請(qǐng)求 httpbin.legacy 服務(wù)：

kubectl exec "$(kubectl get pod -l app=sleep -n foo -o jsnotallow={.items..metadata.name})" -c sleep -n foo -- curl http://httpbin.legacy:8000/headers -s | grep X-Forwarded-Client-Cert

全局嚴(yán)格 mTLS 模式

事實(shí)上當(dāng) Istio 自動(dòng)將代理和工作負(fù)載之間的所有流量升級(jí)到雙向 TLS 時(shí)，工作負(fù)載仍然可以接收明文流量，如果想要禁用非 mTLS 的通信流量，我們可以使用一個(gè) PeerAuthentication 資源對(duì)象來(lái)進(jìn)行配置，只需要將整個(gè)網(wǎng)格的對(duì)等認(rèn)證策略設(shè)置為 STRICT 模式，作用域?yàn)檎麄€(gè)網(wǎng)格范圍的對(duì)等認(rèn)證策略不設(shè)置 selector 即可，這種認(rèn)證策略必須應(yīng)用于根命名空間（istiod 所在的命名空間），例如：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication # 對(duì)等認(rèn)證策略
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT # STRICT 模式表示只允許 mTLS

對(duì)等認(rèn)證策略指定 Istio 對(duì)目標(biāo)工作負(fù)載實(shí)施的雙向 TLS 模式。支持以下模式：

• PERMISSIVE：工作負(fù)載接受雙向 TLS 和純文本流量，也就是所謂的寬容模式。此模式在遷移因?yàn)闆](méi)有 Sidecar 而無(wú)法使用雙向 TLS 的工作負(fù)載的過(guò)程中非常有用。一旦工作負(fù)載完成 Sidecar 注入的遷移，應(yīng)將模式切換為 STRICT。
• STRICT：工作負(fù)載僅接收雙向 TLS 流量。
• DISABLE：禁用雙向 TLS。從安全角度來(lái)看，除非提供自己的安全解決方案，否則請(qǐng)勿使用此模式。

這個(gè)對(duì)等認(rèn)證策略將工作負(fù)載配置為僅接受 mTLS 加密的請(qǐng)求。由于未對(duì) selector 字段指定值，因此該策略適用于網(wǎng)格中的所有工作負(fù)載。

直接應(yīng)用上面這個(gè)對(duì)等認(rèn)證策略后，我們?cè)俅伟l(fā)送請(qǐng)求來(lái)進(jìn)行測(cè)試：

$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsnotallow={.items..metadata.name})" -c sleep -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
sleep.foo to httpbin.foo: 200
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 000
command terminated with exit code 56
sleep.legacy to httpbin.legacy: 200

我們可以發(fā)現(xiàn)從 sleep.legacy 到 httpbin.foo 和 httpbin.bar 的請(qǐng)求都失敗了，其他依然是成功的，這是因?yàn)槲覀儸F(xiàn)在配置了 STRICT 嚴(yán)格要求使用 mTLS，由于 sleep.legacy 沒(méi)有 Envoy Sidecar，所以無(wú)法滿足這一要求，所以要訪問(wèn)網(wǎng)格內(nèi)部的工作負(fù)載是不被允許的。那為什么可以訪問(wèn) httpbin.legacy 呢？這是因?yàn)槲覀冊(cè)?nbsp;legacy 命名空間下的 httpbin 服務(wù)沒(méi)有 Envoy Sidecar，所以它不會(huì)被 Istio 管理，也就不會(huì)被強(qiáng)制要求使用 mTLS 了，所以我們可以直接訪問(wèn)它。

命名空間級(jí)別策略

上面我們是在根命名空間（istiod 所在的命名空間）下配置的對(duì)等認(rèn)證策略，這樣會(huì)影響到整個(gè)網(wǎng)格，如果我們只想對(duì)某個(gè)命名空間下的服務(wù)進(jìn)行配置，那么我們可以使用命名空間級(jí)別的對(duì)等認(rèn)證策略，該策略的規(guī)范與整個(gè)網(wǎng)格級(jí)別的規(guī)范相同，但是可以在 metadata 字段指定具體的命名空間的名稱。比如我們要在 foo 命名空間上啟用嚴(yán)格的雙向 TLS 對(duì)等策略，可以創(chuàng)建如下所示的資源對(duì)象：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo # 命名空間級(jí)別
spec:
  mtls:
    mode: STRICT

直接應(yīng)用上面的資源對(duì)象，然后再次發(fā)送請(qǐng)求來(lái)進(jìn)行測(cè)試：

# 首先刪除上面創(chuàng)建的全局對(duì)等認(rèn)證策略
$ kubectl delete peerauthentication -n istio-system default
$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsnotallow={.items..metadata.name})" -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
sleep.foo to httpbin.foo: 200
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 200
sleep.legacy to httpbin.legacy: 200

由于這些策略只應(yīng)用于命名空間 foo 中的服務(wù)，正常我們會(huì)看到只有從沒(méi)有 Sidecar 的客戶端（sleep.legacy）到有 Sidecar 的客戶端（httpbin.foo）的請(qǐng)求會(huì)失敗，其余都是成功的。

為每個(gè)工作負(fù)載啟用雙向 TLS

要為特定工作負(fù)載設(shè)置對(duì)等認(rèn)證策略，我們就必須配置 selector 字段指定與所需工作負(fù)載匹配的標(biāo)簽。比如我們只想要為 httpbin.bar 服務(wù)啟用嚴(yán)格模式的 mTLS，則可以創(chuàng)建如下所示的資源對(duì)象：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "httpbin"
  namespace: "bar"
spec:
  selector:
    matchLabels:
      app: httpbin # 匹配 httpbin 應(yīng)用的標(biāo)簽
  mtls:
    mode: STRICT

上面的資源對(duì)象將為 bar 命名空間中的 httpbin 應(yīng)用啟用嚴(yán)格模式的 mTLS，其他工作負(fù)載不受影響。直接應(yīng)用上面的資源對(duì)象，然后再次發(fā)送請(qǐng)求來(lái)進(jìn)行測(cè)試：

$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsnotallow={.items..metadata.name})" -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
sleep.foo to httpbin.foo: 200
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 000
command terminated with exit code 56
sleep.legacy to httpbin.legacy: 200

跟預(yù)期一樣，從 sleep.legacy 到 httpbin.bar 的請(qǐng)求因?yàn)橥瑯拥脑蚴　?/p>

除此之外我們還可以為每個(gè)端口配置不同的對(duì)等認(rèn)證策略，例如，以下對(duì)等認(rèn)證策略要求在除 80 端口以外的所有端口上都使用雙向 TLS：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "httpbin"
  namespace: "bar"
spec:
  selector:
    matchLabels:
      app: httpbin
  mtls:
    mode: STRICT
  portLevelMtls:
    80:
      mode: DISABLE

上面的資源對(duì)象中我們配置了一個(gè) portLevelMtls 字段，該字段用于配置端口級(jí)別的對(duì)等認(rèn)證策略，這里我們配置了 80 端口的對(duì)等認(rèn)證策略為 DISABLE，即禁用雙向 TLS，其他端口的對(duì)等認(rèn)證策略為 STRICT，即啟用雙向 TLS，也就是說(shuō)我們只允許 httpbin 應(yīng)用的 80 端口接收明文流量，其他端口都必須使用雙向 TLS。直接應(yīng)用上面的資源對(duì)象，然后再次發(fā)送請(qǐng)求來(lái)進(jìn)行測(cè)試：

$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=sleep -n ${from} -o jsnotallow={.items..metadata.name})" -c sleep -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "sleep.${from} to httpbin.${to}: %{http_code}\n"; done; done
sleep.foo to httpbin.foo: 200
sleep.foo to httpbin.bar: 200
sleep.foo to httpbin.legacy: 200
sleep.bar to httpbin.foo: 200
sleep.bar to httpbin.bar: 200
sleep.bar to httpbin.legacy: 200
sleep.legacy to httpbin.foo: 000
command terminated with exit code 56
sleep.legacy to httpbin.bar: 200
sleep.legacy to httpbin.legacy: 200

可以看到現(xiàn)在我們從 sleep.legacy 到 httpbin.bar 的請(qǐng)求成功了，因?yàn)槲覀兘昧?nbsp;80 端口的雙向 TLS，所以 sleep.legacy 可以訪問(wèn)到 httpbin.bar 的服務(wù)了。

測(cè)試完成后記得刪除上面創(chuàng)建的對(duì)等認(rèn)證策略：

$ kubectl delete peerauthentication default -n foo
$ kubectl delete peerauthentication httpbin -n bar

請(qǐng)求認(rèn)證

Istio 的請(qǐng)求認(rèn)證用于終端用戶認(rèn)證，以驗(yàn)證附加到請(qǐng)求的憑據(jù)。Istio 使用 JWT 驗(yàn)證啟用請(qǐng)求級(jí)認(rèn)證，并使用自定義認(rèn)證實(shí)現(xiàn)或任何 OpenID Connect 的認(rèn)證實(shí)現(xiàn)來(lái)進(jìn)行認(rèn)證簡(jiǎn)化。

要在 Istio 中進(jìn)行請(qǐng)求認(rèn)證，可以通過(guò)一個(gè) RequestAuthentication 資源對(duì)象來(lái)進(jìn)行配置，如果請(qǐng)求包含無(wú)效的認(rèn)證信息，它將根據(jù)配置的認(rèn)證規(guī)則拒絕該請(qǐng)求。不包含任何認(rèn)證憑證的請(qǐng)求將被接受，但不會(huì)有任何認(rèn)證的身份。

JWK 與 JWKS 概述

Istio 使用 JWT 對(duì)終端用戶進(jìn)行身份驗(yàn)證，Istio 要求提供 JWKS 格式的信息，用于 JWT 簽名驗(yàn)證。因此這里得先介紹一下 JWK 和 JWKS。

JWK 即 JSON Web Key，是 JWT 的秘鑰，它描述了一個(gè)加密密鑰（公鑰或私鑰）的值及其各項(xiàng)屬性。JWKS 描述一組 JWK 密鑰，JWKS 的 JSON 文件格式如下:

{
"keys": [
  <jwk-1>,
  <jwk-2>,
  ...
]}

Istio 使用 JWK 描述驗(yàn)證 JWT 簽名所需要的信息。在使用 RSA 簽名算法時(shí)，JWK 描述的應(yīng)該是用于驗(yàn)證的 RSA 公鑰。一個(gè) RSA 公鑰的 JWK 描述如下：

{
    "alg": "RS256",  # 算法「可選參數(shù)」
    "kty": "RSA",    # 密鑰類型
    "use": "sig",    # 被用于簽名「可選參數(shù)」
    "kid": "DHFxxxxx_-envvQ",  # key 的唯一 id
    "n": "xAExxxxMQ", 公鑰的指數(shù)(exponent)
    "e": "AQAB"  # 公鑰的模數(shù)(modulus)
}

那么需要如何生成 JWK 呢？我們可以使用 https://github.com/lestrrat-go/jwx 這個(gè)命令行工具，這是一個(gè)用 Go 語(yǔ)言開發(fā)的命令行工具，內(nèi)置了對(duì)各種 JWx(JWT, JWK, JWA, JWS, JWE) 的支持。

我們可以使用下面的命令來(lái)安裝 jwx 命令行工具:

$ export GOPROXY="https://goproxy.io"
$ git clone https://github.com/lestrrat-go/jwx.git
$ cd jwx
$ make jwx
go: downloading github.com/lestrrat-go/jwx/v2 v2.0.11
go: downloading github.com/urfave/cli/v2 v2.24.4
# ......
go: downloading github.com/russross/blackfriday/v2 v2.1.0
go: downloading golang.org/x/sys v0.8.0
Installed jwx in /root/go/bin/jwx

下面我們使用 jwx 命令行工具生成一個(gè) JWK，通過(guò)模板指定 kid 為 youdianzhishi-key:

$ jwx jwk generate --keysize 4096 --type RSA  --template '{"kid":"youdianzhishi-key"}' -o rsa.jwk
$ cat rsa.jwk
{
  "d": "AxxxwBw6Jok",
  "dp": "j3xxxuvQ",
  "dq": "zzxxxqQ",
  "e": "AQAB",
  "kid": "youdianzhishi-key",
  "kty": "RSA",
  "n": "5sxxxwV8",
  "p": "-yxxxQ",
  "q": "6zkC_xxxxKw",
  "qi": "LExxxTw"
}

然后從 rsa.jwk 中提取 JWK 公鑰:

$ jwx jwk fmt --public-key -o rsa-public.jwk rsa.jwk
$ cat rsa-public.jwk
{
  "e": "AQAB",
  "kid": "youdianzhishi-key",
  "kty": "RSA",
  "n": "5sxxxV8"
}

上面生成的 JWK 其實(shí)就是 RSA 公鑰私鑰換了一種存儲(chǔ)格式而已，我們可以使用下面的命令將它們轉(zhuǎn)換成 PEM 格式的公鑰和私鑰:

$ jwx jwk fmt -I json -O pem rsa.jwk
-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQCym3O0Ik5QGZ8i
......
-----END PRIVATE KEY-----

$ jwx jwk fmt -I json -O pem rsa-public.jwk
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAsptztCJOUBmfIqSE8LR5
......
-----END PUBLIC KEY-----

接下來(lái)我們就可以使用 jwx 命令行簽發(fā) JWT Token 并驗(yàn)證其有效性了：

jwx jws sign --key rsa.jwk --alg RS256 --header '{"typ":"JWT"}' -o token.txt - <<EOF
{
  "iss": "testing@secure.istio.io",
  "sub": "cnych001",
  "iat": 1700648397,
  "exp": 1700656042,
  "name": "Yang Ming"
}
EOF

然后查看生成的 Token 文件內(nèi)容：

$ cat token.txt
eyJhbGciOiJSUzI1NiIsImtpZCI6InlvdWRpYW56aGlzaGkta2V5In0......

上面生成 JWT Token 實(shí)際上是由下面的算法生成的:

base64url_encode(Header) + '.' + base64url_encode(Claims) + '.' + base64url_encode(Signature)

我們可以將該 Token 粘貼到 jwt.io 網(wǎng)站上來(lái)解析：

jwt

先看一下 Headers 部分，包含了一些元數(shù)據(jù):

• alg: 所使用的簽名算法，這里是 RSA256
• kid: JWK 的 kid

然后是 Payload(Claims) 部分，payload 包含了這個(gè) token 的數(shù)據(jù)信息，JWT 標(biāo)準(zhǔn)規(guī)定了一些字段，另外還可以加入一些承載額外信息的字段。

• iss: issuer，token 是誰(shuí)簽發(fā)的
• sub: token 的主體信息，一般設(shè)置為 token 代表用戶身份的唯一 id 或唯一用戶名
• exp: token 過(guò)期時(shí)間，Unix 時(shí)間戳格式
• iat: token 創(chuàng)建時(shí)間， Unix 時(shí)間戳格式

最后看一下簽名 Signature 信息，簽名是基于 JSON Web Signature (JWS) 標(biāo)準(zhǔn)來(lái)生成的，簽名主要用于驗(yàn)證 token 是否有效，是否被篡改。簽名支持很多種算法，這里使用的是 RSASHA256，具體的簽名算法如下:

RSASHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  <rsa-public-key>,
  <rsa-private-key>

最后可以使用 RSA Public Key 驗(yàn)證 JWT Token 的有效性:

$ jwx jws verify --alg RS256 --key rsa-public.jwk token.txt
{
  "iss": "testing@secure.istio.io",
  "sub": "cnych001",
  "iat": 1700648397,
  "exp": 1700656042,
  "name": "Yang Ming"
}

配置 JWT 終端用戶認(rèn)證

上面我們了解了 JWT、JWK、JWKS 這些概念，接下來(lái)我們來(lái)配置 Istio 的認(rèn)證策略使用我們自己創(chuàng)建的 JWKS。

為了方便訪問(wèn)，我們這里通過(guò) Ingress 網(wǎng)關(guān)來(lái)暴露 httpbin.foo 服務(wù)，為其創(chuàng)建一個(gè) Gateway 對(duì)象：

kubectl apply -f samples/httpbin/httpbin-gateway.yaml -n foo

可以通過(guò)如下命令獲取 HTTP 的訪問(wèn)端口：

export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsnotallow='{.spec.ports[?(@.name=="http2")].nodePort}')

然后獲取集群中任意一個(gè)節(jié)點(diǎn)的 IP 地址：

export INGRESS_HOST=$(kubectl get po -l istio=ingressgateway -n istio-system -o jsnotallow='{.items[0].status.hostIP}')

然后可以通過(guò)下面的命令來(lái)測(cè)試 httpbin.foo 服務(wù)是否可以正常訪問(wèn)：

curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"

如果上面命令返回 200，則表示 httpbin.foo 服務(wù)可以正常訪問(wèn)。

接下來(lái)我們就可以添加一個(gè)請(qǐng)求認(rèn)證策略對(duì)象，該策略要求 Ingress 網(wǎng)關(guān)指定終端用戶的 JWT。

apiVersion: "security.istio.io/v1"
kind: RequestAuthentication
metadata:
  name: jwt-example
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
    - issuer: "testing@secure.istio.io" # 簽發(fā)者，需要和 JWT payload 中的 iss 屬性完全一致。
      # forwardOriginalToken: true
      jwks: |
        {
            "keys": [
              {
                "e": "AQAB",
                "kid": "youdianzhishi-key",
                "kty": "RSA",
                "n": "5sbkUCkQDuM3hiw9UTxmxO2wUYOT69IZje7M6O_R-ApJ3KkrhQS1C2SJelBTLgbaWhAsO4jBYOmFfWGLBA-XxrhoB9KxWCGA4EXf6fukp0ljGTYE6Th6r393jIJGDFUt8vQCjj5ivmBAQHLjwmnWiG6I93mrTQhoNHQWAde21O7yYNpg6fvjVJgRFqeAtpieA-5f2sQ8fBkefM0RFgQTqWPGfLHse5nqRWY4hG_gb23GzCo_Ti2h9wJZNuTfdK8hitahOq3eLlDVVvCu8hx-8BEs5APCj54gtqePswHeRXZi_03ccNii5CnW7Y1rHiL8LHKNHhY5tD2iZByh4YrnhkUWD-CXNqyUKx90de0R9H1ON6pqsmdEx4iAMx2xvnZ0S9NbKlk3glw_AvudjJUHa41xx7qy9OZ7QV6cB_ntwLtw513lk5Tfm-RDlVgyU-EO2jKXbOeiDpnb8kgRNBMKDqY9mgLfISW54N-LBjyVwVVHOvICWo0oPJypRgPRWD8f25wHqzjlsB8nIqJkj_e9p2c5WnAGiZWuZjm6t94IfFq9lWYUsSn-JtJvh3ATsv7ptDKFz2Ko82r1uD3446mr4I0J56C-7WOHGchlSOrDWKErwkIGxyrQ_3GEkUhkSxfArAv0bajmcMCu1_j8Eekqk7Fnm5QqytCFmFevzIJkwV8"
              }
            ]
        }

在上面的資源對(duì)象中我們通過(guò) selector 匹配了 istio-ingressgateway 服務(wù)，因?yàn)槲覀円獮?Ingress 網(wǎng)關(guān)添加請(qǐng)求認(rèn)證，具體的請(qǐng)求認(rèn)證規(guī)則通過(guò) jwtRules 來(lái)進(jìn)行配置，這里我們配置了一個(gè) issuer 字段，該字段用于指定 JWT 的 Issuer 發(fā)行人，然后配置了一個(gè) jwks 字段，該字段用于指定 JWT 的公鑰集數(shù)據(jù)，我們也可以通過(guò) jwksUri 來(lái)指向一個(gè)公鑰集地址。對(duì)同一個(gè) issuers（jwt 簽發(fā)者），可以設(shè)置多個(gè)公鑰，以實(shí)現(xiàn) JWT 簽名密鑰的輪轉(zhuǎn)。JWT 的驗(yàn)證規(guī)則是：

• JWT 的 payload 中有 issuer 屬性，首先通過(guò) issuer 匹配到對(duì)應(yīng)的 istio 中配置的 jwks。
• JWT 的 header 中有 kid 屬性，第二步在 jwks 的公鑰列表中，中找到 kid 相同的公鑰。
• 使用找到的公鑰進(jìn)行 JWT 簽名驗(yàn)證。

配置中的 spec.selector 可以省略，這樣會(huì)直接在整個(gè)命名空間中生效，比如在 istio-system 命名空間，該配置將在全集群的所有 sidecar/ingressgateway 上生效！

默認(rèn)情況下，Istio 在完成了身份驗(yàn)證之后，會(huì)去掉 Authorization 請(qǐng)求頭再進(jìn)行轉(zhuǎn)發(fā)。這將導(dǎo)致我們的后端服務(wù)獲取不到對(duì)應(yīng)的 Payload，無(wú)法判斷終端用戶的身份。因此我們需要啟用 Istio 的 Authorization 請(qǐng)求頭的轉(zhuǎn)發(fā)功能，只需要在上面的資源對(duì)象中添加一個(gè) forwardOriginalToken: true 字段即可。

直接應(yīng)用上面的資源對(duì)象，然后再次發(fā)送請(qǐng)求來(lái)進(jìn)行測(cè)試：

$ curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200

可以看到現(xiàn)在依然可以正常訪問(wèn)，但是如果我們請(qǐng)求的時(shí)候帶上一個(gè)無(wú)效的 JWT Token，則會(huì)返回 401 錯(cuò)誤：

$ curl --header "Authorization: Bearer abcdef" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
401

要想正常訪問(wèn)，我們需要使用上面生成的 JWT Token 來(lái)進(jìn)行訪問(wèn)：

$ TOKEN=$(cat token.txt)
$ curl --header "Authorization: Bearer $TOKEN" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200

可以看到就可以正常訪問(wèn)了。

設(shè)置強(qiáng)制認(rèn)證規(guī)則

從上面的測(cè)試可以看出 Istio 的 JWT 驗(yàn)證規(guī)則，默認(rèn)情況下會(huì)直接忽略不帶 Authorization 請(qǐng)求頭（即 JWT）的流量，因此這類流量能直接進(jìn)入網(wǎng)格內(nèi)部。通常這是沒(méi)問(wèn)題的，因?yàn)闆](méi)有 Authorization 的流量即使進(jìn)入到內(nèi)部，也會(huì)因?yàn)闊o(wú)法通過(guò) payload 判別身份而被拒絕操作。但是如果我們需要禁止不帶 JWT 的流量，那么可以通過(guò)一個(gè) AuthorizationPolicy 對(duì)象來(lái)進(jìn)行配置了。

比如拒絕任何 JWT 無(wú)效的請(qǐng)求，則可以創(chuàng)建如下 d 資源對(duì)象：

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-requests-without-authorization
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY # 拒絕
  rules:
    - from:
        - source:
            notRequestPrincipals: ["*"] # 不存在任何請(qǐng)求身份（Principal）的 requests

上面的資源對(duì)象中我們配置的 action: DENY 表示拒絕，然后通過(guò) rules 字段來(lái)配置拒絕的規(guī)則，這里我們配置了一個(gè) from 字段，該字段用于指定請(qǐng)求的來(lái)源，這里我們配置了一個(gè) notRequestPrincipals 字段，該字段用于指定請(qǐng)求的身份，這里我們配置為 *，表示任何請(qǐng)求身份都不允許。

應(yīng)用上面的資源對(duì)象后，重新發(fā)送沒(méi)有令牌的請(qǐng)求，請(qǐng)求失敗并返回錯(cuò)誤碼 403：

$ curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
403

如果僅希望強(qiáng)制要求對(duì)部分 path 的請(qǐng)求必須帶有 Authorization Header，可以這樣設(shè)置：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-requests-without-authorization
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY # 拒絕
  rules:
    - from:
        - source:
            notRequestPrincipals: ["*"] # 不存在任何請(qǐng)求身份的 requests
      # 僅強(qiáng)制要求如下 host/path 相關(guān)的請(qǐng)求，必須帶上 JWT token
      to:
        - operation:
            hosts: ["another-host.com"]
            paths: ["/headers"]

需要注意的是 RequestsAuthentication 和 AuthorizationPolicy 這兩個(gè)對(duì)象返回的錯(cuò)誤碼是不同的：

• RequestsAuthentication 驗(yàn)證失敗的請(qǐng)求，Istio 會(huì)返回 401 狀態(tài)碼。
• AuthorizationPolicy 驗(yàn)證失敗的請(qǐng)求，Istio 會(huì)返回 403 狀態(tài)碼。

到這里我們就實(shí)現(xiàn)了對(duì) JWT 的驗(yàn)證，當(dāng)然除了驗(yàn)證之外，我們還需要授權(quán)，這個(gè)我們?cè)谙旅娴恼鹿?jié)中來(lái)實(shí)現(xiàn)。

參考文檔

• https://www.zhaohuabing.com/post/2020-05-25-istio-certificate/。
• https://istio.io/latest/docs/concepts/security/。
• https://github.com/YaoZengzeng/KubernetesResearch/blob/master/Istio%E5%AE%89%E5%85%A8%E6%A1%86%E6%9E%B6%E8%A7%A3%E6%9E%90.md。