本文介绍了多种加密 Kubernetes Secrets 的方法，作为保护集群敏感数据的关键措施。原文: ☸️ How to Encrypt Kubernetes Secrets
你可能已经听说过好几次这个不算秘密的秘密了：Kubernetes Secrets 是不加密的！实际上 Secret 的值是一个存储在 etcd 中的 base64 编码字符串。
这意味着任何可以访问集群的人都可以轻松解码敏感数据，尤其是在集群 RBAC 设置不正确的情况下，几乎任何人都可以访问 API 或访问 etcd。
任何人都有可能被授权在命名空间中创建 pod 或进行部署，然后通过该权限检索命名空间中的所有 Secrets。如何确保集群的 Secrets 和其他敏感信息（如令牌）不被泄露？本文将讨论在 K8S 上构建、部署和运行应用程序时加密 Secrets 的几种方法。
K8S 的 Secrets
在 Kubernetes 集群上运行的应用程序可以使用 Kubernetes Secrets，从而无需在应用程序代码中存储令牌或密码等敏感数据。
当前 Kubernetes 集群中默认的 Secrets 典型工作流程如下：
- 开发阶段：使用 CICD 的应用程序开发人员将 git 作为管理部署到集群的配置的真实来源。访问控制有助于确保对资源库的访问安全，但这本身并不总能确保应用程序的敏感信息不被暴露。
- 运行阶段：API 服务器在集群上创建 Kubernetes Secrets 资源。可以查看 Kubernetes 官方文档获取有关 Secrets 生命周期的更多信息。应用 pod 可以通过三种方式使用存储在 etcd 中的 Secrets：
- 作为卷挂载在一个或多个容器中的文件
- 作为容器环境变量
- kubelet 在拉取 pod 镜像时使用
这三种情况都会在使用前解码密文中的值。
现在我们知道了它的工作原理，那为什么只对密文进行 base64 编码还不够呢？
为什么 Base64 编码不被视为加密文本？
Base64 编码是一种二进制到文本的编码方案，它将 24 位二进制数据表示为 6 位 base64 数字，可用于在网络上传输大量数据，尤其是图片等大型文件。主要功能是在网络传输过程中提供数据完整性。需要明确的是，编码并不是加密。
尝试在任意 Linux 终端上执行：
$ echo -n 'not encrypted' | base64 bm90IGVuY3J5cHRlZA== $ echo -n 'bm90IGVuY3J5cHRlZA==' | base64 --decode not encrypted SHELL
如上所述，任何人只要能访问你的系统，无论是在传递还是在使用 Secrets，都能轻松将其解码。
问题来了
作为 DevSecOps 管理员，显然面临两个挑战：
- 如何在集群外部（即在构建和部署阶段，并且在进入集群之前）加密和管理敏感数据？
- 在集群内运行应用程序时，如何确保敏感数据安全？
以下是加密 K8S Secrets 的几个选项。
作为将代码推送到 git 仓库的开发人员，可以在将代码推送到 git 仓库之前对应用程序使用的敏感信息进行加密。
以下是两种在 Secrets 提交到 git 仓库并部署到 OpenShift 集群之前进行加密的常用方法：
Bitnami 封装的 Secrets 简介
Bitnami Sealed Secrets：Kubernetes 的 "加密 Secrets"。
典型使用场景：
遇到的问题："我可以在 git 中管理所有 K8S 配置，但 Secrets 除外"。
解决方案：将 Secret 加密为 SealedSecret，并将其安全的存储在公共存储库中。只有在目标集群中运行的控制器才能解密 SealedSecret，其他人（即使是原作者）也无法从 SealedSecret 中获取原始 Secret。
Bitnami Sealed Secrets 使用流程
使用 Bitnami Sealed Secrets 的工作流程示例如下：
- 集群管理员在 K8s 集群中部署 SealedSecret 控制器。
- 开发人员需要在本地计算机上安装
kubesealCLI。 - 开发者创建 Secret 资源，然后
kubesealCLI 在运行时从控制器获取密钥，对资源进行加密或封装。对于网络受限的环境，公钥也可以存储在本地并由kubeseal使用。 - Kubeseal 将创建
SealedSecret自定义资源。 - 开发人员将此自定义资源推送至 git 仓库。
- 可使用 ArgoCD 等 CD 工具在集群上部署自定义资源。
- 控制器将检测 SealedSecret 资源，并使用集群上的私钥对其进行解密。
使用 KSOPS / Mozilla SOPS
KSOPS/Mozilla SOPS 简介
- Mozilla SOPS - sops 是一款加密文件编辑器，支持 YAML、JSON、ENV、INI 和 BINARY 格式，并使用 AWS KMS、GCP KMS、Azure Key Vault、age 和 PGP 进行加密。
- KSOPS - 用于 SOPS 加密资源的 Kustomize 插件。
KSOPS/Mozilla SOPS 使用流程
如果使用 Argo CD 在 Kubernetes 中部署应用程序，可以使用 Kustomize SOPS 插件，该插件用于解密使用 SOPS 加密的资源。
管理员在集群上：
- 部署 ArgoCD
- 使用 age 生成密钥
- 创建一个可将公钥和私钥存储在特定命名空间中的密钥
- 定制 Argo CD 以使用 Kustomize SOPS 插件
- 将公钥推送到 Git 仓库
开发人员将：
- 在本地控制台创建 Secret
- 使用 SOPS CLI 下载公钥并加密密文
- 使用加密的 Secret 生成 KSOPS yaml 并将其推送到 Git 仓库
ArgoCD 在集群上部署 Secret 之前，会使用 KSOPS 对加密文件进行解密。
上述两种方法都适用于使用非对称加密技术加密 Secret 文件。在敏感数据作为 Secret 部署到集群之前，这两种方法都提供了解密敏感数据的方法。
SealedSecrets 与 Kubernetes 原生集成。SOPS / KSOPS 可以独立工作，不需要额外的集群控制器。此外，SealedSecrets 使用 AES-256-GCM 等强加密技术，而 SOPS 使用 gpg 和 age。SOPS 提供与云提供商 KMS 的集成，而 SealedSecrets 还没有，但计划在未来集成（参考：https://github.com/bitnami-labs/sealed-secrets/issues/779）。
SOPS 不仅可以对 Secrets 的值进行加密，还支持对 yaml、json、环境变量和二进制值进行加密，因此也可用于对 helm charts 进行加密。
不过，如你所见，加密数据一旦进入集群，就会在使用前解密。因此，上述方法只能解决部分问题。接下来，我们需要看看如何在集群中保护数据安全，看看在集群中加密数据的不同选项。
用于 K8S 的 etcd 加密选项
默认情况下，K8S 容器平台不会加密 etcd 数据。但原生 K8S 和某些 K8S 发行版提供了启用基于 etcd 加密的选项。
以下是相关参考文档：
- 原生 K8S：对静态机密数据进行加密 | Kubernetes
- OpenShift：加密 etcd 数据 | 安全性与合规性 | OpenShift 容器平台 4.13
- K3S：Secret 加密 | K3s
使用 KMS 驱动进行数据加密
除上述 etcd（静态）加密方案外，原生 K8S 和某些 K8S 发行版还提供基于 KMS 驱动的（动态）数据加密方案。
以下是相关参考文档：
- 原生 K8S：使用 KMS 驱动进行数据加密｜Kubernetes
- GKE：在应用层加密 Secret | Google Kubernetes Engine (GKE) | Google Cloud
- Amazon EKS：在现有群集上启用 Secret 加密 - Amazon EKS
公共云/私有云/数据中心磁盘加密选项
在 K8S 中使用 EBS 的公有云/私有云/数据中心节点级加密可以提供额外的加密层。我们以公有云为例：
- 加密卷内的静态数据
- 在卷和实例之间移动的所有数据
- 从加密卷创建的所有快照
- 根据这些快照创建的所有卷
- Azure 密钥库为连接到 Azure Key Vault 的 Azure 托管磁盘提供加密选项
- Google 为 Google Cloud Storage 提供加密选项。两者默认都使用 AES 256 密钥，但也可以使用客户管理和提供的密钥，并与 KMS 集成。
集成第三方 Secrets 存储
选择第三方 Secrets 存储的一个重要原因是确保通过集中式 Secrets 存储解决方案在群集外管理 Secrets 生命周期。这些 Secrets 存储提供的身份验证和授权策略及程序与群集上的不同，可能更适合控制应用程序数据访问。
这些解决方案大多还提供监管机构要求的封装加密和 HSM 支持。流行的解决方案包括 HashiCorp Vault、CyberArk Conjur、AWS Secret Store、Azure Key Vault、Google Secret Manager、1Password 等。
Sidecar 解决方案
Vault 等解决方案可用于注入应用程序 pod 的特定 Secrets。在这种情况下，sidecar/init 容器负责向 Secret 提供者进行身份验证，然后应用可以在必要时使用返回的 Secret。底层通过 TLS 与提供者进行连接，以确保 Secret 检索的安全性。
选择这些解决方案的客户可以决定在集群上或集群外存储 Secret。通常情况下，如果客户一直使用 Vault 以满足其基础架构和其他应用需求，会倾向于与这些解决方案集成，以便在 K8S 上获得无缝的 Secret 管理体验。
Secrets Storage CSI (SSCSI) 驱动和供应商解决方案
Secrets Store CSI 驱动允许将 Secrets 和其他敏感信息作为卷挂载到应用程序 pod 中。Secrets Store CSI 驱动使用 gRPC 与供应商通信，以便从 SecretProviderClass 自定义资源中指定的外部 Secrets Store 中检索 Secrets 内容。一旦卷被加载，其中的数据就会加载到容器文件系统中。
与从特定供应商获取 Secret 内容的上述 sidecar 解决方案不同，SSCSI 驱动可以配置为从多个不同的 Secret 供应商获取 Secret 内容。有关驱动和供应商程序工作原理的更多信息，请参阅官方文档。
不想在 etcd 中存储 Kubernetes Secret 的客户会选择 SSCSI，原因如下：
- 客户可能有严格的合规性要求，因此有必要在中央存储区而不是集群中存储和管理 Secret。
- 客户可能会将工作负载引入不在他们管理之下的控制平面环境中，因此希望完全控制工作负载的保密性，而不相信平台管理员能做到这一点。例如，客户将工作负载引入托管提供商集群的租户，或引入控制平面不由其管理的云平台。
SSCSI 驱动并不直接提供保护非卷标 Secret 的方法，例如那些需要作为环境变量或镜像提取的 Secret，以及那些可能直接在集群上创建以管理入口证书的 Secret。不过，可以使用同步秘钥功能，该功能会创建 Kubernetes 秘钥，然后为作为环境变量秘钥提供支持。
外部 Secrets 操作员（ESO，External Secrets Operator）
外部 Secrets 操作员（ESO）是一种用户友好型解决方案，用于将外部 Secrets 管理解决方案中的 Secret 同步到 Kubernetes Secrets 中。ESO 作为部署资源在 Kubernetes 集群中运行，使用自定义资源定义（CRD）通过 SecretStore 资源配置访问 Secret 供应商，并使用 ExternalSecret 资源管理 Kubernetes Secret 资源。
客户在以下情况下会选择ESO：
- 客户需要与平台轻松集成，并便于开发人员使用。
- 客户高度信任集群控制平面，尤其是 etcd 的加密配置方式或集群的 RBAC 管理方式。
- 客户有多集群 Secret 管理用例，需要跨集群集成 Secret。
- 客户需要将管理平台 Secret 用于非应用程序，例如用于 Ingress、自动化和镜像拉取的 Secret。
- 需要在集群上修改 Secret，并为特定应用程序提供模板。
- 最后，也是最重要的一点是，客户的用例需要在集群上访问 Secret。
本文介绍了 K8S 提供的各种加密选项，以及每种选项如何保护敏感数据，以便你可以根据自己的实际情况做出明智选择。
以下是一些个人建议，仅供参考：
- 如果主要使用 AWS，可以根据安全级别选择 EBS 加密或 KMS 加密。
- 如果在数据中心使用 K8S，且需要管理 K8S 集群之外的 Secrets，建议使用 Hashicorp Vault。
- 如果在数据中心使用 K8S，且只需要 K8S Secrets 加密，则可以考虑使用 etcd 静态加密和 ESO。
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！
本文由mdnice多平台发布
