Kubernetes 使用秘密管理器进行秘密加密和使用与静态加密。秘密管理器真的安全吗？

Question

我正在研究 Kubernetes 安全性，并且正在研究在 pod 中加密和使用 Secrets 值的各种方法，但我认为我没有掌握一些关键概念。 据我了解，从集群安全的角度来看，加密机密应该避免在集群攻击的情况下，攻击者仅通过简单的 Base64 解码机密值就无法获取 api 密钥、访问令牌、用户名和密码。

我正在将 Vault 和 Sealed Secrets 等秘密管理器的使用与启用静态加密进行比较。

我发现，通过实施 Vault + Vault Secrets Operator、Vault + external Secrets 或 Sealed Secrets，普通的 Secret 是从加密的 Secret 中生成的，并放置在集群中。

来自 Vault Secrets Operator GitHub

Operator 将源 Vault Secret 数据直接写入目标 Kubernetes Secret，确保在其生命周期内对源所做的任何更改都会复制到目标。这样，应用程序只需要访问目标 Secret 即可利用其中包含的秘密数据。

来自 Seal Secret GitHub 我看到他们的 Sealed Secret 自定义资源将转换为普通的 Kubernetes Secret..

这个正常的 kubernetes 密钥将在几秒钟后出现在集群中，您可以像使用直接创建的任何密钥一样使用它（例如，从 Pod 引用它）。

另一方面，静态加密实际上会在创建时对秘密进行加密，但您还需要配置 RBAC 规则，或者使用第三方 KMS 提供商（例如 Azure Key Vaults）的信封加密。

这三种方法的实现几乎同样复杂，例如 Vault 需要大量手动配置来解封和创建加密机密，但只有静态加密才能真正保护敏感数据免受集群攻击，因为机密实际上是在以下情况下加密和解密的：从 pod 中使用。

考虑到上述考虑，Vault 和 Sealed Secret 有什么用处？如果 Secret 最终以未加密的方式存在，那么费尽心思去设置它们还有什么意义呢？

Answer 1

将 Secret 添加到集群中可能是一个挑战。您可以使用 Kubernetes RBAC 来限制 Secret 的可见性，这可能有助于解决一些安全问题。

我建议这里有三个基本级别：

1. Kubernetes 中根本不存在秘密值，但应用程序直接与 Vault 或类似服务集成。 （最难设置和运行，尤其是在非生产环境中。）

2. Kubernetes Secret 存在，但它们由操作员或集成填充。

3. Kubernetes Secret 是在部署时通过

   kubectl apply

   或 Helm 创建的。

如果秘密确实存在，正如您所注意到的，那么获得它的值是相当简单的。

kubectl get secret

将拥有除纯文本之外的所有内容，

kubectl exec

可以在正在运行的 Pod 中找到它，如果您可以

kubectl run

一个新 Pod 或创建任何工作负载类型资源，那么您可以将 Secret 挂载到新的 Pod 中。 Pod 并打印出它的值。这是将应用程序直接绑定到秘密存储中的一个论点，但这是一个更复杂的设置。

假设您没有硬连接到 Vault，并且需要提供数据库密码作为环境变量。它实际上住在哪里；当您部署应用程序时，它是如何设置的？一种选择是将密码放入 CI 系统的凭证存储中，但这是一个非常“泄漏”的选项 – CI 脚本和链上的每一步都可以看到秘密，并且您需要 CI 系统的管理员来创建或修改数值。

这就是各种秘密管理器工具的用武之地。Sealed Secrets 允许您将加密的秘密文件提交到源代码管理，因此您无需与 CI 系统协调来创建或更新凭证。外部密钥从 Vault 或 AWS Secrets Manager 等系统创建密钥。 Vault 拥有相当丰富的访问控制系统，因此这使得用户可以创建秘密并列出现有秘密，但不能直接检索秘密值（至少在 Kubernetes 之外不行）。

因此，如果您通过 CI 系统安装密钥：

credential (only CI admins can update)
    v
CI system --> helm install --> Secret object --> container --> application
    ^              ^                 ^               ^              ^
    credential is visible everywhere

如果您让 Sealed Secrets 或External Secrets 等操作员创建 Secret 对象：

                secret store --> operator
                                     v
CI system --> helm install --> Secret object --> container --> application
                                     ^               ^              ^
                                  Kubernetes operations can get credential

如果您将应用程序代码更改为直接连接到秘密存储（Vault、AWS Secrets Manager...）：

                                                              secret store
                                                                    ^
CI system --> helm install --> Secret object --> container --> application
                                                                    ^
                           credential only visible inside application code
                                  requires wiring specific to secret store