Secrets

本文内容包括：

• Kubernetes Secrets
• GitOps管理secrets的策略
• 管理secrets的工具

Kubernetes提供了一种机制，允许用户在受保护的资源对象中存储少量的敏感信息，称为Secret。一个Secret是任何你想要严格控制访问的东西。希望存储在Secret中的数据的常见示例包括用户名和密码凭据、API密钥、SSH密钥和TLS证书等。在本文中，将学习使用GitOps系统时不同的Secret管理策略。简要介绍几种可用于存储和管理Secrets的不同工具。

Kubernetes Secrets

一个简单的Kubernetes Secret是一个由三种信息组成的数据结构:

• Secret的名字
• Secret的类型(可选)
• 字段名到敏感数据的映射，用Base64编码

Secret简单示例如下：

apiVersion: v1
kind: Secret
metadata:
  name: login-credentials
type: Opaque                  ❶  # Type of the Secret, used to facilitate programmatic handling of Secret data
data:
  username: YWRtaW4=          ❷ # The string “admin” Base64 encoded
  password: UEA1NXcwcmQ=      ❸ # The string “P@55w0rd” Base64 encoded

当第一次查看Secret的值时，乍一看，可能会错误地认为Secret值受到了加密的保护，因为这些字段不是可读的，也不是以纯文本形式显示的。

• Secret值采用Base64编码。
• Base64编码与加密不是一回事。
• 查看应该被认为与纯文本相同。

Base64是一种编码算法，它允许你将任何字符转换为由拉丁字母、数字、加号和斜杠组成的字母表。它允许二进制数据以ASCII字符串格式表示，Base64不提供加密。

Kubernetes Base64对数据进行编码的原因是它允许Secrets存储二进制数据。这对于将证书之类的东西存储为Secrets非常重要。如果没有Base64编码，就不可能将二进制配置存储为Secret。

为什么使用Secrets

在Kubernetes中，使用Secrets是可选的，但是比其他技术更方便、灵活和安全，比如将敏感值直接放在Pod规范中，或者在构建期间将值嵌入到容器镜像中。与ConfigMaps一样，Secrets允许将应用程序的配置与构建工件分离。

如何使用Secrets

Kubernetes Secrets和ConfigMaps一样，可以通过以下几种方式使用:

• 作为文件挂载在Pod中的文件
• 作为Pod中的环境变量
• Kubernetes API访问

图1 Secret卷用于向Pods传递密码等敏感信息。Secret卷由tmpfs(一种ram支持的文件系统)支持，因此它们永远不会被写入非易失性存储。

Volume-mounting Secrets as files in a Pod

使用Secrets的第一种方式是将它们装入一个Pod中。为此，首先声明以下内容。

apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-pod
spec:
  Volumes:                      ❶ # A volume of type Secret is declared in the Pod, with an arbitrary name.
  - name: foo
    secret:
      secretName: mysecret
  containers:
  - name: mycontainer
    image: redis
    volumeMounts:               ❷ The container that needs the Secrets specifies a path for where to mount the Secret data volume.
    - name: foo
      mountPath: etc/foo
      readOnly: true

当将一个Secret(或ConfigMap)作为文件卷映射到Pod中时，对底层Secret的更改最终将更新挂载在Pod中的文件。这允许应用程序在不重启容器/Pod的情况下重新配置或热加载。

Using Secrets as environment variables

使用Kubernetes Secrets的第二种方法是将它们设置为环境变量。

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    env:
    - name: SECRET_USERNAME
      valueFrom:
        secretKeyRef:
          name: mysecret       ❶ # Name of the Secret
          key: username        ❷ # The key of the Secret data map
    - name: SECRET_PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysecret       ❶ # Name of the Secret
          key: password        ❷ # The key of the Secret data map

将Secrets作为环境变量公开到容器中，虽然很方便，但可能不是使用Secrets的最佳方式，因为它不如将它们作为卷挂载的文件使用安全。当将Secret设置为环境变量时，容器中的所有进程(包括子进程)将继承OS环境，并能够读取环境变量的值，从而读取Secret数据。例如，一个shell脚本可以通过运行env
实用程序读取环境变量。

