你可能已经听过很多遍这个不算秘密的秘密了--Kubernetes Secrets 不是加密的！Secret 的值是存储在 etcd 中的 base64 encoded（编码） 字符串。这意味着，任何可以访问你的集群的人，都可以轻松解码你的敏感数据。任何人？是的，几乎任何人都可以，尤其是在集群的 RBAC 设置不正确的情况下。任何人都可以访问 API 或访问 etcd。也可能是任何被授权在 Namespace 中创建 pod 或 Deploy，然后使用该权限检索该 Namespace 中所有 Secrets 的人。 如何确保集群上的 Secrets 和其他敏感信息（如 token）不被泄露？在本篇博文中，我们将讨论在 K8s 上构建、部署和运行应用程序时加密应用程序 Secrets 的几种方法。
在 Kubernetes 集群上运行的应用程序可以使用 Kubernetes Secrets，这样就无需在应用程序代码中存储 token 或密码等敏感数据。
当前默认 Kubernetes 集群内 Secrets 的典型工作流程如下：
Dev 阶段：使用 CICD 的应用程序开发人员将 git 作为管理部署到集群的配置的真实来源。访问控制有助于确保对该资源库的访问安全，但这本身并不总能确保应用程序的敏感信息不被泄露。
Ops 阶段：API 服务器会在集群上创建 Kubernetes Secrets 资源，你可以在这里 这里 阅读有关 Secrets 生命周期的更多信息。 存储在 etcd 中的 Secrets 可由应用程序 pod 以三种方式之一使用：
在这三种情况下，密文中的值在使用前都会被解码 (decode)。
那么，既然我们知道了它的工作原理，为什么只对密文进行 base64 编码还不够呢？
Base64 编码是一种二进制到文本的编码方案，它将 24 位二进制数据表示为 6 位 base64 数字。它用于在网络上传输大量数据，尤其是图像文件等大型文件。它的主要功能是在数据通过网络传输时提供数据的完整性。要明确，编码 (encode) 并不是加密 (encrypt)。
在任何 Linux 终端上试试这个。
$ echo -n 'not encrypted' | base64
bm90IGVuY3J5cHRlZA==
$ echo -n 'bm90IGVuY3J5cHRlZA==' | base64 --decode
not encrypted如上，无论是在将 Secrets 传输到群集时，还是在群集上使用时，任何可以访问你系统的人都可以轻松解码你的 Secrets。
作为 DevSecOps 管理员，您显然面临着两个挑战：
以下是加密 K8s Secrets 的几种方案。
作为将代码推送到 git 仓库（又称应用程序的 "真相源"）的开发人员，您可以在将代码推送到 git 仓库之前对应用程序使用的敏感信息进行加密。下面将介绍两种常见的方法，用于在机密提交到 git 仓库并部署到 OpenShift 集群之前对其进行加密：
Bitnami Sealed Secrets: Kubernetes 的“加密的 Secrets”.
典型使用场景：
遇到的问题：“我可以在 git 中管理我所有的 K8s 配置，除了 Secrets。” 解决方案：将您的 Secret 加密到 SealedSecret 中，即使在公共存储库中也可以安全存储。SealedSecret 只能由目标集群中运行的控制器解密，其他人（甚至原始作者）无法从 SealedSecret 中获得原始 Secret。
使用 Bitnami Sealed Secrets 的工作流程示例如下：
kubeseal CLI。kubeseal CLI 在运行时从控制器中获取密钥，对该资源进行加密或密封。对于网络受限的环境，公钥也可以存储在本地并由 kubeseal 使用。 Kubeseal 将创建一个 SealedSecret 自定义资源。如果使用 Argo CD 在 Kubernetes 中部署应用程序，则可以使用 Kustomize SOPS 插件，该插件用于解密使用 SOPS 加密的资源。
在集群上，管理员将：
GitOps) Namespace 中创建存储公钥和私钥的密钥开发人员将：
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 容器平台不对 etcd 数据进行加密。但是原生 K8s, 以及一些 K8s 发行版，提供了启用基于 etcd 的加密选项。
以下是相关的一些参考文档：
读者可以进一步阅读以了解详情。
除了上面 etcd 的（静态）加密方案之外，原生 K8s 和一些 K8s 发行版也提供了基于 KMS 驱动进行（动态）数据加密的方案。
以下是相关的一些参考文档：
在 K8s 中使用 EBS 的公有云/私有云/数据中心节点级加密可以提供额外的加密层。这里以公有云为例说明：
AWS: 在 AWS 上托管 K8s 群集时，可以启用 Amazon EBS 加密，为 EC2 实例提供加密。Amazon EBS 加密在创建加密卷和快照时使用 AWS KMS 密钥。它使用 AES-256-XTS 进行块密码加密。 创建加密 EBS 卷并将其附加到支持的实例类型时，以下类型的数据将被加密：
Azure: 为连接到 Azure Key Vault 的 Azure Managed Disks 提供加密选项
Google 为 Google Cloud Storage 提供加密选项。两者默认都使用 AES 256 密钥，但也可以使用客户管理和提供的密钥，并与 KMS 集成。
选择第三方 Secrets 存储的一个重要原因是，通过集中式 Secrets 存储解决方案，确保在集群之外管理 Secrets 的生命周期。这些 Secrets 存储提供的身份验证和授权策略及程序与群集上的不同，也许更适合控制应用程序数据访问。这些解决方案大多还提供监管机构要求的信封加密和 HSM 支持。流行的解决方案包括 HashiCorp Vault、CyberArk Conjur、AWS Secret Store、Azure Key Vault、Google Secret Manager、1Password 等。
Vault 等解决方案可用于注入应用程序 pod 的特定 Secrets。在这种情况下，sidecar/init 容器都负责对 Secret Provider 进行身份验证，然后应用程序可以在必要时使用返回的 Secrets。与 Provider 的连接是通过 TLS 进行的，以确保 Secrets 检索的安全性。Vault 通过使用 响应封装 提供额外的安全性，这使您可以在中间人无法看到凭证的情况下传递凭证。选择这些解决方案的客户可以决定将机密存储在集群上或集群外。通常情况下，如果客户一直使用 Vault 来满足其基础架构和其他应用需求，他们会倾向于与这些解决方案集成，以便在 K8s 上获得无缝的机密管理体验。
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）是一种用户友好型解决方案，用于将外部秘密管理解决方案中的秘密同步到 Kubernetes Secrets 中。 ESO 作为部署资源运行在 Kubernetes 集群中，利用自定义资源定义（CustomResourceDefinitions，CRD）通过 SecretStore 资源配置对 Secret Provider 的访问，并利用 ExternalSecret 资源管理 Kubernetes 秘密资源。
客户在以下情况下会选择 ESO:
最高级别安全，将应用程序或 K8s 与 HSM （硬件安全模块） 集成。细节略。
今天，我们了解 K8s 提供的各种加密选项，以及每种选项如何保护敏感数据，可以根据您的使用案例和实际情况做出明智的选择。
以下是笔者的一些个人建议, 仅供参考:
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.