服務(wù)網(wǎng)格是一項(xiàng)熱門技術(shù)，有時(shí)甚至被吹捧為微服務(wù)成功的必要條件。但是，與許多抽象一樣，服務(wù)網(wǎng)格可以節(jié)省時(shí)間，但不會(huì)節(jié)省學(xué)習(xí)時(shí)間。事實(shí)上，許多小型平臺(tái)團(tuán)隊(duì)對(duì)服務(wù)網(wǎng)格增加的復(fù)雜性感到不知所措，尤其是在涉及到長(zhǎng)時(shí)間的操作時(shí)。

很自然地會(huì)問(wèn)一個(gè)問(wèn)題：額外的復(fù)雜性真的超過(guò)了好處嗎？

在這篇文章中，我們提出了在投資服務(wù)網(wǎng)格之前要考慮的替代方案。服務(wù)網(wǎng)格最流行的好處是：

• 驗(yàn)證;
• 入口加密；
• 集群內(nèi)網(wǎng)絡(luò)加密；
• 通訊隔離。

對(duì)于這些好處中的每一個(gè)，我們將展示根據(jù)我們的經(jīng)驗(yàn)更接近管理員已經(jīng)熟悉的替代方案。對(duì)于專業(yè)知識(shí)或平臺(tái)工程帶寬稀缺的組織，這些可能更具吸引力。

在某些情況下，您將需要服務(wù)網(wǎng)格，例如當(dāng)您需要跨多個(gè) Kubernetes 集群的安全 Pod 到 Pod 通信時(shí)。通過(guò)排除不能滿足您需求的解決方案，您將進(jìn)一步說(shuō)服自己為什么選擇服務(wù)網(wǎng)格開始。

Service Mesh 優(yōu)勢(shì) 1 - 使用 OAuth2-proxy 進(jìn)行身份驗(yàn)證

許多應(yīng)用程序團(tuán)隊(duì)需要在他們的微服務(wù)前面添加一個(gè)身份驗(yàn)證層。例如，完全實(shí)現(xiàn) OAuth2 或 OpenID 涉及相當(dāng)多的跳轉(zhuǎn)。與其編寫大量樣板代碼（這與應(yīng)用程序非特定和非業(yè)務(wù)差異化相比），團(tuán)隊(duì)更愿意“某物”只是將具有正確聲明的 JWT 令牌交給他們的應(yīng)用程序，以便專注于特定于應(yīng)用程序的訪問(wèn)控制。

我們之前寫過(guò)關(guān)于如何將 Istio 與 OAuth2-proxy 集成以實(shí)現(xiàn)這一目標(biāo)的博客。但是，如果這是您從 Istio 中唯一需要的東西，那么采用它可能有點(diǎn)過(guò)頭了。

服務(wù)網(wǎng)格的替代方案：Nginx Ingress Controller

讓我舉例說(shuō)明一個(gè)我認(rèn)為更簡(jiǎn)單的解決方案，尤其是對(duì)于已經(jīng)使用 Nginx 的團(tuán)隊(duì)。如果你只需要一些好的 oauth2-proxy，Nginx Ingress Controller 很容易與之集成。只需使用 auth-url 注釋，控制器將完成其余的工作。下圖說(shuō)明了這是如何工作的。

我認(rèn)為這個(gè)解決方案更簡(jiǎn)單的原因是它只會(huì)影響流量進(jìn)入 Kubernetes 集群的方式。Pod 到 Pod 的通信和以前一樣工作。

如果您熟悉 Nginx，但害怕 Ingress Controller 在其周圍添加的自動(dòng)化，您可以通過(guò)鍵入以下內(nèi)容直接檢查 Nginx 的配置方式：

kubectl exec -ti \
-n ingress-nginx \
$(kubectl get pod \
-n ingress-nginx \
-l app.kubernetes.io/component=controller \
-o name \
| head -1 \
) \
-- \
cat /etc/nginx/nginx.conf

默認(rèn)情況下，您的應(yīng)用程序不會(huì)獲得 JWT 令牌。為了確保您的應(yīng)用程序獲得細(xì)粒度訪問(wèn)控制的聲明，您必須做兩件事：

