关于运维:加密-K8s-Secrets-的几种方案

前言

你可能曾经听过很多遍这个不算机密的机密了 –Kubernetes Secrets 不是加密的！Secret 的值是存储在 etcd 中的 base64 encoded（编码）字符串。这意味着，任何能够拜访你的集群的人，都能够轻松解码你的敏感数据。任何人？是的，简直任何人都能够，尤其是在集群的 RBAC 设置不正确的状况下。任何人都能够拜访 API 或拜访 etcd。也可能是任何被受权在 Namespace 中创立 pod 或 Deploy，而后应用该权限检索该 Namespace 中所有 Secrets 的人。如何确保集群上的 Secrets 和其余敏感信息（如 token）不被泄露？在本篇博文中，咱们将探讨在 K8s 上构建、部署和运行应用程序时加密应用程序 Secrets 的几种办法。

K8s 的 Secrets

在 Kubernetes 集群上运行的应用程序能够应用 Kubernetes Secrets，这样就无需在利用程序代码中存储 token 或明码等敏感数据。

以后默认 Kubernetes 集群内 Secrets 的典型工作流程如下：

1. Dev 阶段：应用 CICD 的应用程序开发人员将 git 作为治理部署到集群的配置的实在起源。访问控制有助于确保对该资源库的拜访平安，但这自身并不总能确保应用程序的敏感信息不被泄露。

2. Ops 阶段：API 服务器会在集群上创立 Kubernetes Secrets 资源，你能够在这里 这里 浏览无关 Secrets 生命周期的更多信息。存储在 etcd 中的 Secrets 可由应用程序 pod 以三种形式之一应用：

   1. 作为一个或多个容器的 卷挂载 中的文件。
   2. 作为容器 环境变量。
   3. 由 Pod 的 kubelet 在拉取镜像时应用。

在这三种状况下，密文中的值在应用前都会被解码 (decode)。

那么，既然咱们晓得了它的工作原理，为什么只对密文进行 base64 编码还不够呢？

Base64 编码为什么不算密文？

Base64 编码是一种二进制到文本的编码方案，它将 24 位二进制数据表示为 6 位 base64 数字。它用于在网络上传输大量数据，尤其是图像文件等大型文件。它的次要性能是 在数据通过网络传输时提供数据的完整性。要明确，编码 (encode) 并不是加密 (encrypt)。

在任何 Linux 终端上试试这个。

$ echo -n 'not encrypted' | base64
bm90IGVuY3J5cHRlZA==

$ echo -n 'bm90IGVuY3J5cHRlZA==' | base64 --decode
not encrypted

如上，无论是在将 Secrets 传输到群集时，还是在群集上应用时，任何能够拜访你零碎的人都能够轻松解码你的 Secrets。

问题来了

作为 DevSecOps 管理员，您显然面临着两个挑战：

1. 如何加密和治理集群外的敏感数据，即在构建和部署阶段进入集群之前？
2. 如何在集群内运行应用程序时爱护敏感数据的平安？

以下是加密 K8s Secrets 的几种计划。

在部署到群集之前对秘密进行加密

作为将代码推送到 git 仓库（又称应用程序的 “ 假相源 ”）的开发人员，您能够在将代码推送到 git 仓库之前对应用程序应用的敏感信息进行加密。上面将介绍两种常见的办法，用于在秘密提交到 git 仓库并部署到 OpenShift 集群之前对其进行加密：

应用 Bitnami Sealed Secrets

Bitnami Sealed Secrets 简介

Bitnami Sealed Secrets: Kubernetes 的“加密的 Secrets”.

典型应用场景：

遇到的问题 ：“我能够在 git 中治理我所有的 K8s 配置，除了 Secrets。”
解决方案：将您的 Secret 加密到 SealedSecret 中，即便在公共存储库中也能够平安存储。SealedSecret 只能由指标集群中运行的控制器解密，其他人（甚至原始作者）无奈从 SealedSecret 中取得原始 Secret。

Bitnami Sealed Secrets 应用流程

应用 Bitnami Sealed Secrets 的工作流程示例如下：

