Kubernetes 秘密真的是秘密嗎？

Question

當我開發了一個 API 服務器時，我需要向 API 服務器提供一些帳戶信息，這些信息不應該向任何人顯示。 K8s針對這種情況推薦secret，所以我用了。

但我想知道這個秘密是否真的是秘密。 Secret 只是 base 64“編碼”文本，而不是“加密”文本。

當我看到像下面這樣的任意秘密時，

namespace: ZGVmYXVsdA==

通過解碼我可以很容易地知道它的真正價值。

namespace: default

在這種情況下，秘密真的對安全有幫助嗎？ 我所知道的秘密的安全優勢是它是內存而不是節點文件系統。 但我認為這還不夠安全。

謝謝你。

Answer 1

來自Kubernetes 秘密文檔：

風險

• 在 API 服務器中，secret 數據存儲在 etcd 中（默認情況下，etcd 數據未加密）； 所以：
  1. 管理員應在 rest 為集群數據啟用加密（需要 v1.13 或更高版本）。
  2. 管理員應將 etcd 的訪問權限限制為管理員用戶。
  3. 管理員可能希望在不再使用時擦除/粉碎 etcd 使用的磁盤。
  4. 如果在集群中運行 etcd，管理員應確保使用 SSL/TLS 進行 etcd 對等通信。
• 如果您通過清單（JSON 或 YAML）文件配置密鑰，該文件具有編碼為 base64 的密鑰數據，則共享此文件或將其簽入源存儲庫意味着密鑰已泄露。 Base64 編碼不是一種加密方法，被認為與純文本相同。
• 應用程序在從卷中讀取它后仍然需要保護它的值，例如不意外地記錄它或將其傳輸給不受信任的一方。
• 可以創建使用秘密的 Pod 的用戶也可以看到該秘密的值。 即使 API 服務器策略不允許該用戶讀取 Secret，用戶也可以運行暴露該 Secret 的 Pod。
• 目前，在任何節點上具有 root 權限的任何人都可以通過模擬 kubelet 從 API 服務器讀取任何機密。 這是一個計划的功能，只向實際需要它們的節點發送秘密，以限制根漏洞對單個節點的影響。

另請查看很棒的帖子Kubernetes 可以保密嗎？ 這完全取決於您使用的是什么工具，尤其是“ Kubernetes 普通秘密有什么問題？ ”部分..

我希望這回答了您的問題，但通常@Harsh Manvar 是正確的：您應該首先訪問該秘密。

Answer 2

您應該使用授權策略（例如 RBAC）來限制訪問。

您需要創建一個具有適當權限的Role/ClusterRole ，然后根據您的用例將其綁定（使用RoleBinding/ClusterRoleBinding ）到用戶和/或服務帳戶（然后可以在 pod 定義中使用）。

您可以在此處查看文檔以創建角色和 ClusterRole，並在此處查看用於 RoleBinding 和 ClusterRoleBinding 的文檔。