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 的文档。