我們曾在《在不影響速度的同時保護雲原生應用》一文中探討過，有三個因素使雲原生應用比傳統應用更難以保護：
- 雲原生應用交付導致工具泛濫以及不一致的企業級服務
- 雲原生應用交付成本可能非常高且不可預測
- SecOps 團隊難以保護雲原生應用，並與 DevOps 存在分歧
雖然這三點都會影響安全性，但也許是由於第三點涉及到人的因素最多，它可能是最棘手的問題。 如果SecOps 沒有能力或沒有足夠的許可權保護雲原生應用，那麼有些後果很明顯（漏洞和違規），有些後果卻很隱蔽，例如敏捷性降低、數位化轉型停滯不前等。
我們來深入探討一下這些隱性的代價。 企業之所以選擇 Kubernetes，是因為它有望提高敏捷性並降低成本。 但是當 Kubernetes 環境發生安全事件時，多數企業又會將他們的 Kubernetes 部署挪到生產環境之外。 且不說這會減緩事關企業未來發展的數位化轉型的步伐，就連投入的工程設計和資金也付諸東流了。 從邏輯上來說，如果您希望 Kubernetes 完成從測試到生產的旅程，那麼就必須將安全性視為重要的戰略組成部分，讓企業中的每個人都予以高度重視。
本文介紹了您可以使用 Kubernetes 流量管理工具解決的六個安全用例，該工具允許 SecOps 與 DevOps 和NetOps 更好地協作保護雲原生應用和 API。 您可以搭配使用這些技術以構建一套全面的安全戰略，從而在保護應用和 API 的同時，最大限度地減少對客戶的影響。
安全防護及身份驗證的相關術語
在介紹用例之前，我們先快速瞭解一下您將在本文中遇到的安全防護及身份驗證的相關術語。
- 身份驗證和授權 —— 用於確保只有“正確”的使用者和服務可以存取後端或應用元件，是系統必備的功能：
- 身份驗證 —— 驗證“身份”，確保發出請求的用戶端與自己聲稱的身份相符。 通過 ID 令牌實現，例如密碼或JSON Web Tokens （JWTs）。
- 授權 —— 驗證資源或功能的存取“許可權”。 通過存取令牌實現，例如會話 cookie、工作階段 ID、組 ID 或令牌內容等 7 層屬性。
- 通用漏洞披露 （CVE） —— 這是一個漏洞資料庫，它公開披露了“軟體、韌體、硬體或服務元件中可能會遭到利用的漏洞缺陷，這些缺陷會破壞受影響的一個或若干元件的機密性、完整性或可用性” （https://www.cve.org/)。 CVE 可能由管理工具的開發人員、滲透測試人員、使用者或客戶或社群人員（例如漏洞獵人）發現。 在公開披露漏洞之前，披露者通常會給軟體擁有者一定的時間來開發補丁，以免給駭客帶來可乘之機。
- 拒絕服務 （DoS） 攻擊 —— 一種網路攻擊，惡意請求（TCP/UDP 或 HTTP/HTTPS）猶如洪水般湧向受害網站，目的是讓網站癱瘓。 DoS 攻擊會影響可用性，因此它們造成的主要後果就是受害者的聲譽受損。 分散式拒絕服務 （DDoS） 攻擊是指多個攻擊源瞄準同一個網路或服務進行攻擊，由於攻擊者的潛在網路規模較大，防禦起來也更加困難。 DoS 防護需要一種可以自適應識別和防止攻擊的工具。 更多資訊請參閱《分散式拒絕服務 （DDoS） 詳解》。
- 端到端加密 （E2EE） —— 對從使用者傳輸到應用和後端的數據全程進行完全加密。 E2EE 需要 SSL 證書，可能也需要 mTLS。
- 雙向 TLS （mTLS） —— 一種對用戶端和主機都進行身份驗證（通過 SSL/TLS 證書）的實踐。 使用 mTLS 還可以保護在用戶端和主機之間傳輸的數據的機密性和完整性。 mTLS 的實施可以細化到 Kubernetes pod 級別、同一集群的兩個 service 之間。 有關 SSL/TLS 和 mTLS 的詳細介紹，請參閱 F5 Labs 的《什麼是mTLS？ 》。
- 單點登錄 （SSO） —— SSO 技術（包括 SAML、OAuth 和 OIDC）可以簡化身份驗證和授權的管理。
- 簡化的身份認證 —— SSO 讓使用者省去了針對每個不同的資源或功能設置唯一 ID 令牌的麻煩。
- 標準化授權 —— SSO 有助於根據角色、部門和資歷設置使用者存取許可權，無需為每個使用者單獨配置許可權。
- SSL（安全套接字層）/TLS（傳輸層安全） —— 一種用於在聯網計算機之間建立經過身份驗證和加密的連結的協定。 SSL/TLS 證書能夠驗證網站的身份並建立加密連接。 雖然 SSL 協定已經在 1999 年棄用並被 TLS 協定取代，但我們通常仍然將這些相關技術稱為“SSL”或“SSL/TLS” — 為了保持一致，本文接下來均使用“SSL/TLS”一詞。
- Web 應用防火牆 （WAF） —— 一種反向代理反向代理，能夠檢測和攔截針對應用和 API 的複雜攻擊（包括OWASP 十大安全漏洞和其他進階威脅）， 同時讓「安全」的流量順利通過。 Web 應用防火牆能夠識破駭客的「奸計」，防止他們竊取敏感數據或劫持系統。 有些廠商將 WAF 和 DoS 防護整合到了一種工具中，有些廠商則提供獨立的 WAF 和 DoS 防護工具。
- 零信任 —— 一種經常用於高等安全企業的安全概念，但與每個人息息相關，數據必須在存儲和運輸的所有階段都得到保護。 零信任意味著企業決定在默認情況下不“信任”任何使用者或設備，且所有流量都必須經過全面檢查。 零信任架構通常會包括一組身份驗證工具、授權工具以及 mTLS，並且企業實施端到端加密的可能性很大。
案例：快速解決 CVE 漏洞，有效避免網路攻擊
解決方案：使用能夠發出及時主動的補丁通知的工具
波耐蒙研究所的一項研究指出，在 2019 年，企業平均有 43 天的“寬限期”來開發和發佈重大漏洞或高優先順序漏洞的補丁，否則就會有攻擊者利用漏洞圖謀不軌。 F5 NGINX 發現，這個視窗在接下來的幾年裡明顯縮短了（2021 年的 Apple iOS 15 事件甚至連一天也沒有），也是出於這個原因，我們建議儘快打補丁。 但是，如果在 CVE 發佈後的幾周甚至幾個月內，您的流量管理工具都沒有可用的補丁，怎麼辦？
由社群貢獻者（而不是專門的工程團隊）開發和維護的工具可能會在 CVE 發佈以後滯後幾周或幾個月，導致企業難以在 43 天內完成打補丁。 在之前的一個案例中，OpenResty 花了四個月的時間來應用NGINX 相關的安全補丁。 這導致使用基於 OpenResty Ingress Controller 的使用者至少在四個月的時間里存在風險，並且對於依賴開源專案的軟體來說，通常還要再等一段時間才能獲得補丁。
要以最快的速度獲得 CVE 漏洞補丁，請在選擇流量管理工具時注意以下兩個特性：
- 專門的工程團隊 —— 如果有一支工程團隊負責工具開發（而非社群志願者），那麼您就知道有一群人會全力保障該工具的健康，並會優先考慮儘快發佈補丁。
- 整合的代碼庫 —— 只要不依賴外部專案（就像我們在 OpenResty 案例中討論的那樣），打補丁就快速多了。
有關 CVE 漏洞補丁的更多資訊，請參閱《NGINX Plus 助您快速輕鬆地緩解安全漏洞》。
案例：抵御 OWASP 十大安全漏洞和 DoS 攻擊
解決方案：部署對 Kubernetes 友好的且靈活的 WAF 和 DoS 防護解決方案
在為 Kubernetes 應用選擇合適的 WAF 和 DoS 防護解決方案時，有兩個必不可少的考慮因素（除特性外）：
- 靈活性 —— 某些情況下，在 Kubernetes 內部署工具是最好的選擇，這樣工具就可以在 Kubernetes 內外靈活運行，而不會受基礎架構的限制。 通過使用相同的工具支援所有部署，您可以重複使用策略，並降低 SecOps 團隊的學習難度。
- 體量 —— 一款優秀的 Kubernetes 工具通常體量也小，資源消耗恰到好處，能夠最大程度地減少對輸送量、每秒請求和延遲的影響。 DevOps 團隊通常會拒絕使用安全工具，因為他們先入為主地認為這會降低應用速度，而選擇一款小體量的高性能工具無疑會增加使用概率。
一款融合了 WAF 和 DoS 防護的工具看似更有效，實則在 CPU 使用率（由於體量大）和靈活性方面不盡人意，並且即使您不需要，也永遠都是兩個同時部署。 最終，這兩個問題會抬升 Kubernetes 部署的總體擁有成本，同時為其他基本工具和服務帶來預算方面的挑戰。
安全工具不僅要選得好，還要用得好。 企業通常可以在以下四個位置部署應用服務，保護 Kubernetes 應用：
- 前門（在 F5 NGINX Plus 或 F5 BIG‑IP‑ 等負載均衡器上） —— 適用於粗粒度的全域保護，因為它允許您跨多個集群應用全域策略
- 邊緣（在 Ingress controller 上，比如 F5 NGINX Ingress Controller）—— 適用於在一個集群上提供標準的細粒度保護
- service（在 NGINX Plus 等輕量級負載均衡器上）—— 當集群中的少量服務對獨特的策略有著共同需求時，這種方法必不可少
- pod（作為應用的一部分）—— 一種高度自定義的方法，適用於策略具有應用針對性的情形
那麼四個選項中，哪個最好呢？ 這就要視情況而定了。
WAF 的部署位置
WAF 的各個部署選項具有更細微的差別，我們不妨先來看看。
- 前門和邊緣 —— 如果企業更傾向於採用「深度防禦」安全策略，那麼我們建議在外部負載均衡器和 Ingress Controller 上部署 WAF， 以有效平衡全域保護和自定義的保護。
- F前門或邊緣 —— 如果不採用“深度防禦”策略，那麼也可以只部署在二者其一的位置上，具體取決於擁有權。 當傳統 NetOps 團隊負責管理安全性時，他們可能習慣將 WAF 部署在傳統代理（外部負載平衡器）上。 但是，熟悉 Kubernetes 的 DevSecOps 團隊（更喜歡將安全配置放在集群配置附近）可能會選擇在 Ingress Controller 層面上部署 WAF。
- 按服務 service 或按 pod —— 如果您的團隊對服務或應用有著特定的要求，則可以根據需求部署額外的WAF。 但要注意：這些位置的部署成本更高一些。 這種方法不僅會拖慢開發速度並增加雲預算，而且還會提高與故障排除工作相關的運營成本（例如在排查意外攔截流量的 WAF 時）。
DoS 防護工具的部署位置
DoS 攻擊防禦起來更直接一些，只需將工具部署在一個位置即可 —— 要麼在前門，要麼在 Ingress Controller。 如果您在前門和邊緣都部署了 WAF，那麼我們建議您在前門 WAF 的前面部署 DoS 防護工具，因為它的覆蓋面最廣。 如此一來，那些非法流量還沒到達 WAF 就被濾除了，能夠讓您更有效地利用計算資源。
有關這些部署方案的更多資訊，請參閱 《在 Kubernetes 中部署應用服務，第二部分》。
案例：將身份驗證和授權從應用層卸載下來
解決方案：在入口處集中實施身份驗證和授權
身份驗證和授權是應用和服務中一個常見的非功能性要求。 在不需要頻繁更新應用的小規模部署環境中，這種做法雖然會增加一定的複雜性，卻也是可以控制和接受的。 但是在應用發佈速度更快、規模更大的環境中，將身份驗證和授權整合到應用中是行不通的。 讓每個應用維護相應的存取協定可能會讓應用的業務邏輯變得分散甚至被忽視，並導致信息洩露。 雖然 SSO 技術通過一組憑證消除了單獨設置各個使用者名和密碼的需要，提高了安全性，但是開發人員仍然必須在應用中寫入與 SSO 系統交互的代碼。
對此，我們有更好的解決辦法：將身份驗證和授權卸載到 Ingress Controller。
由於 Ingress Controller 可以檢查進入集群的所有流量並將其路由到相應的服務，在這裡集中進行身份驗證和授權是一個明智的選擇。 開發人員不僅可以擺脫構建、維護和複製應用代碼邏輯的麻煩，而且還可以使用原生的 Kubernetes API 在入口層快速地使用 SSO 技術。
有關該主題的更多資訊，請參閱《借助 Okta 和 NGINX Ingress Controller 實現 Kubernetes OpenID Connect 身份驗證》。
案例：設置有「防護欄」的自助服務
解決方案：實施基於角色的存取控制 （RBAC）。
Kubernetes 使用 RBAC 來控制不同類型的使用者可用的資源和操作。 這是一項重要的安全措施，因為它允許管理員或超級用戶確定使用者或使用者組如何與集群中的任何 Kubernetes 物件或特定命名空間進行交互。
Kubernetes RBAC 在預設情況下呈啟用狀態，需要注意的是，您的 Kubernetes 流量管理工具也默認啟用RBAC，能夠與企業的安全需求保持一致。 借助 RBAC，使用者無需提交工單，即可利用受控的許可權存取完成工作所需的功能。 如果不配置 RBAC，使用者可能會獲得他們不需要或無權使用的許可權，而許可權濫用就會導致出現漏洞。
配置好 RBAC 的工具可以為多個人員和團隊提供服務，Ingress Controller 就是一個典型的例子。 通過使用Ingress Controller 進行細粒度的存取管理（甚至細微到一個命名空間），您可以使用 RBAC 以多租戶模式高效利用資源。
例如，以下多個團隊可能會使用 Ingress Controller：
- NetOps 團隊 —— 配置應用的外部入口點（如主機名和 TLS 證書），並將流量控制策略委派給不同的團隊
- DevOps 團隊 A —— 配置 TCP/UDP 負載均衡和路由策略
- DevOps 團隊 B —— 配置速率限制策略，防止服務請求過多
- Identity 團隊 —— 管理身份驗證和授權元件，同時將 mTLS 策略配置為端到端加密策略的一部分
- DevSecOps 團隊 —— 設置 WAF 策略
如欲瞭解如何在 NGINX Ingress Controller 中利用 RBAC，請觀看視頻“使用 GINX Ingress Controller 進行進階Kubernetes 部署“。 從 13：50 開始，我們的專家解釋了如何利用 RBAC 和資源分配實現安全保護、自助服務和多租戶模式。
案例：實現端到端加密
解決方案：使用流量管理工具
在需要處理敏感資訊或個人資訊的企業中，端到端加密 （E2EE） 成為了一個越來越普遍的要求。 無論是財務數據還是社交媒體消息，消費者對隱私保護的期望加之 GDPR 和 HIPAA 等法規的實施都拉升了對這類保護的需求。 實現 E2EE 的第一步是讓您的後端應用在架構上能夠接受 SSL/TLS 流量，或者使用工具將 SSL/TLS 管理從應用上卸載下來（這是分離安全功能、性能、密鑰管理等工作負載的首選方法）。 然後，您再根據環境的複雜性配置流量管理工具。
最常見的方案：使用 Ingress controller 實現 E2EE
當您的應用只有一個端點（簡單的應用或者您直接遷移到 Kubernetes 的單體應用）或沒有服務到服務通信時，您可以在 Kubernetes 內使用 Ingress controller 實現 E2EE。
第一步：確保您的 Ingress controller 只允許使用服務端證書或 mTLS 證書加密的 SSL/TLS 通過，理想情況下出入向流量均如此。
第二步：解決典型的預設設置，讓 Ingress controller 在將流量發送給應用之前必須先解密並重新加密流量。 實現方法有多種，具體取決於您的 Ingress controller 和要求：
- 如果您的 Ingress controller 支援 SSL/TLS 流量直通，那麼它可以根據服務名稱指示 （SNI） 標頭路由SSL/TLS 加密連接（無需解密流量，也不要求存取 SSL/TLS 證書或金鑰）。
- 或者，您可以設置 SSL/TLS 終止，即由 Ingress controller 終止流量，然後將其代理到後端或上游 — 要麼以明文的形式，要麼通過 mTLS 或服務端 SSL/TLS 對 Kubernetes 服務流量重新加密。
不太常見的方案：使用 Ingress controller 和 service mesh 實現 E2EE
如果您的集群中存在服務到服務通信，那麼您需要在兩個平面上實施 E2EE：使用 Ingress controller 處理出入向流量，並使用 service mesh 處理服務到服務流量。 在 E2EE 中，service mesh 的角色是確保只有特定的服務能夠安全地與其他服務通信。 為 E2EE 設置 service mesh 時，您應該通過兩個因素建立零信任環境：服務之間的 mTLS（設置為需要證書）和服務之間的流量存取控制（指定有權通信的服務）。 理想情況下，您還可以在應用之間實施 mTLS（由 service mesh 和出入向流量控制器管理），以便在整個 Kubernetes 集群中實現真正的E2EE 安全性。
有關加密網路通信數據的更多資訊，請參閱《NGINX Service Mesh 中的 mTLS 架構》。
案例：確保用戶端使用可信的強密碼
解決方案：遵守聯邦資訊處理標準 （FIPS）
在軟體行業中，FIPS 通常是指密碼學的專刊 FIPS PUB 140-2《加密模組的安全要求》。 該文件是美國和加拿大合作的產物，為兩國聯邦機構都能接受的加密模組（目的是保護敏感資訊）制定了測試和認證標準。 “等等！ “您可能會說， ”我不在乎 FIPS，我又不與北美政府機構合作。 “不管您處於哪個行業、哪個地區，遵守FIPS 都是明智之舉，因為 FIPS 也是全球加密領域的基準。
遵守 FIPS 並非難事，只是您的操作系統和相關流量管理工具必須也得以 FIPS 模式運行。 人們普遍存在一種誤解，認為只要在 FIPS 模式下運行操作系統就可以實現 FIPS 合規性。 然而即使在 FIPS 模式下運行操作系統，用戶端在與 Ingress controller 的通信時可能也不使用強密碼。 在 FIPS 模式下運行時，您的作業系統和Ingress controller 可以只使用典型 SSL/TLS 密碼套件的一個子集。
您可以按照以下四個步驟為您的 Kubernetes 部署設置 FIPS：
- 第一步：將您的操作系統配置為 FIPS 模式
- 第二步：驗證操作系統和 OpenSSL 是否處於 FIPS 模式
- 第三步：安裝 Ingress controller
- 第四步：執行 FIPS 狀態檢查，驗證是否符合 FIPS 140-2 標準
在下面的示例中，操作系統和 OpenSSL（使用 NGINX Plus 實現）啟用 FIPS 模式後，所有出入 NGINX Plus 的最終使用者流量都使用經過驗證的支援 FIPS 的加密引擎進行瞭解密和加密。