• 首先，將--set-authorization-header命令行選項(xiàng)添加到 oauth2-proxy：這可確保 oauth2-proxy 生成 HTTP 授權(quán)標(biāo)頭。
• 其次，將以下注釋添加到您的 Ingress：nginx.ingress.kubernetes.io/auth-response-headers: “authorization” 。這可確保 Nginx 入口控制器將 HTTP 授權(quán)標(biāo)頭從 oauth2-proxy 轉(zhuǎn)發(fā)到您的應(yīng)用程序。

如果您需要更多詳細(xì)信息，可以在此處找到現(xiàn)成的代碼片段。

• ?https://github.com/elastisys/compliantkubernetes/blob/main/user-demo/deploy/oauth2-proxy.yaml
• https://elastisys.io/compliantkubernetes/user-guide/network-model/#ingress?

Service Mesh 優(yōu)勢(shì)二：入口加密

許多法規(guī)要求對(duì)不受信任網(wǎng)絡(luò)上的網(wǎng)絡(luò)流量進(jìn)行加密。例如，PCI-DSS 要求 4 規(guī)定：“通過(guò)在開放的公共網(wǎng)絡(luò)上加密來(lái)傳輸持卡人數(shù)據(jù)?！?GDPR 和瑞典醫(yī)療保健（“Behandling av personuppgifter i?ppna n?t”“通過(guò)開放網(wǎng)絡(luò)處理個(gè)人數(shù)據(jù)”）包含類似規(guī)定。

解決方案很簡(jiǎn)單：添加 TLS 終止。但是，TLS 終止不是業(yè)務(wù)差異化，也不是特定于應(yīng)用程序的。理想情況下，平臺(tái)應(yīng)該“做它”。我經(jīng)?？吹綀F(tuán)隊(duì)僅針對(duì)這一功能采用服務(wù)網(wǎng)格，但還有一種更簡(jiǎn)單的替代方案。

服務(wù)網(wǎng)格的替代品：Cert-manager

您可以安裝cert-manager，創(chuàng)建 ClusterIssuer 并通過(guò)注解使用該 ClusterIssuer 配置您的 Ingress。Cert-manager 將發(fā)揮與 LetsEncrypt 對(duì)話的魔力，提供 TLS 證書并在其到期前輪換它。

這在上圖和相同的即用型代碼片段中進(jìn)行了說(shuō)明。請(qǐng)參閱cert-manager.io/cluster-issuer注釋。

Service Mesh 優(yōu)勢(shì)三：集群內(nèi)網(wǎng)絡(luò)加密

為一些爭(zhēng)議做好準(zhǔn)備。

我經(jīng)?？吹浇M織添加服務(wù)網(wǎng)格，因?yàn)?mTLS 和 Pod 到 Pod 加密很酷，并且可能是某些法規(guī)要求的。這是我對(duì)這個(gè)話題的看法。

首先，您很少（如果有的話）需要 Pod 到 Pod 加密。如上所述，PCI-DSS 和瑞典醫(yī)療保健都只需要對(duì)開放（即不受信任）網(wǎng)絡(luò)進(jìn)行加密。我經(jīng)常聽(tīng)到團(tuán)隊(duì)爭(zhēng)論 Pod 到 Pod 加密“以防萬(wàn)一”底層網(wǎng)絡(luò)不受信任。如果您不能信任您的基礎(chǔ)設(shè)施提供商，請(qǐng)更換提供商。再多的加密都不會(huì)阻止他們?cè)趦?nèi)存中未加密時(shí)訪問(wèn)您的數(shù)據(jù)。

其次，假設(shè)您確實(shí)需要集群內(nèi)加密。例如，您希望將 Kubernetes 集群擴(kuò)展到通過(guò)不受信任的網(wǎng)絡(luò)連接的兩個(gè)數(shù)據(jù)中心?；蛘撸Ｍ苊馀c兩個(gè)數(shù)據(jù)中心之間的網(wǎng)絡(luò)提供商簽署另一個(gè) GDPR 風(fēng)格的數(shù)據(jù)保護(hù)協(xié)議 (DPA)。

服務(wù)網(wǎng)格的替代方案：CNI 級(jí)加密

在這種情況下，只需在您的容器網(wǎng)絡(luò)接口 (CNI) 提供程序中啟用 WireGuard 或 IPsec。這樣就達(dá)到了加密網(wǎng)絡(luò)流量Node-to-Node的效果。至少Calico和Flannel對(duì)此有支持。例如，如果您使用 Kubespray 設(shè)置 Calico，只需添加：

