使用服務網格提高安全性：Christian Posta帶你探索Istio的新功能

\

主要結論

\\

• Istio意在讓“服務網格（Service Mesh）”這個概念變得更具體、更好理解，最新發布的Istio 1.0有望獲得業界的廣泛關注。\\t
• Istio試圖解決通過雲平臺執行應用程式時可能面臨的一些困難挑戰：應用程式網路、可靠性以及可觀測性。\\t
• Istio還希望解決安全性這個問題。藉助Istio，網格中不同服務間的通訊將更安全，並預設加密。\\t
• Istio還有助於解決“源頭”和“終端使用者”的JWT標識令牌驗證問題。\\t
• 這些基礎的安全功能可以幫助我們構建“零信任”網路，藉此根據標識、上下文情境以及具體情況來分配信任，而不再讓“呼叫方恰巧位於同一個內部網路中”。\

\\

Istio意在讓“服務網格”這個概念變得更具體、更好理解，最新發布的Istio 1.0有望獲得業界的廣泛關注。InfoQ之前的文章中，Jasmine Jaksic曾經詳細介紹了Istio和服務網格，因此本文我想重點介紹Istio在安全領域採取的措施，這些功能將會為雲服務的開發和運維人員提供巨大價值。

\\

Istio的用例

\\

Istio試圖解決通過雲平臺執行應用程式時可能面臨的一些困難挑戰。具體來說，Istio主要解決了應用程式網路、可靠性和可觀測性等問題。以往我們通常會使用預構建的應用程式庫來應對這些挑戰，如斷路器、客戶端負載均衡、指標集（Metrics collection）等。然而跨越不同語言、框架、執行時等內容這樣做，會造成大部分組織都無法承受的運營負擔。

\\

此外，這種做法也很難確保在每種語言的實現中維持一致，更不用提需要改動或修復Bug時用固定的步驟將它們一次升級到位了。圍繞可靠性、可觀測性以及策略的實施會遇到大量挑戰，任何企業無一例外都會面臨類似情況。雖然不同企業面臨的問題基本類似，但如果不加以重視都會對業務造成巨大應向，因此必須妥善解決。Istio的目標就是解決這些難題。

\\

網路安全的重要性

\\

對應用程式團隊來說，安全性是另一個共同面臨，並且難以解決的問題。某些情況下，安全性只是一種事後想法，而我們往往會在最後一刻試圖將它硬塞進自己的應用中。為什麼？因為安全性很難做到足夠好。舉例來說，諸如“加密應用程式流量”這種基本工作應該很常見並且很簡單，對吧？在服務端配置TLS/HTTPS也應該很簡單，對吧？甚至之前的專案中可能很早就這樣做過了。然而在我看來，做的到底是否正確，就不那麼好判斷了。加密是否使用了正確的證照？證照是否由客戶端認可的CA頒發？是否選擇了正確的加密演算法？是否將其正確匯入至證照儲存/金鑰庫？難道不是直接在TLS/HTTPS配置中啟用“—insecure”標記就行了嗎？

\\

此類錯誤的配置可能非常危險。Istio則能提供必要幫助。Istio會在負責處理應用程式網路流量的每個應用程式例項旁部署（基於Envoy代理的）旁側代理（Sidecar proxy）。當應用程式試圖與http://foo.com通訊時，將通過這個旁側代理（使用環回網路介面）通訊，隨後Istio會將通訊重定向至另一個服務的旁側代理，並最終將通訊代理至實際的上游http://foo.com。通過在請求路徑上放置這些代理，即可實現類似不被應用程式知曉的透明自動加密等操作。藉此無需要求每個應用程式的開發團隊“做正確的事”，一樣可以實現一致的流量加密。

\\

\\

在配置和維護TLS以及為服務架構搭建共用的TLS過程中，證照的管理也是難題之一。Istio的控制介面提供了Citadel元件，可以用於管理應用程式例項的證照和金鑰。Citadel能夠生成供每個工作負載表明自身身份所需的證照和金鑰，並能定期更換，這樣任何被攻陷的證照都會盡快失效。藉助這樣的證照，支援Istio的叢集就可以自動獲得共用的TLS。當然使用者也可以在必要時加入自己的CA提供商根證照。

\\

\\

藉助Istio，網格中不同服務間的通訊將更安全，並預設加密。使用者無需折騰證照和CA證照鏈即可獲得能投入實用的TLS。運營商也不再需要祈禱每位開發者正確實現並配置自己的TLS/HTTPS設定。這一切都可以通過Istio的配置自動實現。

\\

使用Istio實現mTLS

\\

Istio在配置方面採取了與Kubernetes類似的路徑。實際上，在Kubernetes中，我們可以通過Kubernetes Custom Resource Definition（CRD）物件配置Istio。用於配置Istio安全策略的兩個重要物件包括Policy和DestinationRule物件。Policy物件可配置服務（或一組服務）的安全設定，例如，若要配置Kubernetes中執行的一個客戶名稱空間中的所有服務，可以使用下列Policy物件：

\\

\apiVersion: “authentication.istio.io/v1alpha1”\kind: “Policy”\metadata:\  name: “default”\  namespace: “customer”\spec:\  peers:

\\

通過上述配置，該客戶名稱空間中執行的所有服務均會接受使用mTLS的傳入流量。但為了使用mTLS，我們還需要告訴客戶端在呼叫服務時使用mTLS。為此可以使用Istio的DestinationRule物件。Istio中的DestinationRule可用於配置客戶端與服務的通訊方式，我們可以在DestinationRule中指定很多設定，如斷路器、負載均衡和TLS。若要啟用mTLS，可使用下列配置：