1. 集群管理员在 K8s 集群上部署 Sealed secrets 控制器
2. 开发者须要在本地计算机上安装 kubeseal CLI。
3. 开发者创立一个 Secret 资源，而后由 kubeseal CLI 在运行时从控制器中获取密钥，对该资源进行加密或密封。对于网络受限的环境，公钥也能够存储在本地并由 kubeseal 应用。Kubeseal 将创立一个 SealedSecret 自定义资源。
4. 开发者将此 CR 推送到本人的 git 仓库中
5. 可应用 ArgoCD 等 CD 工具在集群上部署 CR。
6. 控制器将检测到 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 加密的资源。

在集群上，管理员将：

1. 部署 ArgoCD
2. 应用 age 生成密钥
3. 在 特定（如 GitOps) Namespace 中创立存储公钥和私钥的密钥
4. 定制 Argo CD 以应用 Kustomize SOPS 插件
5. 将公钥推送到 Git 仓库

开发人员将：

1. 在本地控制台创立 Secret
2. 应用 SOPS CLI 下载公钥并加密密文
3. 用加密后的 Secrets 生成 KSOPS yaml 并推送到 Git 仓库

ArgoCD 在集群上部署 Secrets 之前，会应用 KSOPS 对机密文件进行解密。

小结

下面这两种办法都实用于应用非对称加密技术对机密文件进行加密。两者都提供了在敏感数据作为 Secrets 部署到集群之前对其进行解密的办法。Sealed secrets 与 Kubernetes 原生集成。SOPS / KSOPS 能够独立工作，不须要集群上的控制器。另外，Sealed secrets 应用 AES-256-GCM 等强 crypto，而 SOPS 应用 gpg 和 age。SOPS 提供与云提供商 KMS 的集成，而 SealedSecrets 目前还没有，但打算在将来实现集成（参见 这里）。SOPS 不只能够对 Secrets 的值加密，还反对 yaml、json、env var 和二进制值加密，因而也可用于加密 helm chart。

不过，正如你所看到的，加密的数据一旦进入集群，就会在应用前被解密。因而，这基本上只解决了局部问题。接下来，咱们须要看看如何在群集中爱护这些数据的平安。让咱们看看在集群上加密数据的不同选项。

加密 K8s 群集上的 Secrets

K8s 的 etcd 加密选项

默认状况下，K8s 容器平台不对 etcd 数据进行加密。然而原生 K8s, 以及一些 K8s 发行版，提供了启用基于 etcd 的加密选项。

以下是相干的一些参考文档：

1. 原生 K8s: 动态加密秘密数据 | Kubernetes
2. OpenShift: Encrypting etcd data | Security and compliance | OpenShift Container Platform 4.13
3. K3s: Secret 加密 | K3s

读者能够进一步浏览以理解详情。

应用 KMS 驱动进行数据加密

除了下面 etcd 的（动态）加密计划之外，原生 K8s 和一些 K8s 发行版也提供了基于 KMS 驱动进行（动静）数据加密的计划。

以下是相干的一些参考文档：

1. 原生 K8s: 应用 KMS 驱动进行数据加密 | Kubernetes
2. GKE: 在应用层对 Secret 加密 | Google Kubernetes Engine (GKE) | Google Cloud
3. Amazon EKS: Enabling secret encryption on an existing cluster – Amazon EKS
4. 应用阿里云 KMS 进行 Secret 的落盘加密 (alibabacloud.com)

私有云 / 公有云 / 数据中心磁盘加密选项

在 K8s 中应用 EBS 的私有云 / 公有云 / 数据中心节点级加密能够提供额定的加密层。这里以私有云为例阐明：

1. AWS: 在 AWS 上托管 K8s 群集时，能够启用 Amazon EBS 加密，为 EC2 实例提供加密。Amazon EBS 加密在创立加密卷和快照时应用 AWS KMS 密钥。它应用 AES-256-XTS 进行块明码加密。创立加密 EBS 卷并将其附加到反对的实例类型时，以下类型的数据将被加密：

   • 加密卷内的静态数据
   • 卷和实例之间挪动的所有数据
   • 从加密卷创立的所有快照
   • 从这些快照创立的所有卷
2. Azure: 为连贯到 Azure Key Vault 的 Azure Managed Disks 提供加密选项
3. Google 为 Google Cloud Storage 提供加密选项。两者默认都应用 AES 256 密钥，但也能够应用客户治理和提供的密钥，并与 KMS 集成。

