在 K8s 中，Secret 非常重要。因為它是 K8s 中存儲所有敏感信息的對象。據悉，這些敏感信息包含密碼、集群的證書、OAuth token、ssh key 以及其他用戶自定義的敏感文件等。因此，一旦 K8s 中 Secret 出現安全問題，后果將非常嚴重。此外，雖然社區提供了一定的安全防護方案，但是依然存在諸多問題。

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

K8s Secret 的安全問題

根據 K8ss 文檔，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 保護防護方案，增強了其自身安全和可信，提升了螞蟻核心管控平面的安全水位，“這對于金融場景下高標準的數據安全和隱私保護來說不可或缺”。