使用Secret作为环境变量的第二个缺点是，与将Secrets映射到volume中不同，如果在容器启动后更新Secret，则Secret环境变量的值将不会更新。需要重新启动容器或Pod才能注意到更改。

Using Secrets from the K8s API

最后，Kubernetes Secrets也可以直接从Kubernetes API中检索。假设有以下带有密码字段的Secret。

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  password: UEA1NXcwcmQ=

要检索Secret， Pod本身可以直接从Kubernetes检索Secret值，例如，通过使用kubectl命令或REST API调用。下面的kubectl命令检索名为my-secret
的Secret, Base64解码密码字段，并将明文值打印到标准输出:

$ kubectl get secret my-secret -o=jsonpath='{.data.password}' | base64 --decode
P@55w0rd

SECRET TYPES

Secret类型字段指示Secret中包含什么类型的数据。它主要被软件程序用来识别他们可能感兴趣的相关Secret，以及安全地假设Secret中设置了哪些可用字段。

下表描述了内置的Kubernetes Secret类型，以及每种类型所需的字段。

GitOps and Secrets

Kubernetes GitOps使用者总是会遇到同样的问题:虽然用户非常喜欢将配置存储在Git中，但当涉及到敏感数据时，出于安全考虑，他们不愿意将这些数据存储在Git中。Git被设计成一种协作工具，使得多人和团队可以很容易地访问代码并查看彼此的更改。但是，正是这些相同的属性使得使用Git保存Secrets成为一种极其危险的做法。为什么在Git中存储Secrets是不合适的，原因有很多，我们接下来将讨论这个问题。

No encryption

Kubernetes没有对Secret的内容提供加密，值的Base64编码应该被视为与纯文本相同。此外，Git本身并不提供任何形式的内置加密。因此，当在Git存储库中存储Secrets时，所有能够访问Git存储库的人都会看到Secrets。

分布式Git repos

使用GitOps，你和团队成员在本地将Git存储库克隆到你的笔记本电脑和工作站，以管理应用程序的配置。但是，这样做的话，你也会在没有适当的审计或跟踪的情况下，将Secrets扩散并分发到许多系统。如果这些系统中的任何一个被破坏(被黑客攻击或甚至物理上丢失)，就会有人获得你所有的Secret。

没有细粒度(文件级)访问控制

Git不提供Git存储库的子路径或子文件的读保护。换句话说，不可能限制对Git存储库中的某些文件的访问，而不限制对其他文件的访问。在处理Secrets时，理想情况下应该在需要知道的基础上授予对Secrets的读访问权。例如，如果你有一个需要对Git存储库进行部分访问的临时员工，那么你将希望给该用户尽可能少的内容访问权限。不幸的是，Git并没有提供任何工具来完成这一任务。

安全存储

Git从未打算在Secret管理系统中使用。因此，它没有设计成系统标准的加密等安全特性。因此，受损的Git服务器还可能泄露其管理的所有存储库的Secret，使其成为主要攻击目标。

尽管Git本身并没有提供安全特性，比如静态加密，但Git提供程序经常在Git之上提供这些特性。例如，GitHub确实声称可以在静止状态下加密存储库。但是这个功能可能因提供者的不同而不同。

完整提交历史

一旦将Secret添加到Git提交历史中，就很难删除它了。如果将Secret签入Git并随后删除，那么仍然可以通过签出存储库历史中删除Secret之前的一个点来检索Secret。即使对Secret进行了加密，当稍后旋转用于加密Secret的密钥并使用新密钥重新加密Secret时，使用旧密钥加密的Secret仍然存在于存储库历史记录中。

Secret管理策略

在GitOps中有许多不同的策略来处理Secrets，并在灵活性、可管理性和安全性方面进行权衡。在讨论实现这些策略的工具的应用之前，我们将首先在概念层面上回顾一些策略。

在Git中保存Secrets

GitOps and Secrets的第一个策略是完全没有策略。换句话说，只需像其他Kubernetes资源一样在Git中提交和管理Secrets，并接受所带来的安全后果。

