螞蟻是如何改進 K8s 集羣敏感信息的安全防禦的？

在 Kubernetes 中，Secret 顯得尤爲重要。由於它是 K8s 中存儲全部敏感信息的對象。據悉，這些敏感信息包含密碼、集羣的證書、OAuth token、ssh key 以及其餘用戶自定義的敏感文件等。所以，一旦 K8s 中 Secret 出現安全問題，後果將很是嚴重。此外，雖然社區提供了必定的安全防禦方案，可是依然存在諸多問題。

K8s Secret 面臨着哪些安全問題？這些安全問題會帶來什麼影響？社區提供的解決方案存在哪些不足？......針對這些問題，InfoQ 記者採訪了螞蟻集團高級工程師秦凱倫，他專一於可信計算、系統安全和虛擬化等領域，對 K8s Secret 有着深刻的研究和探索。

K8s Secret 的安全問題

根據 Kubernetes 文檔，Secret 是 K8s 中存儲全部敏感信息的對象。事實上，若是敏感信息直接存放於 K8s 的 Pod spec 或鏡像中，不只管控困難，並且存在較大的安全隱患。所以，K8s 經過建立、管理、應用 Secret 對象，能夠更好地控制敏感信息的用途，並下降其意外暴露的風險。

秦凱倫稱，雖然引入 K8s Secret 對象，這在必定程度上下降了意外泄露的風險（更多地是經過集中式的管理），可是 K8s Secret 對象自身的安全性，「社區默認方案中仍存在許多安全問題」。

通常來講，K8s 中，Secret 數據以純文本的方式存儲在 etcd 中，默認只有 base64 編碼，未經加密。同時，共享該文件或將其檢入代碼庫，密碼容易泄露。

社區解決方案的不足

針對此問題，K8s 社區提供了基於 KMS 的 K8s Secret 加密方案，谷歌雲、AWS 和 Azure 均支持該方案。他說，「這雖然解決了 etcd 中 Secret 明文存儲問題，但依然有一些問題。」

• Secret、加密 Secret 的密鑰在內存中明文存放、易被攻破；
• 攻擊者能夠假冒合法用戶，調用解密接口，竊取密鑰；

密鑰一旦泄露，將致使全部數據的泄露，從而引發用戶對整個系統的信任崩潰。「爲此，社區和一些公司嘗試爲該方案中的 Plugin 加上基於硬件的安全保護，從而提高攻擊難度。但對某些特定用戶來講，保護的覆蓋面和程度依然不夠」。

實際上，咱們能夠從 K8s Secret 的整個生命週期來看：

• Secret 的生成及訪問 Secret 的身份證書明文存放在用戶側內存中，用戶側環境複雜，容易被攻擊者攻破；
• 加密 Secret 的密鑰的生成、cache 等在 K8s API server 中明文存放在內存中，安全根易被竊取或破壞；
• 與 KMS 交互的 Plugin 的加解密接口沒法防止攻擊者假冒，存在泄漏風險；
• Secret 在 Node 中消費，依然明文內存存放，暴露出必定攻擊面；

在秦凱倫看來，理想中，對 K8s 中 Secret 的保護程度應該考慮其整個生命週期的安全、可信，作到端到端的安全防禦。

螞蟻集團的探索

爲此，他們基於 TEE 技術，將 K8s Secret 整個生命週期和端到端使用過程當中的關鍵組件、步驟保護起來。總體方案大體以下：

• 將 API Server 端與 KMS 交互的 KMS Plugin  用 TEE 保護，在保障了 Plugin 中根密鑰（安全根）、數據加密密鑰無泄漏風險的前提下，下降了性能開銷；
• 將 API Server 端的 KMS provider 用 TEE 保護，避免數據密鑰及 Secret 在任什麼時候候明文直接暴露在內存中；同時，經過 TEE 的本地證實機制可以認證解密數據密鑰接口的調用者，防止攻擊者假冒，確保密鑰的安全；
• 將用戶端的 kubectl、kubeconfig 等使用 TEE 保護，一方面 kubeconfig 不落盤同時被硬件保護，提高了安全水位；另外一方面，用戶的 Secret 經過安全信道直通到 TEE 中進行處理，避免了直接暴露在內存中，規避了被惡意竊取的風險，且用戶對 API Server 進行 TEE 遠程證實，能夠幫助用戶確信他正在把本身的 Secret 託付給可信的軟件實體（沒有含有故意泄露用戶祕密的惡意邏輯），創建對 API Server 的信任；
• 將 Node 端的 kubelet 中 Secret 的消費過程用 TEE 保護，進一步避免了 Secret直接暴露在內存中，規避了被惡意竊取的風險；

秦凱倫向 InfoQ 記者指出，「這種方案是基於 TEE 的端到端 K8s Secret 保護，還引入 LibOS 技術，實現 TEE 保護對用戶、開發者和運維團隊徹底透明。」

據悉，KMS Plugin 和 TEE-based KMS Plugin 沒有標準和開源的社區實現，所以他們設計並開發了本身的 KMS Plugin，並在灰度發佈、應急處理、監控管理等方面進行了生產加強。「在與 TEE 結合的過程當中，咱們爲了應對 SGX 機型存在的性能問題，提供了 standalone 和服務化 KMS Plugin 兩套方案」。

一樣，TEE-based kubectl 也沒有標準和開源的社區實現，他說：「咱們基於 kubeproxy 開發了本身的安全 kubectl，實現了 kubeconfig 對用戶透明、與用戶身份綁定、不落盤並採用TEE保護內存安全等設計目標。」

此外，考慮到 TEE 保護的易用性、可靠性、可擴展性和可維護性等，他們在評估多套方案後，引入了由螞蟻開源的 Occlum LibOS，屏蔽了 TEE 對用戶、開發者和運維團隊的影響，大大下降了 TEE 開發的門檻和成本。

在秦凱倫看來，K8s 做爲螞蟻大規模容器集羣的管控根基，應用基於 TEE 的端到端 K8s Secret 保護防禦方案，加強了其自身安全和可信，提高了螞蟻核心管控平面的安全水位，「這對於金融場景下高標準的數據安全和隱私保護來講不可或缺」。

K8s 相關閱讀

• 備戰雙 11！螞蟻金服萬級規模 K8s 集羣管理系統如何設計？
• Kubernetes: 微內核的分佈式操做系統
• 開箱即用的 Java Kubernetes Operator 運行時
• 深刻Kubernetes 的「無人區」 — 螞蟻金服雙十一的調度系統
• 深度 | 螞蟻金服自動化運維大規模 Kubernetes 集羣的實踐之路