Kubernetes 你不知道的事
你真的需要 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 文档中提到的漏洞开始。
- 默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储 (etcd) 中。
实际上，秘密数据是 base64 编码的。但是只需要应用反向 base64 即可获得纯数据。 - 任何拥有 API 访问权限的人都可以检索或修改 Secret，任何有权访问 etcd 的人也可以。
- 此外，任何有权在命名空间中创建 Pod 的人都可以使用该访问权限来读取该命名空间中的任何 Secret；这包括间接访问，例如创建 Deployment 的能力。
为了解决这些问题，Kubernetes 推荐了一些实践来保证 Secret 数据的安全。
Kubernetes 文档有什么建议？
为了避免这些陷阱，文档提供了一些建议。
首先，您应该为 Secrets 启用静态加密。
其次，您应该启用或配置限制读取和写入 Secret 的 RBAC 规则。
最后，还应该使用 RBAC 等机制来限制允许哪些主体创建新的 Secret 或替换现有的 Secret。
生产中的 Secret 问题
也就是说，一些问题仍然存在，当我们在生产中考虑它们时，事情就会浮出水面。让我们来看看。
- GitOps 已经控制了我们创建和维护基础设施的方式。因此，如果我们需要创建一个 Secret 来存储敏感数据，我们是否要将其添加到 Ops 存储库中？
如果不这样做，那么用户（开发人员、管理员等）将不得不通过命令式命令来处理这些秘密。如果这样做了，那么就为不同类型的攻击打开了大门。
- 通过同一个 pod 中的容器，可以访问 pod 内的任何秘密。
第 4 个问题是 DevOps 最关注的问题：我们如何在 Kubernetes 集群上提供 Secret 数据，同时遵循 GitOps 最佳实践。
以下是我迄今为止找到的一些替代方案。
1. Hashicorp 保险库：
HashiCorp Vault 是一个基于身份的秘密和加密管理系统。Vault 提供由身份验证和授权方法控制的加密服务。
Vault 的美妙之处在于它是一个开源工具。您可以设置自己的实例并自行管理。也可以依赖他们的云平台。
2. 云提供商 Secret Managers
AWS、GCP 和 Azure 等云提供商提供了 Secret Manager，可以使用它来保护秘密数据的安全并在 Kubernetes 上使用它们。
GCP 有 Google Secret Manager。本教程展示了如何开始在 GKE（Kubernetes For Google）上使用 Google 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 存储库时），但我们必须将它们与更高级的工具和服务结合起来以确保系统安全。