你可能会想，“在Git中存储我的Secrets有什么错吗?”即使你有一个私有的GitHub存储库，它只能由你的团队中受信任的成员访问，你也可能希望允许第三方访问Git repo-CI/CD系统、安全扫描仪、静态分析等等。通过向这些第三方软件系统提供你的Git Secrets存储库，你就可以将secrets委托给他们。

因此，在实践中，只有当Secrets不包含任何真正敏感的数据(如开发和测试环境)时，才能真正接受将Secrets按原样存储在Git中。

将Secret嵌入到容器镜像中

避免在Git中存储Secrets的一个简单策略是将敏感数据直接放入容器镜像中。在这种方法中，作为Docker构建过程的一部分，Secret数据直接复制到容器镜像中。

图2将Secret放入到容器映像中Docker构建过程将敏感数据嵌入到镜像中(例如将敏感文件复制到容器中)。没有使用Secret存储(Kubernetes或外部)，但是容器仓库变得敏感，因为它实际上是一个Secret存储。

一个简单的Dockerfile将Secrets放入镜像中，如下：

FROM scratch
COPY ./my-app /my-app
COPY ./credentials.txt /credentials.txt
ENTRYPOINT [“/my-app”]

这种方法的一个优点是它将Git甚至Kubernetes本身从中移除。事实上，将Secret数据放入容器镜像后，映像可以在任何地方运行，而不仅仅是Kubernetes，并且不需要任何配置即可工作。

但是，直接将敏感数据放入到容器镜像中有一些非常糟糕的缺点，这将自动将其排除为可行选项。第一个问题是容器镜像本身现在是敏感的。由于敏感数据被写入到镜像中，任何人都可以访问容器镜像(例如通过docker pull
)的东西现在都可以简单地复制并检索Secret。

另一个问题是，因为Secret是放入到镜像中的，更新secret数据非常麻烦。每当需要更新凭据时，就需要完全重新构建容器镜像。

第三个问题是容器镜像不够灵活，无法适应同一个镜像需要使用不同的Secret数据集运行的情况。假设有三个环境将部署这个容器镜像:

• 开发环境
• 测试环境
• 生产环境

每个环境都需要一组不同的凭据，因为它连接到三个不同的数据库。将Secret数据放入到容器镜像中的方法在这里不起作用，因为它只能选择一个数据库凭证放入到镜像中。

Out-of-band management

在GitOps中处理Secret的第二个方法是管理完全脱离GitOps的secret。使用这种方法，除了Kubernetes Secrets之外的所有内容都将在Git中定义，并通过GitOps进行部署，但将使用一些其他机制来部署Secrets，即使它是手动的。

例如，用户可以将他们的Secrets存储在数据库中，云提供商管理的Secret存储中，甚至可以将文本文件存储在本地工作站上。当需要部署时，用户将手动运行kubectl apply
程序将Secret部署到集群中，然后让GitOps operator部署其他所有东西。

图3使用带外管理，GitOps用于部署正常资源。但是使用其他一些机制(例如手动kubectl apply
)来部署Secret。

这种方法的明显缺点是，需要两种不同的机制来将资源部署到集群:一种是通过GitOps将正常的Kubernetes资源部署到集群，另一种是严格地将Secret资源部署到集群。

在GitOps中处理secret的另一个策略是使用Kubernetes之外的外部secret管理系统。在这种策略中，应用程序容器本身在运行时使用时动态地检索Secret值，而不是使用本地Kubernetes特性将Secrets存储并加载到容器中。

Secret管理系统有很多种，但最流行和最广泛使用的是HashiCorp Vault
，这是在讨论外部Secret管理系统时主要关注的工具。个别云提供商也提供他们自己的secret管理服务，如AWS secret管理器、谷歌云secret管理器和微软Azure密钥库。这些工具可能在功能和特性集上有所不同，但通用原则是相同的，应该适用于所有的工具。

图4从外部Secret存储中检索Secret。在这种方法中，敏感数据不会以Kubernetes Secrets的形式存储。相反，它存储在外部系统中，由容器在运行时检索(例如通过API调用)。