calico_wireguard_enabled: true

Service Mesh 的優(yōu)勢(shì)四：網(wǎng)絡(luò)通信的隔離

服務(wù)網(wǎng)格帶來(lái)了另一個(gè)特性：它們?yōu)槊總€(gè) Pod 賦予一個(gè)身份，然后通過(guò)相互身份驗(yàn)證 (mTLS) 實(shí)施基于身份的訪問(wèn)控制。這帶來(lái)了兩個(gè)好處：首先，您的 Pod “不要與陌生人交談”，這有助于使某些漏洞更難被利用，例如臭名昭著的Log4Shell。其次，它減少了爆炸半徑：如果 Pod 被闖入，攻擊者會(huì)發(fā)現(xiàn)很難橫向移動(dòng)。

服務(wù)網(wǎng)格的替代方案：NetworkPolicies

但是使用 NetworkPolicies 可以更簡(jiǎn)單、更標(biāo)準(zhǔn)化地實(shí)現(xiàn)相同的好處。它們就像容器化世界中的防火墻規(guī)則或安全組。由于 Pod 在每次部署時(shí)都會(huì)更改 IP 地址，因此 NetworkPolicies 本質(zhì)上會(huì)將 Pod 身份轉(zhuǎn)換為基于 IP 的防火墻規(guī)則，由 Linux 內(nèi)核強(qiáng)制執(zhí)行。

NetworkPolicy 由兩部分組成：選擇器和規(guī)則。選擇器選擇 NetworkPolicy 應(yīng)用于哪些 Pod，匹配 Pod 標(biāo)簽或命名空間標(biāo)簽。規(guī)則指定允許進(jìn)出所選 Pod 的入口和出口流量?？梢栽O(shè)置安全措施以確保每個(gè) Pod 都由 NetworkPolicy 選擇。

在某些組織中，網(wǎng)絡(luò)安全和應(yīng)用程序安全是不同團(tuán)隊(duì)的責(zé)任。這可以通過(guò) NetworkPolicies 和 Kubernetes RBAC 在技術(shù)上強(qiáng)制執(zhí)行。只有網(wǎng)絡(luò)團(tuán)隊(duì)被授予編輯 NetworkPolicies 的權(quán)限，而應(yīng)用程序團(tuán)隊(duì)僅被授予在選定的命名空間中部署的權(quán)限。

最后一條建議：將命名空間視為“內(nèi)部 API”。由于命名空間最終成為集群內(nèi) DNS 名稱的一部分，因此最好通過(guò)它提供的服務(wù)（例如，“auth”、“database”、“l(fā)icensing”）來(lái)命名命名空間，而不是團(tuán)隊(duì)名稱（“team-green ”、“team-yellow”等）。這種做法還簡(jiǎn)化了網(wǎng)絡(luò)安全團(tuán)隊(duì)設(shè)置 NetworkPolicies 的過(guò)程。

結(jié)論

簡(jiǎn)單性和可理解性是安全的關(guān)鍵。雖然安全網(wǎng)格帶來(lái)了巨大的好處，但在采用它們之前請(qǐng)考慮更簡(jiǎn)單的替代方案。我的經(jīng)驗(yàn)是網(wǎng)絡(luò)和網(wǎng)絡(luò)安全已經(jīng)足夠復(fù)雜。添加另一層可能會(huì)使您的平臺(tái)團(tuán)隊(duì)不堪重負(fù)，并給他們帶來(lái)“待命焦慮”。

當(dāng)然，有許多出色的服務(wù)網(wǎng)格特性缺乏更簡(jiǎn)單的替代方案，例如多集群安全通信和聯(lián)合網(wǎng)絡(luò)可觀察性。如果您確實(shí)需要更高級(jí)的功能，我們希望這篇博文可以幫助您做出明智的決定并接受新增的技術(shù)。

Kubernetes 網(wǎng)絡(luò)和服務(wù)網(wǎng)格都在快速發(fā)展。就在最近幾個(gè)月，Calico 添加了一個(gè) eBPF 數(shù)據(jù)平面，并且 Istio 被捐贈(zèng)給了 CNCF。此類事件可以有利于決策者決定傾向于采用或不采用服務(wù)網(wǎng)格。