应用第三方 Secrets 存储集成的 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 Provider 进行身份验证，而后应用程序能够在必要时应用返回的 Secrets。与 Provider 的连贯是通过 TLS 进行的，以确保 Secrets 检索的安全性。Vault 通过应用 响应封装 提供额定的安全性，这使您能够在中间人无奈看到凭证的状况下传递凭证。抉择这些解决方案的客户能够决定将秘密存储在集群上或集群外。通常状况下，如果客户始终应用 Vault 来满足其基础架构和其余利用需要，他们会偏向于与这些解决方案集成，以便在 K8s 上取得无缝的秘密治理体验。

Secrets 存储 CSI（SSCSI）驱动程序和提供商解决方案

Secrets Store CSI 驱动程序容许将 Secrets 和其余敏感信息作为卷挂载到应用程序 pod 中。Secrets Store CSI 驱动程序应用 gRPC 与提供程序通信，以便从 SecretProviderClass 自定义资源中指定的内部 Secrets Store 中检索 Secrets 内容。一旦连贯了卷，其中的数据就会加载到容器的文件系统中。与上述从特定提供商引入 Secrets 内容的 sidecar 解决方案不同，SSCSI 驱动程序能够配置为从多个不同的 Secret Provider 检索 Secrets 内容。无关驱动程序和提供商如何工作的更多信息，请参阅 此处。

不心愿将机密存储在 etcd 中作为 Kubernetes 机密的客户次要会抉择 SSCSI，起因如下

• 他们可能有严格的合规性要求，因而有必要仅在地方存储区而非集群中存储和治理秘密。
• 他们可能会在管制立体不禁他们治理的环境中引入工作负载，因而他们心愿齐全管制工作负载的秘密，而不置信平台管理员能做到这一点。例如，客户将工作负载引入托管服务提供商集群的租户中，或者将工作负载引入管制立体不禁其治理的云平台中。

SSCSI 驱动程序并不间接提供爱护非卷标挂载秘密的办法，例如那些须要作为环境变量或镜像拉取秘密的 Secrets，或者那些你可能间接在群集上创立用于治理 Ingress 证书的 Secrets。不过，你能够应用 sync secrets 性能，它能够创立 Kubernetes Secrets，而后为作为 Env 变量的 Secret 提供反对。

External Secrets Operator (ESO)

External Secrets Operator（ESO）是一种用户敌对型解决方案，用于将内部机密治理解决方案中的机密同步到 Kubernetes Secrets 中。ESO 作为部署资源运行在 Kubernetes 集群中，利用自定义资源定义（CustomResourceDefinitions，CRD）通过 SecretStore 资源配置对 Secret Provider 的拜访，并利用 ExternalSecret 资源管理 Kubernetes 机密资源。

客户在以下状况下会抉择 ESO:

• 他们须要与平台轻松集成，并便于开发人员应用
• 他们对集群的管制立体高度信赖 – 尤其是在如何对 etcd 进行加密配置或如何在集群上治理 RBAC 方面
• 他们在秘密治理方面有多集群用例，须要跨集群秘密集成
• 他们须要为非应用程序应用治理平台 Secrets，例如用于 Ingress、自动化、图像拉取的秘密
• 须要在集群上批改 Secrets，并为特定利用提供模板
• 最初，也是最重要的一点是，他们的用例须要集群上的 Secrets

将应用程序与 HSM（硬件安全模块）集成

最高级别平安，将应用程序或 K8s 与 HSM（硬件安全模块）集成。细节略。

总结

明天，咱们理解 K8s 提供的各种加密选项，以及每种选项如何爱护敏感数据，能够依据您的应用案例和理论状况做出理智的抉择。

以下是笔者的一些集体倡议, 仅供参考:

• 次要应用 AWS 的，能够依据安全级别抉择：EBS 加密或 KMS 加密
• 在数据中心应用 K8s, 且有 K8s 集群外的 Secrets 须要治理的，举荐应用 Hashicorp Vault
• 在数据中心应用 K8s, 且只有 K8s Secrets 加密需要，那么 etcd 动态加密、ESO 都是能够思考的选项

三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.