通过选择使用外部的Secret管理系统(比如Vault)来管理Secrets，可以有效地决定不使用Kubernetes Secrets。这是因为在使用此策略时，依赖于外部secret管理系统来存储和检索secret，而不是Kubernetes。一个很大的结果是，也无法利用Kubernetes Secrets提供的一些便利，比如从Secret设置环境变量的值，或者将Secret映射为卷中的文件。

当使用外部Secret存储时，应用程序有责任安全地从存储中检索Secrets。例如，当应用程序启动时，它可以在运行时动态地从Secret存储中检索Secret值，而不是使用Kubernetes机制(环境变量、卷挂载等)。这就把保密的责任转移到了必须安全地检索Secret的应用程序开发人员和外部Secret存储的管理员身上。

这种技术的另一个结果是，由于Secrets是在一个单独的数据库中管理的，因此没有与在Git中管理配置时相同的更改历史/记录。这甚至可能影响以可预测的方式回滚的能力。例如，在回滚期间，在之前的Git提交中应用manifest可能不够。另外，在Git提交的同时，还必须将Secret回滚到以前的值。这取决于Secret store使用的是什么，在最好的情况下这可能是不方便的，或者在最坏的情况下完全不可能。

在Git中加密Secret

由于Git被认为用于存储纯文本的Secrets是不安全的，因此一种策略是对敏感数据进行加密，这样就可以安全地存储在Git中，然后在接近使用点的时候对加密的数据进行解密。执行解密的参与者必须拥有必要的密钥来解密加密的Secret。这可能是应用程序本身、填充应用程序使用的卷的init容器或为应用程序无缝处理这些任务的控制器。

图5 Secret与其他Kubernetes资源一起被加密并安全存储在Git中在运行时，应用程序可以在使用之前解密内容。

Bitnami SealedSecrets是一款非常流行的工具，它可以帮助我们在Git中加密Secrets。

在Git中加密Secrets的挑战在于，仍然涉及到最后一个Secret，那就是用于加密那些Secrets的加密密钥。如果没有对加密密钥的充分保护，这种技术就毫无意义，因为任何能够访问加密密钥的人现在都能够解密并访问清单中的敏感数据。

工具

在Kubernetes生态系统内部和外部，已经出现了许多项目来帮助用户处理Secrets的问题。所有的项目都使用前面讨论过的Secret管理策略之一。以下，我们将介绍一些比较流行的工具，这些工具可以使用以gitops为重点的方法来补充Kubernetes环境。

HashiCorp Vault

由HashiCorp开发的Vault是一个专用的开源工具，用于以安全的方式存储和管理Secrets。Vault提供了一个CLI和一个UI，以及一个用于对Secret数据进行编程访问的API。Vault并不是Kubernetes特有的，它是作为一个独立的Secret管理系统而流行的。

Vault installation and setup

有许多方法可以安装和运行Vault，推荐的最简单的入门方法是使用HashiCorp维护的官方Helm chart安装Vault。

$ helm repo add hashicorp https://helm.releases.hashicorp.com
$ helm install vault hashicorp/vault \
    --set server.dev.enabled=true \
    --set injector.enabled=true

Vault是一个通用的Secret管理系统，适用于Kubernetes以外的应用程序和平台。许多企业选择为其公司运行集中管理的Vault实例，因此单个Vault实例可以为多个Kubernetes集群和虚拟机提供服务，开发人员和运营商也可以从公司网络和工作站访问该实例。

安装后，可以通过标准端口转发访问Vault，并访问http://localhost:8200：

# Run the following from a different terminal, or background it with ‘&’$ kubectl port-forward vault-0 8200$ export VAULT_ADDR=http://localhost:8200# In dev mode, the token is the word: root$ vault login
Token (will be hidden):
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"again. Future Vault requests will automatically use this token.
Key                  Value
---                  -----
token                root
token_accessor       o4SQvGgg4ywEv0wnGgqHhK1h
token_duration       ∞
token_renewable      falsetoken_policies       ["root"]
identity_policies    []
policies             ["root"]
$ vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     trueSealed          falseTotal Shares    1Threshold       1Version         1.4.0Cluster Name    vault-cluster-23e9c708
Cluster ID      543c058a-a9d4-e838-e270-33f7e93814f2
HA Enabled      false

