6月iOS設備性能榜：M2穩居榜首 A系列只能等一手3nm來救
沒有新品發布，自然iOS設備性能榜的上榜設備就沒有什么更替，僅僅只有跑分變化而產生的排名變動，畢竟蘋果新品的發布節奏就是這樣的，一年下來也就幾個移動端新品，不會像安卓廠商，一
簽名我們了解了位于服務網格內部的應用應如何訪問網格外部的 HTTP 和 HTTPS 服務，我們學習了如何通過 ServiceEntry 對象配置 Istio 以受控的方式訪問外部服務，這種方式實際上是通過 Sidecar 直接調用的外部服務，但是有時候我們可能需要通過專用的 Egress Gateway 服務來調用外部服務，這種方式可以更好的控制對外部服務的訪問。
Istio 使用 Ingress 和 Egress Gateway 配置運行在服務網格邊緣的負載均衡，Ingress Gateway 允許定義網格所有入站流量的入口。 Egress Gateway 是一個與 Ingress Gateway 對稱的概念，它定義了網格的出口。Egress Gateway 允許我們將 Istio 的功能（例如，監視和路由規則）應用于網格的出站流量。
比如有一個對安全要求非常嚴格的團隊，要求服務網格所有的出站流量必須經過一組專用節點。專用節點運行在專門的機器上，與集群中運行應用程序的其他節點隔離，這些專用節點用于實施 Egress 流量的策略，并且受到比其余節點更嚴密地監控。
另一個使用場景是集群中的應用節點沒有公有 IP，所以在該節點上運行的網格服務都無法訪問互聯網，那么我們就可以通過定義 Egress gateway，將公有 IP 分配給 Egress Gateway 節點，用它引導所有的出站流量，可以使應用節點以受控的方式訪問外部服務。
接下來我們就來學習下在 Istio 中如何配置使用 Egress Gateway。
如果你使用的 demo 這個配置文件安裝 Istio，那么 Egress Gateway 已經默認安裝了，可以通過下面的命令來查看：
$ kubectl get pod -l istio=egressgateway -n istio-systemNAME READY STATUS RESTARTS AGEistio-egressgateway-556f6f58f4-hkzdd 1/1 Running 0 14d如果沒有 Pod 返回，可以通過下面的步驟來部署 Istio Egress Gateway。如果你使用 IstioOperator 安裝 Istio，請在配置中添加以下字段：
spec: components: egressGateways: - name: istio-egressgateway enabled: true否則使用如下的 istioctl install 命令來安裝：
$ istioctl install <flags-you-used-to-install-Istio> / --set components.egressGateways[0].name=istio-egressgateway / --set components.egressGateways[0].enabled=true同樣我們還是使用 sleep 示例做為發送請求的測試源，如果啟用了自動 Sidecar 注入，運行以下命令部署示例應用程序：
kubectl apply -f samples/sleep/sleep.yaml否則，在使用以下命令部署 sleep 應用程序之前，手動注入 Sidecar：
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)為了發送請求，您需要創建 SOURCE_POD 環境變量來存儲源 Pod 的名稱：
export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})首先創建一個 ServiceEntry 對象來允許流量直接訪問外部的 edition.cnn.com 服務。
apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata: name: cnnspec: hosts: - edition.cnn.com ports: - number: 80 name: http-port protocol: HTTP - number: 443 name: https protocol: HTTPS resolution: DNS發送 HTTPS 請求到 https://edition.cnn.com/politics 驗證 ServiceEntry 是否已正確應用。
$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics# 輸出如下內HTTP/1.1 301 Moved Permanently# ......location: https://edition.cnn.com/politics# ......HTTP/2 200Content-Type: text/html; charset=utf-8# ......然后為 edition.cnn.com 的 80 端口創建一個 egress Gateway，并為指向 Egress Gateway 的流量創建一個 DestinationRule 規則，如下所示：
apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata: name: istio-egressgatewayspec: selector: istio: egressgateway # 匹配 Egress Gateway Pod 的標簽 servers: - port: number: 80 name: http protocol: HTTP hosts: - edition.cnn.com # 也支持通配符 * 的形式---apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: egressgateway-for-cnnspec: host: istio-egressgateway.istio-system.svc.cluster.local # 目標規則為 Egress Gateway subsets: - name: cnn # 定義一個子集 cnn，沒有指定 labels，則 subset 會包含所有符合 host 字段指定的服務的 Pod在上面的對象中我們首先定義了一個 Gateway 對象，不過這里我們定義的是一個 Egress Gateway，通過 istio: egressgateway 匹配 Egress Gateway Pod 的標簽，并在 servers 中定義了 edition.cnn.com 服務的 80 端口。然后定義了一個 DestinationRule 對象，指定了目標規則為 istio-egressgateway.istio-system.svc.cluster.local，并定義了一個子集 cnn。
這里的子集名稱是 cnn，但沒有指定 labels。這意味著，這個 subset 會涵蓋所有屬于 istio-egressgateway.istio-system.svc.cluster.local 服務的 Pod。這種情況下，subset 的作用主要是為了在其他 Istio 配置中提供一個方便的引用名稱，而不是為了區分不同的 Pod 子集。
如何再定義一個 VirtualService 對象將流量從 Sidecar 引導至 Egress Gateway，再從 Egress Gateway 引導至外部服務，如下所示：
apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: direct-cnn-through-egress-gatewayspec: hosts: - edition.cnn.com gateways: - istio-egressgateway # Egress Gateway - mesh # 網格內部的流量 http: - match: - gateways: - mesh # 這條規則適用于從服務網格內發出的流量 port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local # 流量將被路由到 egress gateway subset: cnn port: number: 80 weight: 100 - match: - gateways: - istio-egressgateway # 這條規則適用于通過 istio-egressgateway 的流量 port: 80 route: - destination: host: edition.cnn.com # 流量將被路由到外部服務 port: number: 80 weight: 100在上面的 VirtualService 對象中通過 hosts 指定 edition.cnn.com，表示該虛擬服務用于該服務的請求，gateways 字段中定義了 istio-egressgateway 和 mesh 兩個值，istio-egressgateway 是上面我們定義的 Egress Gateway，mesh 表示該虛擬服務用于網格內部的流量，也就是說這個虛擬服務指定了如何處理來自服務網格內部以及通過 istio-egressgateway 的流量。
mesh 是一個特殊的關鍵字，在 Istio 中表示服務網格內的所有 Sidecar 代理。當使用 mesh 作為網關時，這意味著 VirtualService 中定義的路由規則適用于服務網格內的所有服務，即所有裝有 Istio sidecar 代理的服務。
http 字段中定義了兩個 match，第一個 match 用于匹配 mesh 網關，第二個 match 用于匹配 istio-egressgateway 網關，然后在 route 中定義了兩個 destination，第一個 destination 用于將流量引導至 Egress Gateway 的 cnn 子集，第二個 destination 用于將流量引導至外部服務。
總結來說，這個 VirtualService 的作用是控制服務網格內部到 edition.cnn.com 的流量。當流量起始于服務網格內時，它首先被路由到 istio-egressgateway，然后再路由到 edition.cnn.com，這種配置有助于統一和控制從服務網格內部到外部服務的流量，可以用于流量監控、安全控制或實施特定的流量策略。
應用上面的資源對象后，我們再次向 edition.cnn.com 的 /politics 端點發出 curl 請求：
$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics# ......HTTP/1.1 301 Moved Permanentlylocation: https://edition.cnn.com/politics# ......HTTP/2 200Content-Type: text/html; charset=utf-8# ......正常和前面的一次測試輸出結果是一致的，但是這次在請求是經過 istio-egressgateway Pod 發出的，我們可以查看日志來驗證：
kubectl logs -l istio=egressgateway -c istio-proxy -n istio-system | tail正常會看到一行類似于下面這樣的內容：
[2023-11-15T08:48:38.683Z] "GET /politics HTTP/2" 301 - via_upstream - "-" 0 0 204 203 "10.244.1.73" "curl/7.81.0-DEV" "6c2c4550-92d4-955c-b6cb-83bf2b0e06f4" "edition.cnn.com" "151.101.3.5:80" outbound|80||edition.cnn.com 10.244.2.184:46620 10.244.2.184:8080 10.244.1.73:49924 - -因為我們這里只是將 80 端口的流量重定向到 Egress Gateway 了，所以重定向后 443 端口的 HTTPS 流量將直接進入 edition.cnn.com，所以沒有看到 443 端口的日志，但是我們可以通過 SOURCE_POD 的 Sidecar 代理的日志來查看到：
$ kubectl logs "$SOURCE_POD" -c istio-proxy | tail# ......[2023-11-15T08:55:55.513Z] "GET /politics HTTP/1.1" 301 - via_upstream - "-" 0 0 191 191 "-" "curl/7.81.0-DEV" "12ce15aa-1247-9b7e-8185-4224f96f5ea0" "edition.cnn.com" "10.244.2.184:8080" outbound|80|cnn|istio-egressgateway.istio-system.svc.cluster.local 10.244.1.73:49926 151.101.195.5:80 10.244.1.73:41576 - -[2023-11-15T08:55:55.753Z] "- - -" 0 - - - "-" 839 2487786 1750 - "-" "-" "-" "-" "151.101.195.5:443" outbound|443||edition.cnn.com 10.244.1.73:45246 151.101.67.5:443 10.244.1.73:42998 edition.cnn.com -上面我們已經學習了如何通過 Egress Gateway 發起 HTTP 請求，接下來我們再來學習下如何通過 Egress Gateway 發起 HTTPS 請求。
原理都是一樣的，只是我們需要在相應的 ServiceEntry、Egress Gateway 和 VirtualService 中指定 TLS 協議的端口 443。
首先為 edition.cnn.com 定義 ServiceEntry 服務：
apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata: name: cnnspec: hosts: - edition.cnn.com ports: - number: 443 name: tls protocol: TLS resolution: DNS應用該資源對象后，發送 HTTPS 請求到 https://edition.cnn.com/politics，驗證該 ServiceEntry 是否已正確生效。
$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics...HTTP/2 200Content-Type: text/html; charset=utf-8...接下來同樣的方式為 edition.cnn.com 創建一個 Egress Gateway。除此之外還需要創建一個目標規則和一個虛擬服務，用來引導流量通過 Egress Gateway，并通過 Egress Gateway 與外部服務通信。
apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata: name: istio-egressgatewayspec: selector: istio: egressgateway servers: - port: number: 443 name: tls protocol: TLS hosts: - edition.cnn.com tls: mode: PASSTHROUGH # 透傳---apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: egressgateway-for-cnnspec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: cnn---apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: direct-cnn-through-egress-gatewayspec: hosts: - edition.cnn.com gateways: - mesh - istio-egressgateway tls: - match: - gateways: - mesh port: 443 sniHosts: - edition.cnn.com route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: cnn port: number: 443 - match: - gateways: - istio-egressgateway port: 443 sniHosts: - edition.cnn.com route: - destination: host: edition.cnn.com port: number: 443 weight: 100上面對象中定義的 Gateway 對象和前面的一樣，只是將端口改為了 443，然后在 tls 中指定了 mode: PASSTHROUGH，表示該 Gateway 對象用于 TLS 協議的請求。然后在后面的 VirtualService 對象中就是配置 spec.tls 屬性，用于指定 TLS 協議的請求的路由規則，配置方法和前面 HTTP 方式類似，只是注意要將端口改為 443，并且在 match 中指定 sniHosts 為 edition.cnn.com，表示該虛擬服務用于處理 edition.cnn.com 的 TLS 請求。
應用上面的資源對象后，我們現在發送 HTTPS 請求到 https://edition.cnn.com/politics，輸出結果應該和之前一樣。
$ kubectl exec "$SOURCE_POD" -c sleep -- curl -sSL -o /dev/null -D - https://edition.cnn.com/politics...HTTP/2 200Content-Type: text/html; charset=utf-8...檢查 Egress Gateway 代理的日志，則打印日志的命令是：
kubectl logs -l istio=egressgateway -n istio-system應該會看到類似于下面的內容：
[2023-11-15T08:59:55.513Z] "- - -" 0 - 627 1879689 44 - "-" "-" "-" "-" "151.101.129.67:443" outbound|443||edition.cnn.com 172.30.109.80:41122 172.30.109.80:443 172.30.109.112:59970 edition.cnn.com到這里我們就實現了通過 Egress Gateway 發起 HTTPS 請求。最后記得清理上面創建的資源對象：
$ kubectl delete serviceentry cnn$ kubectl delete gateway istio-egressgateway$ kubectl delete virtualservice direct-cnn-through-egress-gateway$ kubectl delete destinationrule egressgateway-for-cnn需要注意的是，Istio 無法強制讓所有出站流量都經過 Egress Gateway， Istio 只是通過 Sidecar 代理實現了這種流向。攻擊者只要繞過 Sidecar 代理， 就可以不經 Egress Gateway 直接與網格外的服務進行通信，從而避開了 Istio 的控制和監控。出于安全考慮，集群管理員和云供應商必須確保網格所有的出站流量都要經過 Egress Gateway。這需要通過 Istio 之外的機制來滿足這一要求。例如，集群管理員可以配置防火墻，拒絕 Egress Gateway 以外的所有流量。Kubernetes NetworkPolicy 也能禁止所有不是從 Egress Gateway 發起的出站流量，但是這個需要 CNI 插件的支持。 此外，集群管理員和云供應商還可以對網絡進行限制，讓運行應用的節點只能通過 gateway 來訪問外部網絡。要實現這一限制，可以只給 Gateway Pod 分配公網 IP，并且可以配置 NAT 設備， 丟棄來自 Egress Gateway Pod 之外的所有流量。
接下來我們將學習如何通過配置 Istio 去實現對發往外部服務的流量的 TLS Origination（TLS 發起）。 若此時原始的流量為 HTTP，則 Istio 會將其轉換為 HTTPS 連接。TLS Origination 的概念前面我們也已經介紹過了。
TLS Origination
假設有一個傳統應用正在使用 HTTP 和外部服務進行通信，如果有一天突然有一個新的需求，要求必須對所有外部的流量進行加密。此時，使用 Istio 便可通過修改配置實現此需求，而無需更改應用中的任何代碼。該應用可以發送未加密的 HTTP 請求，由 Istio 為請求進行加密。
從應用源頭發起未加密的 HTTP 請求，并讓 Istio 執行 TLS 升級的另一個好處是可以產生更好的遙測并為未加密的請求提供更多的路由控制。
下面我們就來學習下如何配置 Istio 實現 TLS Origination。
同樣我們這里使用 sleep 示例應用來作為測試源，如果啟用了自動注入 Sidecar，那么可以直接部署 sleep 應用：
kubectl apply -f samples/sleep/sleep.yaml否則在部署 sleep 應用之前，必須手動注入 Sidecar：
kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)創建一個環境變量來保存用于將請求發送到外部服務 Pod 的名稱：
export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsnotallow={.items..metadata.name})首先使用 ServiceEntry 對象來配置對外部服務 edition.cnn.com 的訪問。這里我們將使用單個 ServiceEntry 來啟用對服務的 HTTP 和 HTTPS 訪問。創建一個如下所示的 ServiceEntry 對象：
apiVersion: networking.istio.io/v1alpha3kind: ServiceEntrymetadata: name: edition-cnn-comspec: hosts: - edition.cnn.com ports: - number: 80 name: http-port protocol: HTTP - number: 443 name: https-port protocol: HTTPS resolution: DNS上面的 ServiceEntry 對象中我們指定了 edition.cnn.com 服務的主機名，然后在 ports 中指定了需要暴露的端口及其屬性，表示該 ServiceEntry 對象代表對 edition.cnn.com 的訪問，這里我們定義了 80 和 443 兩個端口，分別對應 http 和 https 服務，resolution: DNS 定義了如何解析指定的 hosts，這里我們使用 DNS 來解析。
直接應用該資源對象，然后向外部的 HTTP 服務發送請求：
$ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics# 輸出如下結果HTTP/1.1 301 Moved Permanently# ......location: https://edition.cnn.com/politicsHTTP/2 200content-type: text/html; charset=utf-8# ......上面我們在使用 curl 命令的時候添加了一個 -L 標志，該標志指示 curl 將遵循重定向。 在這種情況下，服務器將對到 http://edition.cnn.com/politics 的 HTTP 請求進行重定向響應，而重定向響應將指示客戶端使用 HTTPS 向 https://edition.cnn.com/politics 重新發送請求，對于第二個請求，服務器則返回了請求的內容和 200 狀態碼。
盡管 curl 命令簡明地處理了重定向，但是這里有兩個問題。第一個問題是請求冗余，它使獲取 http://edition.cnn.com/politics 內容的延遲加倍，第二個問題是 URL 中的路徑（在本例中為 politics）被以明文的形式發送。如果有人嗅探你的應用與 edition.cnn.com 之間的通信，他將會知曉該應用獲取了此網站中哪些特定的內容。出于隱私的原因，我們可能希望阻止這些內容被嗅探到。通過配置 Istio 執行 TLS 發起，則可以解決這兩個問題。
為 edition.cnn.com 創建一個出口網關，端口為 80，接收 HTTP 流量，如下所示：
apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata: name: istio-egressgatewayspec: selector: istio: egressgateway servers: - port: number: 80 name: tls-origination-port protocol: HTTP hosts: - edition.cnn.com然后為 istio-egressgateway 創建一個 DestinationRule 對象，如下所示：
apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: egressgateway-for-cnnspec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: cnn接著我們只需要創建一個 VirtualService 對象，將流量從 Sidecar 引導至 Egress Gateway，再從 Egress Gateway 引導至外部服務，如下所示：
apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: direct-cnn-through-egress-gatewayspec: hosts: - edition.cnn.com gateways: - istio-egressgateway # Egress Gateway - mesh # 網格內部的流量 http: - match: - gateways: - mesh port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: cnn port: number: 80 weight: 100 - match: - gateways: - istio-egressgateway port: 80 route: - destination: host: edition.cnn.com port: number: 443 # 443 端口 weight: 100---apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: originate-tls-for-edition-cnn-comspec: host: edition.cnn.com trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 443 tls: mode: SIMPLE # initiates HTTPS for connections to edition.cnn.com需要注意的是上面最后針對 edition.cnn.com 的 DestinationRule 對象，在 trafficPolicy 中指定了 portLevelSettings 用于對不同的端口定義不同的流量策略，這里我們定義了 443 端口的 tls 模式為 SIMPLE，表示當訪問 edition.cnn.com 的 HTTP 請求時執行 TLS 發起。
應用上面的資源對象，然后再次向 http://edition.cnn.com/politics 發送 HTTP 請求：
$ kubectl exec "${SOURCE_POD}" -c sleep -- curl -sSL -o /dev/null -D - http://edition.cnn.com/politics# 直接輸出200狀態碼HTTP/1.1 200 OKcontent-length: 2474958content-type: text/html; charset=utf-8# ......這次將會收到唯一的 200 OK 響應，因為 Istio 為 curl 執行了 TLS 發起，原始的 HTTP 被升級為 HTTPS 并轉發到 edition.cnn.com。服務器直接返回內容而無需重定向，這消除了客戶端與服務器之間的請求冗余，使網格保持加密狀態，隱藏了你的應用獲取 edition.cnn.com 中 politics 端點的信息。
如果我們在代碼中有去訪問外部服務，那么我們就可以不用修改代碼了，只需要通過配置 Istio 來獲得 TLS 發起即可，而無需更改一行代碼。
到這里我們就學習了如何通過配置 Istio 實現對外部服務的 TLS 發起。
前面我們學習了如何通過配置 Istio 實現對外部服務的 TLS 發起，這里其實還有一個 mTLS 的概念呢，由于 TLS 本身就比較復雜，對于雙向 TLS（mTLS）就更復雜了。
TLS 是一個連接層協議，旨在為 TCP 連接提供安全保障。TLS 在連接層工作，可以與任何使用 TCP 的應用層協議結合使用。例如，HTTPS 是 HTTP 與 TLS 的結合（HTTPS 中的 S 指的是 SSL，即 TLS 的前身），TLS 認證的流程大致如下所示：
認證過程
當然 HTTPS 的工作流程和這個過程基本就一致了：
HTTPS 工作流程
當然雙向 TLS 就更為復雜了，Mutual TLS（雙向 TLS），或稱 mTLS，對于常規的 TLS，只需要服務端認證，mTLS 相對來說有一個額外的規定：客戶端也要經過認證。在 mTLS 中，客戶端和服務器都有一個證書，并且雙方都使用它們的公鑰/私鑰對進行身份驗證。
TLS 保證了真實性，但默認情況下，這只發生在一個方向上：客戶端對服務器進行認證，但服務器并不對客戶端進行認證。為什么 TLS 的默認只在一個方向進行認證？因為客戶端的身份往往是不相關的。例如我們在訪問優點知識的時候，你的瀏覽器已經驗證了要訪問的網站服務端的身份，但服務端并沒有驗證你的瀏覽器的身份，它實際上并不關心你的瀏覽器的身份，這對于互聯網上的 Web 項目來說足夠了。但是在某些情況下，服務器確實需要驗證客戶端的身份，例如，當客戶端需要訪問某些敏感數據時，服務器可能需要驗證客戶端的身份，以確保客戶端有權訪問這些數據，這就是 mTLS 的用武之地，mTLS 是保證微服務之間跨服務通信安全的好方法。
接下來我們就來測試下如何通過 egress 網關發起雙向 TLS 連接。
首先使用 openssl 命令生成客戶端和服務器的證書與密鑰，為你的服務簽名證書創建根證書和私鑰：
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt# 生成 CA 證書和私鑰為 my-nginx.mesh-external.svc.cluster.local 創建證書和私鑰：
# 為 my-nginx.mesh-external.svc.cluster.local 創建私鑰和證書簽名請求$ openssl req -out my-nginx.mesh-external.svc.cluster.local.csr -newkey rsa:2048 -nodes -keyout my-nginx.mesh-external.svc.cluster.local.key -subj "/CN=my-nginx.mesh-external.svc.cluster.local/O=some organization"# 使用 CA 公鑰和私鑰以及證書簽名請求為 my-nginx.mesh-external.svc.cluster.local 創建證書$ openssl x509 -req -sha256 -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in my-nginx.mesh-external.svc.cluster.local.csr -out my-nginx.mesh-external.svc.cluster.local.crt然后生成客戶端證書和私鑰：
# 為 client.example.com 創建私鑰和證書簽名請求$ openssl req -out client.example.com.csr -newkey rsa:2048 -nodes -keyout client.example.com.key -subj "/CN=client.example.com/O=client organization"# 使用相同的 CA 公鑰和私鑰以及證書簽名請求為 client.example.com 創建證書$ openssl x509 -req -sha256 -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 1 -in client.example.com.csr -out client.example.com.crt接著我們來部署一個雙向 TLS 服務器，為了模擬一個真實的支持雙向 TLS 協議的外部服務，我們在 Kubernetes 集群中部署一個 NGINX 服務，該服務運行在 Istio 服務網格之外，比如運行在一個沒有開啟 Istio Sidecar proxy 注入的命名空間中。
創建一個命名空間 mesh-external 表示 Istio 網格之外的服務，注意在這個命名空間中，Sidecar 自動注入是沒有開啟的，不會在 Pod 中自動注入 Sidecar proxy。
kubectl create namespace mesh-external然后創建 Kubernetes Secret，保存服務器和 CA 的證書。
$ kubectl create -n mesh-external secret tls nginx-server-certs --key my-nginx.mesh-external.svc.cluster.local.key --cert my-nginx.mesh-external.svc.cluster.local.crt$ kubectl create -n mesh-external secret generic nginx-ca-certs --from-file=example.com.crt生成 NGINX 服務器的配置文件：
$ cat <</EOF > ./nginx.confevents {}http { log_format main '$remote_addr - $remote_user [$time_local] $status ' '"$request" $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log; server { listen 443 ssl; root /usr/share/nginx/html; index index.html; server_name my-nginx.mesh-external.svc.cluster.local; ssl_certificate /etc/nginx-server-certs/tls.crt; ssl_certificate_key /etc/nginx-server-certs/tls.key; ssl_client_certificate /etc/nginx-ca-certs/example.com.crt; ssl_verify_client on; }}EOF生成 Kubernetes ConfigMap 保存 NGINX 服務器的配置文件：
kubectl create configmap nginx-configmap -n mesh-external --from-file=nginx.cnotallow=./nginx.conf然后就可以部署 NGINX 服務了：
$ kubectl apply -f - <<EOFapiVersion: v1kind: Servicemetadata: name: my-nginx namespace: mesh-external labels: run: my-nginxspec: ports: - port: 443 protocol: TCP selector: run: my-nginx---apiVersion: apps/v1kind: Deploymentmetadata: name: my-nginx namespace: mesh-externalspec: selector: matchLabels: run: my-nginx template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx ports: - containerPort: 443 volumeMounts: - name: nginx-config mountPath: /etc/nginx readOnly: true - name: nginx-server-certs mountPath: /etc/nginx-server-certs readOnly: true - name: nginx-ca-certs mountPath: /etc/nginx-ca-certs readOnly: true volumes: - name: nginx-config configMap: name: nginx-configmap - name: nginx-server-certs secret: secretName: nginx-server-certs - name: nginx-ca-certs secret: secretName: nginx-ca-certsEOF現在如果我們在網格內部去直接訪問這個 my-nginx 服務，是無法訪問的，第一是沒有內置 CA 證書，另外是 my-nginx 服務開啟了 mTLS，需要客戶端證書才能訪問，現在我們的網格中是沒有對應的客戶端證書的，會出現 400 錯誤。
開啟了雙向認證
創建 Kubernetes Secret 保存客戶端證書：
kubectl create secret -n istio-system generic client-credential --from-file=tls.key=client.example.com.key / --from-file=tls.crt=client.example.com.crt --from-file=ca.crt=example.com.crtSecret 所在的命名空間必須與出口網關部署的位置一致，我們這里是 istio-system 命名空間。
然后為 my-nginx.mesh-external.svc.cluster.local 創建一個端口為 443 的 Egress Gateway，以及目標規則和虛擬服務來引導流量流經 egress 網關并從 egress 網關流向外部服務。
$ kubectl apply -f - <<EOFapiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata: name: istio-egressgatewayspec: selector: istio: egressgateway servers: - port: number: 443 name: https protocol: HTTPS hosts: - my-nginx.mesh-external.svc.cluster.local tls: mode: ISTIO_MUTUAL---apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: egressgateway-for-nginxspec: host: istio-egressgateway.istio-system.svc.cluster.local subsets: - name: nginx trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 443 tls: mode: ISTIO_MUTUAL sni: my-nginx.mesh-external.svc.cluster.localEOF上面我們定義的 Gateway 對象和前面的一樣，只是將端口改為了 443，然后在 tls 中指定了 mode: ISTIO_MUTUAL，表示該 Gateway 對象用于 TLS 雙向認證協議的請求。
然后同樣在后面的 DestinationRule 對象中配置了通過 istio-egressgateway 的流量的規則，這里我們定義了 443 端口的 tls 模式為 ISTIO_MUTUAL，表示當訪問 my-nginx.mesh-external.svc.cluster.local 的 TLS 請求時執行 TLS 雙向認證。
最后我們定義一個 VirtualService 對象來引導流量流經 egress 網關：
$ kubectl apply -f - <<EOFapiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata: name: direct-nginx-through-egress-gatewayspec: hosts: - my-nginx.mesh-external.svc.cluster.local gateways: - istio-egressgateway - mesh # 網格內部的流量 http: - match: - gateways: - mesh port: 80 route: - destination: host: istio-egressgateway.istio-system.svc.cluster.local subset: nginx port: number: 443 weight: 100 - match: - gateways: - istio-egressgateway port: 443 route: - destination: host: my-nginx.mesh-external.svc.cluster.local port: number: 443 weight: 100EOF上面的 VirtualService 對象定義網格內部對 my-nginx.mesh-external.svc.cluster.local 服務的訪問引導至 istio-egressgateway，然后再由 istio-egressgateway 引導流量流向外部服務。
添加 DestinationRule 執行雙向 TLS：
$ kubectl apply -n istio-system -f - <<EOFapiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata: name: originate-mtls-for-nginxspec: host: my-nginx.mesh-external.svc.cluster.local trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 443 tls: mode: MUTUAL credentialName: client-credential # 這必須與之前創建的用于保存客戶端證書的 Secret 相匹配 sni: my-nginx.mesh-external.svc.cluster.localEOF發送一個 HTTP 請求至 http://my-nginx.mesh-external.svc.cluster.local：
$ kubectl exec "$(kubectl get pod -l app=sleep -o jsnotallow={.items..metadata.name})" -c sleep -- curl -sS http://my-nginx.mesh-external.svc.cluster.local<!DOCTYPE html><html><head><title>Welcome to nginx!</title>...檢查 istio-egressgateway Pod 日志，有一行與請求相關的日志記錄。如果 Istio 部署在命名空間 istio-system 中，打印日志的命令為：
kubectl logs -l istio=egressgateway -n istio-system | grep 'my-nginx.mesh-external.svc.cluster.local' | grep HTTP將顯示類似如下的一行：
[2023-11-17T08:23:51.203Z] "GET / HTTP/1.1" 200 - via_upstream - "-" 0 615 17 16 "10.244.1.100" "curl/7.81.0-DEV" "434b5755-54da-9924-9e2a-a204b5a2124c" "my-nginx.mesh-external.svc.cluster.local" "10.244.1.106:443" outbound|443||my-nginx.mesh-external.svc.cluster.local 10.244.2.239:35198 10.244.2.239:8443 10.244.1.100:56448 my-nginx.mesh-external.svc.cluster.local -
雙向認證
即使我們直接在網格中訪問的是 HTTP 的服務，但是通過配置 Istio，我們也可以實現對外部服務的雙向 TLS 認證。
參考文檔：https://istio.io/latest/docs/tasks/traffic-management/egress/。
本文鏈接：http://www.www897cc.com/showinfo-26-31553-0.htmlIstio Egress 出口網關使用
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 通過實例理解Web應用跨域問題
下一篇： C++中的mutable關鍵字
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號