面對接二連三的災難性安全漏洞和勒索軟體攻擊，2021 年 5 月，拜登政府頒布了一項行政命令，要求改進美國的安全技術，並特別呼籲構建零信任 （zero trust，即ZT） 安全模型。
同年 8 月，美國國家標準與技術研究院 （NIST） 發佈了一份白皮書，白皮書定義了零信任架構（ZTA），並探討了“零信任可以改善企業整體資訊技術安全態勢的部署模型和用例”。 各個政府機構（包括網路安全和基礎設施安全域 （CISA） 以及管理和預算辦公室）相繼發佈零信任實施指導檔，其中包括一個成熟度模型以幫助實施者瞭解如何分步實現完全零信任部署。
多年來，Kubernetes 社群一直在討論如何讓零信任成為端到端加密戰略的關鍵組成部分。 service mesh 提供商已經實施了一些關鍵實踐（例如 mTLS 和證書密鑰輪換），旨在簡化零信任的實施。 但即便如此，我們仍處於在大規模應用中實施穩健零信任架構的早期階段。
關於零信任對 Kubernetes 意味著什麼以及最佳實踐是什麼，仍然存在一些爭議。 相比傳統 IT 和基礎架構系統，開箱即用的 Kubernetes 給不瞭解 Kubernetes 網路和安全與前者的區別的團隊帶來了重大的安全挑戰。
什麼是零信任？
為何零信任很重要？
傳統的安全模型在部署環境周圍構築了一個強大的邊界，並通過一個集中的“看門人”驗證使用者身份，且只允許授權使用者訪問內部的基礎架構。 隨著微服務、雲和分散式部署的採用，這種模型逐漸被淘汰，因為邊界已變得越來越模糊，甚至不確定邊界是否還存在。 零信任應運而生。
在零信任模型中，幾乎沒有任何東西或任何人是可信的，包括使用者、應用、網路、伺服器、服務或API。 每一層的每一個元素都必須經過身份驗證和授權測試。
當技術資產、應用或服務連接並交換數據時，所有通信都通過指定的代理進行路由，該代理對所有各方進行身份驗證並根據訪問策略授予他們許可權。 重要的是，除了明確授權訪問特定資源的人以外，零信任系統在每個級別都以最小許可權運行，並拒絕所有各方的訪問。
零信任具有很多優勢 —— 它可以通過以下方式改善安全狀況：
- 自動阻止未經授權的活動
- 通過存取控制減少可訪問的攻擊面
- 快速檢測行為異常和危害指標（Indicator of Compromise）
- 通過即時最小許可權策略限制存取時間
- 使安全性獨立於其他所有變數，包括環境和地理
- 通過持續的認證和身份驗證攔截正在進行的攻擊
零信任對於雲原生應用和基礎架構尤為重要。 鬆散耦合且可移植的雲原生應用被設計成在容器中運行，並根據需要改變位置和狀態。 除了代碼、配置和少數必要元素（例如將雲原生應用連結到外部世界或內部服務的IP位址）之外，一切都是短暫的。
東西向流量（環境內部的流量）和南北向流量（進出環境的流量）看起來越來越相似。 API 在所有通信（包括應用環境內的通信和與外部用戶端的通信）中起仲介作用。 不斷驗證許可權和身份不僅有用，而且最終還是一種安全需要。
在 Kubernetes 中實施零信任的七條準則
為 Kubernetes 驅動的基礎架構和應用部署零信任可能具有一定的挑戰性，為此我們提供了一系列實施準則。 這些準則可能看起來平淡無奇，但要從零開始實施也不輕鬆。
準則1
避免增加 Kubernetes 架構的複雜性
在沒有零信任框架的情況下運行 Kubernetes 具有挑戰性，而添加零信任會使事情變得更加複雜。 對於許多廠商來說，提供額外服務或功能的預設方式是添加新的 sidecar 或 Kubernetes 自定義資源定義（CRD）。
不幸的是，無論添加什麼都會增加複雜性。 例如，當您添加一個新的 sidecar 來傳輸可觀察性數據時，Kubernetes 必須維護一個甚至兩個以上的網路連接。 增加的複雜性不僅會降低應用的速度，而且由於需要更大的 pod 來滿足應用需求，還會導致基礎架構的成本急劇增加。 奧卡姆剃刀原理適用於此：最簡單的零信任路徑、最少的 sidecar 和 CRD 通常就是最好的。
準則2
將開發人員和最終使用者的額外開銷降至最低
開發人員不想考慮零信任，而且我們也沒有理由強迫他們考慮。 當零信任的實施迫使開發人員改變其行為或工作流程時，他們可能會抗拒，因為他們認為安全防護會影響開發速度。
改變行為或工作流程也顯著增加了人為錯誤的機會 ——開發人員本身始終是安全鏈中的薄弱環節。 作為NetOps 或 SecOps 工程師，如果零信任機制透明到開發人員（以及最終使用者和客戶）都不知道它們的存在，那麼您就成功了。
事實上，通過增強安全策略及提高其自動化水準，從理論上來說，零信任甚至可以消除多因素身份驗證和許多安全流程中的不便，進而改善最終用戶的體驗。
準則3
將零信任規則應用於數據平面和控制平面
雖然數據平面是應用的「活動所在地」 ，但控制平面通常也同樣容易（有時甚至更容易）遭受供應鏈攻擊和其他入侵。 由於策略引擎以及用於遙測和跟蹤的數據收集系統等複雜元素的介入，在控制平面上實施零信任合規要比在數據平面上更複雜。
雖然我們很想為數據平面實施零信任，並減少對控制平面及其所有移動部件的擔憂，但我們必須確保兩者都符合要求，以最大限度發揮零信任的優勢。
準則4
為東西向和南北向流量實施零信任
許多企業開始選擇僅將零信任應用到南北向流量，因為來自環境外部的流量似乎不如內部流量可信。 這是一種錯誤的做法。
在 Kubernetes 中，東西向流量無論在外觀還是行為上都很像南北向流量。 Kubernetes 服務、節點和pod 都通過 API 在 HTTP 或 HTTPS 上進行通信。 將相同的零信任策略和流程應用到所有流量會明顯提高安全性，並且這樣做不會產生更多開銷。
此外，一開始便在所有位置應用零信任還有一個好處，可避免在南北向零信任實踐發生改變後對東西向零信任實踐進行修補的風險或麻煩。
準則5
同時使用 Ingress controller 和 service mesh
雖然不用 Ingress controller 或 service mesh 也可以在 Kubernetes 中構建和運行應用，但如果您想輕鬆地讓零信任成為基礎架構中所有元素的預設設置，您就需要用到它們了。
Ingress controller 包含了 API 閘道和負載均衡器的一些較有用的功能。 它的另一項強大優勢是可以用作真正的反向代理，能夠將流量路由到特定的 Kubernetes pod（與傳統的負載均衡器不同）。 service mesh 從根本上簡化了零信任在東西向流量上的實施、面向審計和驗證目的的可觀測性和報告。
因此，如果您想通過更簡單、更清晰的方式實現零信任，那麼請在架構設計時同時考慮 Ingress controller 和 service mesh。
準則6
將 Ingress controller 與 service mesh 整合
該準則與準則 5 密切相關。 並非所有 Ingress controller 都可以與所有 service mesh 緊密整合。
例如，基於 Istio 的 service mesh 使用與 NGINX Ingress Controller 不同類型的證書管理系統。 在設計階段確保這兩個工具能夠輕鬆地緊密整合，可以避免日後出現嚴重的複雜性和配置問題。 有關整合南北向和東西向解決方案的示例，請閱讀我們的博文《如何簡化 Kubernetes 出入向流量管理》。
準則7
自動化證書的正確處理
對於其他大多數安全的連接形式，證書維護對於在 Kubernetes 中運行用於加密的公鑰基礎設施（PKI） 元件至關重要。 而對於零信任一致性，證書管理必須是自動化和動態的，這意味著證書需要定期過期和輪換，以確保持續進行身份驗證。
service mesh 和 Ingress controller 都需要自動進行證書頒發、輪換和到期。 如果 Ingress controller 或 service mesh 的本地或最佳整合證書管理工具無法做到這一點，您要不就需要想其他辦法，要不就得選擇放棄。
NGINX 的零信任
無影無形、無所不在、輕鬆簡單
零信任尚處於早期發展階段。 如果拿採用 Kubernetes 的合作夥伴作為指標來看的話，學習曲線比我們希望的要陡峭一些。 話雖如此，雲原生和雲託管應用的發展趨勢 —— 以及持續的網路安全威脅使得向零信任的過渡勢在必行。 通過常識判斷，並就實施零信任的系統做出明智的選擇，您可以更快、更順利地過渡到最終目標，實現不僅無價而且無影無形、無所不在、輕鬆簡單的零信任。
在 Kubernetes 中實現零信任並非易事，但使用具有預先設計的零信任架構功能的 Ingress controller 和 service mesh 可以説明您節省時間並免去麻煩。
您可以立即點擊文末「閱讀原文」使用我們的 Kubernetes 解決方案 —— 帶有 F5 NGINX Service Mesh 的 F5 NGINX Ingress Controller 。 有了它們，只需一個 CLI 命令即可輕鬆進行配置更改，從而滿足您對零信任的大部分需求。