Vault use

一旦Vault安装到集群中，就可以在Vault中存储你的第一个Secret了:

root@gongwanzhang:$ vault kv put secret/hello foo=world
Key              Value
---              -----
created_time     2021-09-15T12:36:21.956834623Z
deletion_time    n/a
destroyed        falseversion          1

要查看Secret，运行vault kv get
命令:

$ vault kv get secret/hello
====== Metadata ======
Key              Value
---              -----
created_time     2021-09-15T12:36:21.956834623Z
deletion_time    n/a
destroyed        falseversion          1=== Data ===
Key    Value
---    -----
foo    world

默认情况下，vault kv get
将以表格格式打印Secrets。虽然这种格式以一种易于阅读的方式呈现，而且对人来说很好，但它不太容易通过自动化来解析，也不容易被应用程序使用。为了帮助实现这一点，Vault提供了一些格式化输出和提取Secret的特定字段的额外方法:

$ vault kv get -field foo secret/hello
world
$ vault kv get -format json secret/hello
{  "request_id": "825d85e4-8e8b-eab0-6afb-f6c63856b82c",  "lease_id": "",  "lease_duration": 0,  "renewable": false,  "data": {    "data": {      "foo": "world"
    },    "metadata": {      "created_time": "2021-09-15T12:36:21.956834623Z",      "deletion_time": "",      "destroyed": false,      "version": 1
    }
  },  "warnings": null
}

这使得在启动脚本中使用Vault CLI变得容易：

1. 运行vault kv get
   命令获取Secret的值。
2. 将Secret值设置为环境变量或文件。
3. 启动主应用程序，现在它可以从env var或文件中读取Secret。

这样的启动脚本示例如下所示。

#!/bin/shexport VAULT_TOKEN=your-vault-tokenexport VAULT_ADDR=https://your-vault-address.com:8200export HELLO_SECRET=$(vault kv get -field foo secret/hello)./guestbook

要将其与Kubernetes应用程序集成，可以使用这个启动脚本作为容器的入口点，用启动脚本替换普通的应用程序命令，该脚本在检索Secret并将其设置为环境变量后启动应用程序。

关于这种方法需要注意的一点是，vault kv get
命令本身需要访问vault的特权。因此，要使这个脚本工作，vault kv get
需要安全地与vault服务器通信，通常使用vault令牌。另一种说法是，你仍然需要一个secret来获得更多的secret。这就产生了一个先有鸡还是先有蛋的问题，你现在需要以某种方式安全地配置和存储检索应用程序Secrets所需的Vault secret。

Vault Agent Sidecar Injector

由于Vault的流行，许多Vault和Kubernetes集成被创建以使其更易于使用。Kubernetes的官方集成是由HashiCorp开发和支持的Vault Agent Sidecar Injector。

要让应用程序从Vault检索Secrets，需要使用专用脚本，该脚本在启动应用程序之前执行一些必要步骤。这涉及到检索和准备应用程序Secrets。这种方法存在一些问题:

• 尽管以安全的方式检索了应用程序的Secret，但仍然需要使用该技术来保护用于访问应用程序Secret的Vault Secret。
• 容器需要支持Vault，也就是说，容器需要使用专门的脚本构建，该脚本理解如何检索特定的Vault Secret并将其传递给应用程序。

为了解决这一问题，HashiCorp开发了Vault Agent Sidecar Injector，以通用的方式解决了这两个问题。Vault Agent Sidecar Injector会自动修改以特定方式标注的Pods，并安全地检索标注的Secret引用(application Secrets)，并将这些值呈现到应用程序容器可访问的共享卷中。通过将Secrets呈现给共享卷，Pod中的容器可以在不感知Vault的情况下使用Vault Secrets。