\\

\apiVersion: “networking.istio.io/v1alpha3”\kind: “DestinationRule”\metadata:\  name: “default”\  namespace: “foo”\spec:\  host: “*.customer.svc.cluster.local”\  trafficPolicy:\    tls:\      mode: ISTIO_MUTUAL

\\

上述DestinationRule會要求客戶端在發出呼叫，與客戶名稱空間中的服務通訊時使用mTLS。我們還可以將TLS模式配置為ISTIO_MUTUAL，這意味著我們允許讓Istio管理證照和金鑰，並將其載入服務（使用Kubernetes中的Kubernetes機密），隨後服務代理即可用它們來發起TLS通訊。如果希望自行控制客戶端證照，則可使用MUTUAL模式，並通過磁碟位置提供證照，這樣客戶端即可找到所需證照和私鑰。

\\

使用Istio驗證來源身份（藉助JWT）

\\

按照上述方式使用mTLS時，不僅可以加密連線，並且更重要的是可以清楚地知道誰在呼叫誰。Istio使用了Secure Production Identity Framework for Everyone（SPIFFE）規範，標識可直接編碼到mTLS使用的證照中。通過這樣的方式，當服務B與服務A通訊時，服務A就可以確認服務B的真實身份。我們可以針對這些標識編寫規則，藉此決定服務網格必須應用的規則或策略。舉例來說，如果服務A不允許與服務B通訊，即可在每個應用程式旁側執行的代理中，使用建立mTLS所必須的標識來實施這樣的策略。

\\

但如果服務A是代表使用者X向服務B發出請求又會怎樣？如果服務A有權呼叫並訪問服務B來執行某些操作（例如檢查賬戶餘額），但使用者X無權這樣做，如何確認並實現這一目標？在服務架構中，服務與終端使用者或來源標識（登入的使用者）進行通訊的典型方式是傳遞標識令牌，例如JSON Web Token。這些令牌可以代表已經通過身份驗證的使用者以及這些使用者的主張。

\\

Istio有助於實現“來源”或“終端使用者”JWT標識令牌的驗證。以往這也是個非常麻煩的領域，因為不同的應用程式語言/框架組合使得我們很難通過庫來處理驗證工作並解包JWT令牌。舉例來說，在流行的Keycloak Identity和SSO專案中，為了處理這類操作，甚至為每種流行的語言提供了語言外掛。但如果使用Istio，就可以更自由地實現這一切。例如，若要配置Istio在請求中使用mTLS，同時驗證JWT令牌（如果令牌不存在、無效或過期，則讓請求失敗），我們可以配置Policy物件。畢竟Policy物件就是用於指定希望服務表現出的行為的：

\\

\apiVersion: “authentication.istio.io/v1alpha1”\kind: “Policy”\metadata:\  name: “customer-jwt-policy”\spec:\  targets:\  - name: customer\  peers:\  - mtls:\  origins:\  - jwt:\      issuer: http://keycloak:8080/auth/realms/istio\      jwksUri: http://keycloak:8080/auth/realms/istio/protocol/openid-connect/certs\  principalBinding: USE_ORIGIN

\\

通過上述配置，如果客戶端試圖連線至客戶的服務，除非JWT身份驗證成功，否則請求將無法到達服務。使用Istio的另一個優勢在於請求依然可獲得mTLS的保護，藉此可保護JWT令牌不被洩露並用於某種型別的重播攻擊。

\\

未來：零信任網路

\\

本文介紹了在構建雲原生應用過程中，Istio在改善安全性方面提供的幾種方法。通過在服務相互之間，以及與來源/終端使用者通訊過程中使用強標識機制，我們可以編寫出一些非常強大的訪問控制規則，藉此對系統行為加以約束。這些基本功能為“零信任”網路的搭建奠定了基礎。在零信任網路中，我們可以根據標識、上下文情境以及具體情況來分配信任，而不再讓“呼叫方恰巧位於同一個內部網路中”。隨著逐漸步入全面互聯模式以及混合雲部署模式，我們也需要重新思考如何以最佳方式讓整個架構獲得安全性。Istio可以解決當今架構所面臨的很多挑戰，並在未來提供更豐富的選項。

\\

Istio提供了非常強大的功能，服務團隊可以藉此解決自己面臨的很多問題。它還提供了實用的API與配置物件，藉此可在應用程式服務之外進行配置。以高度去中心化方式實現的這一切面對故障將獲得更高彈性。如果你需要構建服務網格，並且希望實現一致的高安全性，那麼Istio值得一試。

\\

關於本文作者

\\

Christian Posta（@christianposta）是Red Hat的雲應用程式首席架構師，並以圖書作者（Introducing Istio Service Mesh，O’Reilly 2018；Microservices for Java Developers，O’Reilly 2016）、博主、演講人、開源傳道士，以及包括Istio、Apache ActiveMQ、Fabric8等在內眾多開源專案貢獻者的身份聞名於社群。Christian在大規模企業有多年工作經驗，現在致力於幫助企業建立並部署大規模、高彈性、分散式架構，也就是現在我們所說的微服務。他喜歡輔導、培訓並領導團隊從事有關分散式系統、微服務、DevOps、雲原生應用程式設計的專案。

\\

閱讀英文原文：Increasing Security with a Service Mesh: Christian Posta Explores the Capabilities of Istio