DevOps知识中心
DevOps知识中心

Kubernetes集群中管理密钥和敏感数据的最佳实践

了解保护Kubernetes中敏感数据的基本最佳实践。本指南详细说明了为什么默认的Secrets不安全，概述了强制性的静态etcd加密，并探讨了使用Secrets Store CSI驱动程序和外部保险库等高级策略，以最大限度地减少凭证暴露并确保强大的集群安全性。

28 浏览量

Kubernetes集群中管理密钥和敏感数据的最佳实践

Kubernetes是现代云原生应用的基础，它负责自动化部署、扩展和管理。然而，这个强大的编排层需要对安全性给予细致的关注，特别是涉及凭证、API密钥和私有证书等敏感数据时。对这些元素的处理不当可能导致灾难性的数据泄露，即使在其他方面安全可靠的集群架构中也是如此。本文旨在提供一个指南，介绍如何在Kubernetes环境中实施健壮的安全实践来管理Secret和敏感配置数据。

我们将探讨Kubernetes的原生功能、一流的加密策略以及旨在最大限度降低最宝贵资产暴露风险的关键操作模式。

理解Kubernetes Secret：默认机制

Kubernetes引入了专门用于保存敏感信息的Secret对象。虽然它很有用，但了解其在安全性方面的局限性和默认行为至关重要。

默认行为和注意事项

默认情况下，Kubernetes Secret在etcd（集群所有配置数据的后端存储）中未加密存储。它们仅仅是经过Base64编码，这并不提供任何实际的加密。任何有权访问etcd数据存储的人（例如集群管理员、被攻陷的节点）都可以轻松地解码这些值。

警告： 对于高度敏感的数据，切勿仅依赖默认的Kubernetes Secret对象而不应用加密措施。

Base64编码与加密的区别

认为Base64编码能提供安全是一种常见的误解。Base64是一种编码方案，而不是一种加密方案。它很容易被反转：

# 解码Kubernetes Secret值的示例
echo 'c3VwZXItc2VjcmV0Cg==' | base64 -d
# 输出: super-secret

第1层：保护静态存储中的Secret（etcd加密）

保护Secret最基本的一步是确保它们在存储层（etcd）上是加密的。这可以保护数据，即使底层数据库被直接访问。

启用静态加密

静态加密是通过Kubernetes API服务器使用EncryptionConfiguration对象进行配置的。此配置指定应使用哪些提供程序来加密存储在etcd中的各种类型的数据，包括secrets。

加密配置的关键组成部分：

  1. kind: EncryptionConfiguration：声明资源类型。
  2. resources：指定应加密哪些API资源。
  3. providers：定义加密机制。常见的提供程序包括aescbc、aesgcm和KMS提供程序（如AWS KMS或GCP KMS）。

最佳实践： 如果使用静态密钥，请利用像aesgcm这样强大的提供程序，或者最好与仅API服务器可访问的托管密钥管理服务（KMS）集成。

第2层：保护传输中和使用中的Secret

虽然etcd加密解决了“静态存储”问题，但当Secret挂载到Pod中时，它们仍然会被Kubelet解密。我们必须控制这些Secret如何以及在何处出现。

策略1：卷挂载Secret

将Secret数据注入容器的标准方法是将其挂载为卷（通常在容器的文件系统中形成一个文件）。

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/config/db"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: my-sensitive-secret

安全考虑： 如果容器崩溃或生成核心转储文件，Secret文件可能会保留在节点磁盘上。使用readOnly: true并确保容器运行时不留下任何残余物。

策略2：环境变量（不推荐用于高敏感度数据）

虽然方便，但从Secret源化环境变量通常不推荐用于高价值Secret。环境变量很容易通过以下方式泄露：

  • 配置不当的应用程序生成的容器日志。
  • 从容器内部或其他有特权的容器中读取/proc/1/environ。
  • 容器检查工具。

如果必须使用环境变量，则仅将其用于低敏感度的配置数据。

第3层：使用外部Secret存储的高级管理

最安全的模式是将敏感数据完全保留在Kubernetes控制平面（etcd）之外，并使用专业工具在运行时动态检索它们。

使用外部Secret Operator

外部Secret Operator在安全存储在专用保险库（如HashiCorp Vault、AWS Secrets Manager、Azure Key Vault）中的Secret和原生的Kubernetes Secret对象之间架起桥梁。

  1. 存储： 实际的Secret仅存在于外部保险库中。
  2. 同步/注入： Operator监视自定义资源（如ExternalSecret）并从保险库中获取数据。
  3. 创建： 然后Operator在本地创建一个标准的Kubernetes Secret对象，该对象随后可以挂载到Pod中。

优势： 如果Kubernetes集群受到攻击，攻击者仅能访问动态生成、有时效性的本地Secret，而无法访问存储在保险库中的主凭证。

使用Secrets Store CSI Driver

对于需要直接、临时访问而无需在etcd本地存储Secret的应用程序，Secrets Store CSI Driver是更好的选择。

  • 该驱动程序利用提供程序（例如Vault提供程序、Azure提供程序）。
  • 它将Secret直接从外部存储挂载到Pod的文件系统中作为临时卷，无需将Secret数据写入etcd的需要。

通过完全消除etcd数据库中的Secret，这提供了最高级别的安全性。

Secret管理的运维最佳实践

除了技术存储机制之外，运维卫生对于保持安全态势至关重要。

1. 最少权限原则 (PoLP)

确保与Pod关联的服务账户只有读取其所需特定Secret的权限，而不能读取其他Secret。使用基于角色的访问控制（RBAC）来严格限制权限范围。

2. 频繁轮换Secret

为所有凭证实施自动轮换计划。长期存在的Secret会增加被泄露的机会窗口。与外部保险库集成的工具通常会自动处理这种轮换。

3. 审计和监控访问

配置审计日志以跟踪谁读取或修改了Secret对象。与外部保险库集成的工具（如Vault Agents或CSI驱动程序）也应记录对外部存储的访问尝试。

4. 绝不将Secret提交到Git

这是一个基本规则。绝不要将原始的或甚至经过Base64编码的Secret存储在Git仓库中，即使是私有的。使用git-secrets等工具或结合外部Secret注入机制的配置管理模板工具（如Helm或Kustomize）来管理部署清单。

使用Kustomize的示例（外部引用）：

在使用模板时，您可以在清单文件中使用占位符，并依赖构建步骤或CI/CD管道来从保险库中安全检索实际的Secret值，然后再将YAML应用到集群中。

管理策略摘要表

策略 安全级别 是否暴露给etcd 复杂性 最佳用途
默认K8s Secret（无etcd加密） 非常低 是（明文） 低 仅用于临时测试
带有etcd加密的K8s Secret 中等 是（加密） 中等 一般配置数据
外部Secret Operator 高 是（Operator管理的Secret） 高 统一Secret管理
Secrets Store CSI Driver 最高 否（直接挂载） 高 高度敏感的凭证和令牌

通过采用分层方法——从etcd加密开始，并通过使用现代CSI驱动程序转向外部保险库集成——组织可以显著加强其Kubernetes集群，防止Secret暴露。