Vault Agent Injector 修改Pod规范，将Vault Agent容器包含到应用程序可访问的共享内存卷中。要实现这一点，可以使用Kubernetes中的一个特性，即mutating admission webhooks。

mutating admission webhooks是扩展Kubernetes API服务器的多种方法之一。可变webhook实现为HTTP回调，它拦截允许请求(创建、更新、补丁请求)并以某种方式修改对象。

图6解释了Vault Agent Injector的工作原理。

这一方法涉及的一系列步骤如下:

1. 将工作负载资源(Deployment、Job、ReplicaSet等)部署到集群中。这最终创建了Kubernetes Pod。
2. 当Pod被创建时，Kubernetes API服务器调用一个mutating webhook调用到Vault Agent Sidecar Injector。Vault Agent Sidecar Injector通过注入一个init容器到Pod(也可以是一个Sidecar)来修改Pod。
3. 当Vault代理Init容器运行时，它安全地与Vault通信以检索Secret。
4. Secret被写入共享内存卷，该卷在init容器和应用程序容器之间共享。
5. 当应用程序容器运行时，它现在能够从共享内存卷检索Secret。

Sealed Secrets

Bitnami的Sealed Secrets是GitOps Secret问题的另一个解决方案，它恰当地描述了这个问题:“我可以在Git中管理我的所有k8配置，除了Secrets。”虽然不是唯一的工具，但是目前对于那些更喜欢在Git中加密他们的Secret的团队来说，Sealed Secrets是最流行和最广泛使用的工具。这使得包括Secrets在内的所有内容都可以在Git中进行完全和完整的管理。

Sealed Secrets遵循对敏感数据进行加密的策略，这样它就可以安全地存储在Git中，并在集群中解密。它的独特之处在于它提供了一个控制器和命令行界面，这有助于自动化这个过程。

Sealed Secrets包括以下内容:

• 一个新的CustomResourceDefinition，称为SealedSecret，它将产生一个普通的Secret
• 在集群中运行的一个控制器，负责解密一个SealedSecret，并使用解密的数据生成一个正常的Kubernetes Secret
• kubeseal是一个命令行工具，它将敏感数据加密到一个SealedSecret中，以便在Git中安全存储

当用户希望使用Git管理Secret时，他们会使用kubeseal CLI将Secret密封或加密到SealedSecret自定义资源中，并将其与其他应用程序资源(部署、ConfigMaps等)一起存储在Git中。Sealed Secret和Kubernetes的其他资源一样。

当部署了SealedSecret时，sealedsecrets -controller
将解密数据并生成一个同名的普通Kubernetes Secret。此时，使用SealedSecret和使用普通的Kubernetes Secret并没有什么不同，因为pod可以使用常规的Kubernetes Secret。

总结

• Kubernetes Secrets是简单的数据结构，允许将应用程序的配置与构建工件分离。
• Pods可以以各种方式使用Kubernetes Secrets，包括卷挂载、环境变量或直接从Kubernetes API检索。
• 由于缺乏加密和路径级访问控制，Git不适合用于Secrets。
• 将Secret放入到容器中意味着容器本身也是敏感的，并且没有将配置与构建工件分离。
• 带外的Secret管理允许使用本地Kubernetes功能，但会产生不同的机制来管理/部署Secrets和配置。
• 外部Secret管理允许灵活性，但失去了使用Kubernetes原生Secret功能的能力。
• HashiCorp Vault是一个安全的外部Secret存储，可以使用brew安装。Vault还提供了一个CLI Vault来管理存储中的Secret。启动时的pod可以使用CLI和脚本从外部存储中获取Secrets。
• Vault Agent Sidecar Injector可以自动将Secrets注入到pod中，而无需CLI和脚本。
• Sealed Secrets是一个用于保护Kubernetes Secrets中的数据的CustomResourceDefinition (CRD)。可以通过应用Sealed Secrets清单将Sealed Secrets安装到集群中。Sealed Secrets附带了一个CLI工具kubeseal，用于加密Kubernetes Secrets中的数据。
• Kustomize Secret生成器插件允许用户定义的逻辑在构建过程中将Secrets注入到清单中。

感兴趣的关注如下公众号！