你真的需要 Secret 对象吗？

很多人认为应该始终使用 Kubernetes Secrets。当开始使用 Kubernetes 时，我认为对 Secret Objects 的需求是显而易见的。

但是经过很短的时间和多个项目的工作后，我开始怀疑在将应用程序部署到生产环境的过程中的实际需求。让我们详细说明。

什么是 Secret

我希望我们首先清楚地了解 Kubernetes 上的 Secret 对象是什么。我认为官方文档给出了明确的定义。

Secret 是一个包含少量敏感数据（例如密码、令牌或密钥）的对象。此类信息可能会以其他方式放入 Pod Spec 或容器镜像中。使用 Secret 意味着您不需要在应用程序代码中包含秘密数据。

让我们看一个 Secret YAML 文件的示例：

apiVersion: v1kind: Secretmetadata:  name: mysecret  namespace: defaulttype: Opaquedata:  username: YWRtaW4=  password: MWYyZDFlMmU2N2Rm

Secret 的特征

Secret 有如下特征：

• 一个 pod 无法访问另一个 pod 的 Secret。

• 如果在该节点上安排了一个 pod 并且需要它，则该节点可以使用 Secret。

• Secret 的最大允许大小只能是 1 MB。这有助于保护 apiserver 内存资源和 kubelet 免受滥用。

• 默认的 View 角色不授予对 Secrets 的访问权限。

这些是 Kubernetes 为提供 Secret 安全基线而实施的一些主要安全机制。

生产 Secret 的硬道理

现在让我们从攻击者的角度来看，事情是怎样的。

让我们从 Kubernetes 文档中提到的漏洞开始。

1. 默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储 (etcd) 中。

   实际上，秘密数据是 base64 编码的。但是只需要应用反向 base64 即可获得纯数据。

2. 任何拥有 API 访问权限的人都可以检索或修改 Secret，任何有权访问 etcd 的人也可以。

3. 此外，任何有权在命名空间中创建 Pod 的人都可以使用该访问权限来读取该命名空间中的任何 Secret；这包括间接访问，例如创建 Deployment 的能力。

为了解决这些问题，Kubernetes 推荐了一些实践来保证 Secret 数据的安全。

Kubernetes 文档有什么建议？

为了避免这些陷阱，文档提供了一些建议。

首先，您应该为 Secrets 启用静态加密。

其次，您应该启用或配置限制读取和写入 Secret 的 RBAC 规则。

最后，还应该使用 RBAC 等机制来限制允许哪些主体创建新的 Secret 或替换现有的 Secret。

生产中的 Secret 问题

也就是说，一些问题仍然存在，当我们在生产中考虑它们时，事情就会浮出水面。让我们来看看。

1. GitOps 已经控制了我们创建和维护基础设施的方式。因此，如果我们需要创建一个 Secret 来存储敏感数据，我们是否要将其添加到 Ops 存储库中？

如果不这样做，那么用户（开发人员、管理员等）将不得不通过命令式命令来处理这些秘密。如果这样做了，那么就为不同类型的攻击打开了大门。

1. 通过同一个 pod 中的容器，可以访问 pod 内的任何秘密。

第 4 个问题是 DevOps 最关注的问题：我们如何在 Kubernetes 集群上提供 Secret 数据，同时遵循 GitOps 最佳实践。

以下是我迄今为止找到的一些替代方案。

1. Hashicorp 保险库：

HashiCorp Vault 是一个基于身份的秘密和加密管理系统。Vault 提供由身份验证和授权方法控制的加密服务。

https://www.vaultproject.io/

Vault 的美妙之处在于它是一个开源工具。您可以设置自己的实例并自行管理。也可以依赖他们的云平台。

2. 云提供商 Secret Managers

AWS、GCP 和 Azure 等云提供商提供了 Secret Manager，可以使用它来保护秘密数据的安全并在 Kubernetes 上使用它们。

GCP 有 Google Secret Manager。本教程展示了如何开始在 GKE（Kubernetes For Google）上使用 Google Secret Manager。

https://cloud.google.com/secret-manager

AWS 提供 AWS Secret Manager，可以利用它来管理您的秘密数据。

https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html

Azure 也是如此，它提出了 Key Vault，可以与 Azure Kubernetes Service 集成。

https://medium.com/swlh/integrate-azure-key-vault-with-azure-kubernetes-service-1a8740429bea

还有很多其他解决方案可以提出相同的服务并更好地解决这些问题。

结论

我们经常说没有一个 100% 安全的系统，但作为 DevOps 和软件工程师，有责任寻找、构建和实施最佳实践，以改进基础设施并为客户提供更安全的系统。

Kubernetes Secret 仍然有用（例如在访问私有 Docker 存储库时），但我们必须将它们与更高级的工具和服务结合起来以确保系统安全。