ecret与ConfigMap都是用来存储配置信息的，不同之处在于ConfigMap是明文存储的，而Secret用来保存敏感信息，如：密码、OAuth令牌，ssh key等等。

Secret有三种类型：

• Service Account：用来访问kubernetes API，由k8s自动创建，并且会自动挂载到pod的/run/secrets/kubernetes.io/serviceaccount 目录中。
• Opaque：base64编码格式的Secret，用来存储密码，密钥等。
• kubernetes.io/dockerconfigjson： 用来存储私有docker registry的认证信息。

一、前言

ConfigMap传递敏感数据，就需要Secret。
Secret 对象可以存储和管理敏感信息，比如 passwords、OAuth tokens、以及 ssh keys 等。把敏感信息存储到 Secret 对象中会比放到 Pod 的定义文件或是容器镜像中更加安全、灵活，使用 Secret 对象可以更好的控制数据的使用方式，并且减少意外泄露的风险。

不仅用户可以创建 Secret 对象，kubernetes 系统也会创建一些 Secret 对象。
Secret 被创建以后，可以使用 3 种方式创建它：

• 创建 Pod 时，通过为 Pod 指定 Service Account 自动使用该 Secret
• 通过挂载该 Secret 到 Pod 来使用它
• 在 Docker 镜像下载时使用，通过指定 Pod 的 spc.ImagePullSecrets 来引用它

在存储数据的时候，如何从 ConfigMap 和 Secret 这两者之间进行选择呢？

• 使用 ConfigMap 存储非敏感的配置信息
• 使用 Secret 存储敏感的配置信息
• 如果配置文件既包含敏感信息、又包含非敏感信息，依然选择 Secret 进行存储

Secret 和 ConfigMap 对比，既有相同点、也有不同点，列表如下：
相同点：

• 存储数据都属于 key-value 键值对形式
• 属于某个特定的 namespace
• 可以导出到环境变量
• 可以通过目录/文件形式挂载（支持挂载所有 key 和部分 key）

不同点：

• Secret 可以被 ServerAccount 关联使用
• Secret 可以存储 Register 的鉴权信息，用于 ImagePullSecret 参数中，用于拉取私有仓库的镜像
  Secret 支持 Base64 加密
• Secret 分为 Opaque、kubernetes.io/Service Account、kubernetes.io/dockerconfigjson 三种类型，ConfigMap 不区分类型
• Secret 文件存储在 tmpfs 文件系统中，Pod 删除后 Secret 文件也会对应被删除

二、默认令牌Secret
Service Accounts使用API证书自动创建并且绑定Secret。

kubernetes 系统可以自动创建用于访问 API 证书的 Secret，并且可以自动绑定到 Pod 中使用这种类型的 Secret。

可以根据需要禁用或覆盖重写这类 Secret，但是通常情况下如果考虑到安全性，更加推荐使用系统默认创建的 Secret。

查看系统默认创建的Secret: kubectl get secrets

查看Secrets详细信息：kubectl describe secrets

新建yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-manual
spec:
  containers:
    - image: registry.cn-hangzhou.aliyuncs.com/chenshi-kubernetes/nginx:1.9.1
      name: nginx
      ports:
        - containerPort: 80
          protocol: TCP

执行创建

$ kubectl create -f nginx-manual.yaml
pod/nginx-manual created

查看详细信息

$ kubectl describe pod nginx-manual

这里显示了 default-token-sz72t Secret 被挂载到了容器中的 /var/run/secrets/kubernetes.io/serviceaccount 目录下

    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-sz72t (ro)

查看容器该目录下的文件名是否符合

$ kubectl exec nginx-manual ls /var/run/secrets/kubernetes.io/serviceaccount

ca.crt
namespace
token

**Tips: **

当pod被API Service创建时，API Service不会校验该pod引用的Secret是否存在

一旦这个pod被调度，则kubelet将试着获取Secret的值

如果Secret不存在或暂时无法连接到API Secret，则kubelet会按照一定的时间间隔定期重试获取该Secret，并发送一个Event来解释pod没有启动的原因。

一旦 Secret 被 Pod 获取，则 kubelet 将创建并挂载包含 Secret 的 Volume，只有所有 Volume 都挂载成功，Pod 中的 Container 才会被启动。

三、创建Secret
创建Secret三种方式：

• kubectl
• yaml配置文件
• 生成器创建secret

（1）使用kubectl创建secret

定义帐号和密码

echo -n 'admin' > /home/donald/username.txt
echo -n '1f2d1e2e67df' > /home/donald/password.txt

创建

shell复制代码$ kubectl create secret generic db-user-pass --from-file=/home/donald/username.txt --from-file=/home/donald/password.txt
secret/db-user-pass created

查看Secret

kubectl get secrets

（2）yaml配置文件
文件可以是json或yaml
定义Secret有两种字段：

data：被Base64编码以后的数据
stringData：可以纯文本

定义帐号和密码

echo -n 'admin' | base64
YWRtaW4=
$ echo -n '123' | base64
MTIz

创建secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MTIz

执行创建
$ kubeclt create -f secre.yaml
secret/mysecret created

（3）生成器创建Secret
kubectl v1.14版本开始支持 Kustomize管理对象

创建一个kustomization.yaml, 生成器字段secretGenerator

cat <<EOF >/home/donald/kustomization.yaml

secretGenerator:
- name: db-user-pass
  files:
  - username.txt
  - password.txt

或者 key-value形式
cat <<EOF >/home/donald/kustomization.yaml

secretGenerator:
- name: db-user-pass
  literals:
  - username=admin
  - password=secret

执行创建

shell复制代码kubectl apply -k .

查看

kubectl get 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 （硬件安全模块） 集成。细节略。