Kubernetes Secret

Secret

Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。

由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将机密数据写入非易失性存储。

Secret 类似于 ConfigMap 但专门用于保存机密数据。

Caution:
默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储（etcd）中。 任何拥有 API 访问权限的人都可以检索或修改 Secret，任何有权访问 etcd 的人也可以。 此外，任何有权限在命名空间中创建 Pod 的人都可以使用该访问权限读取该命名空间中的任何 Secret； 这包括间接访问，例如创建 Deployment 的能力。
为了安全地使用 Secret，请至少执行以下步骤：

1. 为 Secret 启用静态加密；
2. 启用或配置 RBAC 规则来限制读取和写入 Secret 的数据（包括通过间接方式）。需要注意的是，被准许创建 Pod 的人也隐式地被授权获取 Secret 内容。
3. 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。

Secret 的使用

Pod 可以用三种方式之一来使用 Secret：

• 作为挂载到一个或多个容器上的卷 中的文件。
• 作为容器的环境变量。
• 由 kubelet 在为 Pod 拉取镜像时使用。

Kubernetes 控制面也使用 Secret； 例如，引导令牌 Secret 是一种帮助自动化节点注册的机制。

Secret 的替代方案 

除了使用 Secret 来保护机密数据，你也可以选择一些替代方案。

下面是一些选项：

• 如果你的云原生组件需要执行身份认证来访问你所知道的、在同一 Kubernetes 集群中运行的另一个应用， 你可以使用 ServiceAccount 及其令牌来标识你的客户端身份。
• 你可以运行的第三方工具也有很多，这些工具可以运行在集群内或集群外，提供机密数据管理。 例如，这一工具可能是 Pod 通过 HTTPS 访问的一个服务，该服务在客户端能够正确地通过身份认证 （例如，通过 ServiceAccount 令牌）时，提供机密数据内容。
• 就身份认证而言，你可以为 X.509 证书实现一个定制的签名者，并使用 CertificateSigningRequest 来让该签名者为需要证书的 Pod 发放证书。
• 你可以使用一个设备插件 来将节点本地的加密硬件暴露给特定的 Pod。例如，你可以将可信任的 Pod 调度到提供可信平台模块（Trusted Platform Module，TPM）的节点上。 这类节点是另行配置的。

你还可以将如上选项的两种或多种进行组合，包括直接使用 Secret 对象本身也是一种选项。

例如：实现（或部署）一个 operator， 从外部服务取回生命期很短的会话令牌，之后基于这些生命期很短的会话令牌来创建 Secret。 运行在集群中的 Pod 可以使用这些会话令牌，而 Operator 则确保这些令牌是合法的。 这种责权分离意味着你可以运行那些不了解会话令牌如何发放与刷新的确切机制的 Pod。

使用 Secret 

创建 Secret

• 使用 kubectl 命令来创建 Secret
• 基于配置文件来创建 Secret
• 使用 kustomize 来创建 Secret

对 Secret 名称与数据的约束

Secret 对象的名称必须是合法的 DNS 子域名。

在为创建 Secret 编写配置文件时，你可以设置 ​data ​与/或 ​stringData ​字段。 ​data ​和 ​stringData ​字段都是可选的。​data ​字段中所有键值都必须是 base64 编码的字符串。如果不希望执行这种 base64 字符串的转换操作，你可以选择设置 ​stringData ​字段，其中可以使用任何字符串作为其取值。

​data ​和 ​stringData ​中的键名只能包含字母、数字、​-​、​_​ 或 ​.​ 字符。 ​stringData ​字段中的所有键值对都会在内部被合并到 ​data ​字段中。 如果某个主键同时出现在 ​data ​和 ​stringData ​字段中，​stringData ​所指定的键值具有高优先级。

尺寸限制 

每个 Secret 的尺寸最多为 1MiB。施加这一限制是为了避免用户创建非常大的 Secret， 进而导致 API 服务器和 kubelet 内存耗尽。不过创建很多小的 Secret 也可能耗尽内存。 你可以使用资源配额来约束每个名字空间中 Secret（或其他资源）的个数。

编辑 Secret 

你可以使用 kubectl 来编辑一个已有的 Secret：

kubectl edit secrets mysecret

这一命令会启动你的默认编辑器，允许你更新 ​data ​字段中存放的 base64 编码的 Secret 值； 例如：

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file, it will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: { ... }
  creationTimestamp: 2020-01-22T18:41:56Z
  name: mysecret
  namespace: default
  resourceVersion: "164619"
  uid: cfee02d6-c137-11e5-8d73-42010af00002
type: Opaque

这一示例清单定义了一个 Secret，其 ​data ​字段中包含两个主键：​username ​和 ​password​。 清单中的字段值是 Base64 字符串，不过，当你在 Pod 中使用 Secret 时，kubelet 为 Pod 及其中的容器提供的是解码后的数据。

你可以在一个 Secret 中打包多个主键和数值，也可以选择使用多个 Secret， 完全取决于哪种方式最方便。

使用 Secret 

Secret 可以以数据卷的形式挂载，也可以作为环境变量 暴露给 Pod 中的容器使用。Secret 也可用于系统中的其他部分，而不是一定要直接暴露给 Pod。 例如，Secret 也可以包含系统中其他部分在替你与外部系统交互时要使用的凭证数据。

Kubernetes 会检查 Secret 的卷数据源，确保所指定的对象引用确实指向类型为 Secret 的对象。因此，如果 Pod 依赖于某 Secret，该 Secret 必须先于 Pod 被创建。

如果 Secret 内容无法取回（可能因为 Secret 尚不存在或者临时性地出现 API 服务器网络连接问题），kubelet 会周期性地重试 Pod 运行操作。kubelet 也会为该 Pod 报告 Event 事件，给出读取 Secret 时遇到的问题细节。

可选的 Secret 

当你定义一个基于 Secret 的环境变量时，你可以将其标记为可选。 默认情况下，所引用的 Secret 都是必需的。

只有所有非可选的 Secret 都可用时，Pod 中的容器才能启动运行。

如果 Pod 引用了 Secret 中的特定主键，而虽然 Secret 本身存在，对应的主键不存在， Pod 启动也会失败。

在 Pod 中以文件形式使用 Secret 

如果你希望在 Pod 中访问 Secret 内的数据，一种方式是让 Kubernetes 将 Secret 以 Pod 中一个或多个容器的文件系统中的文件的形式呈现出来。

要配置这种行为，你需要：

1. 创建一个 Secret 或者使用已有的 Secret。多个 Pod 可以引用同一个 Secret。
2. 更改 Pod 定义，在 ​.spec.volumes[]​ 下添加一个卷。根据需要为卷设置其名称， 并将 ​.spec.volumes[].secret.secretName​ 字段设置为 Secret 对象的名称。
3. 为每个需要该 Secret 的容器添加 ​.spec.containers[].volumeMounts[]​。 并将 ​.spec.containers[].volumeMounts[].readyOnly​ 设置为 ​true​， 将 ​.spec.containers[].volumeMounts[].mountPath​ 设置为希望 Secret 被放置的、目前尚未被使用的路径名。
4. 更改你的镜像或命令行，以便程序读取所设置的目录下的文件。Secret 的 ​data​ 映射中的每个主键都成为 ​mountPath ​下面的文件名。

下面是一个通过卷来挂载名为 ​mysecret ​的 Secret 的 Pod 示例：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      optional: false # 默认设置，意味着 "mysecret" 必须已经存在

你要访问的每个 Secret 都需要通过 ​.spec.volumes​ 来引用。

如果 Pod 中包含多个容器，则每个容器需要自己的 ​volumeMounts ​块， 不过针对每个 Secret 而言，只需要一份 ​.spec.volumes​ 设置。

Note:
Kubernetes v1.22 版本之前都会自动创建用来访问 Kubernetes API 的凭证。 这一老的机制是基于创建可被挂载到 Pod 中的令牌 Secret 来实现的。 在最近的版本中，包括 Kubernetes v1.24 中，API 凭据是直接通过 TokenRequest API 来获得的，这一凭据会使用投射卷 挂载到 Pod 中。使用这种方式获得的令牌有确定的生命期，并且在挂载它们的 Pod 被删除时自动作废。
你仍然可以手动创建 服务账号令牌。例如，当你需要一个永远都不过期的令牌时。 不过，仍然建议使用 TokenRequest 子资源来获得访问 API 服务器的令牌。

将 Secret 键投射到特定目录

你也可以控制 Secret 键所投射到的卷中的路径。 你可以使用 ​.spec.volumes[].secret.items​ 字段来更改每个主键的目标路径：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username

将发生的事情如下：

• ​mysecret ​中的键 ​username ​会出现在容器中的路径为 ​/etc/foo/my-group/my-username​， 而不是​ /etc/foo/username​。
• Secret 对象的 ​password ​键不会被投射。

如果使用了 ​.spec.volumes[].secret.items​，则只有 ​items ​中指定了的主键会被投射。 如果要使用 Secret 中的所有主键，则需要将它们全部枚举到 ​items ​字段中。

如果你显式地列举了主键，则所列举的主键都必须在对应的 Secret 中存在。 否则所在的卷不会被创建。

Secret 文件的访问权限

你可以为某个 Secret 主键设置 POSIX 文件访问权限位。 如果你不指定访问权限，默认会使用 ​0644​。 你也可以为整个 Secret 卷设置默认的访问模式，然后再根据需要在主键层面重载。

例如，你可以像下面这样设置默认的模式：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      defaultMode: 0400

该 Secret 被挂载在 ​/etc/foo​ 下，Secret 卷挂载所创建的所有文件的访问模式都是 ​0400​。

Note:
如果你是使用 JSON 来定义 Pod 或 Pod 模板，需要注意 JSON 规范不支持八进制的记数方式。 你可以在 ​defaultMode ​中设置十进制的值（例如，八进制中的 0400 在十进制中为 256）。 如果你使用 YAML 来编写定义，你可以用八进制值来设置 ​defaultMode​。

使用来自卷中的 Secret 值 

在挂载了 Secret 卷的容器内，Secret 的主键都呈现为文件。 Secret 的取值都是 Base64 编码的，保存在这些文件中。

下面是在上例中的容器内执行命令的结果：

ls /etc/foo/

输出类似于：

username
password

cat /etc/foo/username

输出类似于：

admin

cat /etc/foo/password

输出类似于：

1f2d1e2e67df

容器中的程序要负责根据需要读取 Secret 数据。

挂载的 Secret 是被自动更新的 

当卷中包含来自 Secret 的数据，而对应的 Secret 被更新，Kubernetes 会跟踪到这一操作并更新卷中的数据。更新的方式是保证最终一致性。

Note:
对于以 subPath 形式挂载 Secret 卷的容器而言， 它们无法收到自动的 Secret 更新。

Kubelet 组件会维护一个缓存，在其中保存节点上 Pod 卷中使用的 Secret 的当前主键和取值。 你可以配置 kubelet 如何检测所缓存数值的变化。 kubelet 配置中的 ​configMapAndSecretChangeDetectionStrategy ​字段控制 kubelet 所采用的策略。 默认的策略是 ​Watch​。

对 Secret 的更新操作既可以通过 API 的 watch 机制（默认）来传播， 基于设置了生命期的缓存获取，也可以通过 kubelet 的同步回路来从集群的 API 服务器上轮询获取。

因此，从 Secret 被更新到新的主键被投射到 Pod 中，中间存在一个延迟。 这一延迟的上限是 kubelet 的同步周期加上缓存的传播延迟， 其中缓存的传播延迟取决于所选择的缓存类型。 对应上一段中提到的几种传播机制，延迟时长为 watch 的传播延迟、所配置的缓存 TTL 或者对于直接轮询而言是零。

以环境变量的方式使用 Secret

如果需要在 Pod 中以环境变量 的形式使用 Secret：

1. 创建 Secret（或者使用现有 Secret）。多个 Pod 可以引用同一个 Secret。
2. 更改 Pod 定义，在要使用 Secret 键值的每个容器中添加与所使用的主键对应的环境变量。 读取 Secret 主键的环境变量应该在 ​env[].valueFrom.secretKeyRef​ 中填写 Secret 的名称和主键名称。
3. 更改你的镜像或命令行，以便程序读取环境变量中保存的值。

下面是一个通过环境变量来使用 Secret 的示例 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
            optional: false # 此值为默认值；意味着 "mysecret"
                            # 必须存在且包含名为 "username" 的主键
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
            optional: false # 此值为默认值；意味着 "mysecret"
                            # 必须存在且包含名为 "password" 的主键
  restartPolicy: Never

非法环境变量 

对于通过 ​envFrom ​字段来填充环境变量的 Secret 而言， 如果其中包含的主键不能被当做合法的环境变量名，这些主键会被忽略掉。 Pod 仍然可以启动。

如果你定义的 Pod 中包含非法的变量名称，则 Pod 可能启动失败， 会形成 reason 为 ​InvalidVariableNames ​的事件，以及列举被略过的非法主键的消息。 下面的例子中展示了一个 Pod，引用的是名为 ​mysecret ​的 Secret， 其中包含两个非法的主键：​1badkey ​和 ​2alsobad​。

kubectl get events


    

输出类似于：

LASTSEEN   FIRSTSEEN   COUNT     NAME            KIND      SUBOBJECT                         TYPE      REASON
0s         0s          1         dapi-test-pod   Pod                                         Warning   InvalidEnvironmentVariableNames   kubelet, 127.0.0.1      Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names.

通过环境变量使用 Secret 值

在通过环境变量来使用 Secret 的容器中，Secret 主键展现为普通的环境变量。 这些变量的取值是 Secret 数据的 Base64 解码值。

下面是在前文示例中的容器内执行命令的结果：

echo "$SECRET_USERNAME"

输出类似于：

admin

echo "$SECRET_PASSWORD"

输出类似于：

1f2d1e2e67df

Note:
如果容器已经在通过环境变量来使用 Secret，Secret 更新在容器内是看不到的， 除非容器被重启。有一些第三方的解决方案，能够在 Secret 发生变化时触发容器重启。

容器镜像拉取 Secret 

如果你尝试从私有仓库拉取容器镜像，你需要一种方式让每个节点上的 kubelet 能够完成与镜像库的身份认证。你可以配置 镜像拉取 Secret 来实现这点。 Secret 是在 Pod 层面来配置的。

Pod 的 ​imagePullSecrets ​字段是一个对 Pod 所在的名字空间中的 Secret 的引用列表。你可以使用 ​imagePullSecrets ​来将镜像仓库访问凭据传递给 kubelet。 kubelet 使用这个信息来替你的 Pod 拉取私有镜像。

使用 imagePullSecrets

​imagePullSecrets ​字段是一个列表，包含对同一名字空间中 Secret 的引用。 你可以使用 ​imagePullSecrets ​将包含 Docker（或其他）镜像仓库密码的 Secret 传递给 kubelet。kubelet 使用此信息来替 Pod 拉取私有镜像。

手动设定 imagePullSecret

你可以通过阅读容器镜像 文档了解如何设置 ​imagePullSecrets​。

设置 imagePullSecrets 为自动挂载

你可以手动创建 ​imagePullSecret​，并在一个 ServiceAccount 中引用它。 对使用该 ServiceAccount 创建的所有 Pod，或者默认使用该 ServiceAccount 创建的 Pod 而言，其 ​imagePullSecrets ​字段都会设置为该服务账号。

在静态 Pod 中使用 Secret 

你不可以在静态 Pod. 中使用 ConfigMap 或 Secret。

使用场景 

使用场景：作为容器环境变量

创建 Secret：

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  USER_NAME: YWRtaW4=
  PASSWORD: MWYyZDFlMmU2N2Rm

创建 Secret：

kubectl apply -f mysecret.yaml

使用 ​envFrom ​来将 Secret 的所有数据定义为容器的环境变量。 来自 Secret 的主键成为 Pod 中的环境变量名称：

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      command: [ "/bin/sh", "-c", "env" ]
      envFrom:
      - secretRef:
          name: mysecret
  restartPolicy: Never

使用场景：带 SSH 密钥的 Pod

创建包含一些 SSH 密钥的 Secret：

kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub

输出类似于：

secret "ssh-key-secret" created

你也可以创建一个 ​kustomization.yaml​ 文件，在其 ​secretGenerator ​字段中包含 SSH 密钥。

Caution:
在提供你自己的 SSH 密钥之前要仔细思考：集群的其他用户可能有权访问该 Secret。
你也可以创建一个 SSH 私钥，代表一个你希望与你共享 Kubernetes 集群的其他用户分享的服务标识。 当凭据信息被泄露时，你可以收回该访问权限。

现在你可以创建一个 Pod，在其中访问包含 SSH 密钥的 Secret，并通过卷的方式来使用它：

apiVersion: v1
kind: Pod
metadata:
  name: secret-test-pod
  labels:
    name: secret-test
spec:
  volumes:
  - name: secret-volume
    secret:
      secretName: ssh-key-secret
  containers:
  - name: ssh-test-container
    image: mySshImage
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/etc/secret-volume"

容器命令执行时，秘钥的数据可以在下面的位置访问到：

/etc/secret-volume/ssh-publickey
/etc/secret-volume/ssh-privatekey

容器就可以随便使用 Secret 数据来建立 SSH 连接。

使用场景：带有生产、测试环境凭据的 Pod 

这一示例所展示的一个 Pod 会使用包含生产环境凭据的 Secret，另一个 Pod 使用包含测试环境凭据的 Secret。

你可以创建一个带有 ​secretGenerator ​字段的 ​kustomization.yaml​ 文件或者运行 ​kubectl create secret​ 来创建 Secret。

kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11

输出类似于：

secret "prod-db-secret" created

你也可以创建一个包含测试环境凭据的 Secret：

kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests

输出类似于：

secret "test-db-secret" created

Note:
特殊字符（例如 ​$​、​\​、​*​、​=​ 和 ​!​）会被你的 Shell解释，因此需要转义。
在大多数 Shell 中，对密码进行转义的最简单方式是用单引号（​'​）将其括起来。 例如，如果你的实际密码是 ​S!B\*d$zDsb​，则应通过以下方式执行命令：

kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb='

你无需对文件中的密码（​--from-file​）中的特殊字符进行转义。

现在生成 Pod：

cat <<EOF > pod.yaml
apiVersion: v1
kind: List
items:
- kind: Pod
  apiVersion: v1
  metadata:
    name: prod-db-client-pod
    labels:
      name: prod-db-client
  spec:
    volumes:
    - name: secret-volume
      secret:
        secretName: prod-db-secret
    containers:
    - name: db-client-container
      image: myClientImage
      volumeMounts:
      - name: secret-volume
        readOnly: true
        mountPath: "/etc/secret-volume"
- kind: Pod
  apiVersion: v1
  metadata:
    name: test-db-client-pod
    labels:
      name: test-db-client
  spec:
    volumes:
    - name: secret-volume
      secret:
        secretName: test-db-secret
    containers:
    - name: db-client-container
      image: myClientImage
      volumeMounts:
      - name: secret-volume
        readOnly: true
        mountPath: "/etc/secret-volume"
EOF

将 Pod 添加到同一 ​kustomization.yaml​ 文件中：

cat <<EOF >> kustomization.yaml
resources:
- pod.yaml
EOF

通过下面的命令在 API 服务器上应用所有这些对象：

kubectl apply -k .

两个文件都会在其文件系统中出现下面面的文件，文件中内容是各个容器的环境值：

/etc/secret-volume/username
/etc/secret-volume/password

注意这两个 Pod 的规约中只有一个字段不同。 这便于基于相同的 Pod 模板生成具有不同能力的 Pod。

你可以通过使用两个服务账号来进一步简化这一基本的 Pod 规约：

1. ​prod-user​ 服务账号使用 ​prod-db-secret ​
2. ​test-user​ 服务账号使用 ​test-db-secret ​

Pod 规约简化为：

apiVersion: v1
kind: Pod
metadata:
  name: prod-db-client-pod
  labels:
    name: prod-db-client
spec:
  serviceAccount: prod-db-client
  containers:
  - name: db-client-container
    image: myClientImage

使用场景：在 Secret 卷中带句点的文件 

通过定义以句点（​.​）开头的主键，你可以“隐藏”你的数据。 这些主键代表的是以句点开头的文件或“隐藏”文件。 例如，当下面的 Secret 被挂载到 ​secret-volume​ 卷中时：

apiVersion: v1
kind: Secret
metadata:
  name: dotfile-secret
data:
  .secret-file: dmFsdWUtMg0KDQo=
---
apiVersion: v1
kind: Pod
metadata:
  name: secret-dotfiles-pod
spec:
  volumes:
  - name: secret-volume
    secret:
      secretName: dotfile-secret
  containers:
  - name: dotfile-test-container
    image: k8s.gcr.io/busybox
    command:
    - ls
    - "-l"
    - "/etc/secret-volume"
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/etc/secret-volume"

卷中会包含一个名为 ​.secret-file​ 的文件，并且容器 ​dotfile-test-container​ 中此文件位于路径 ​/etc/secret-volume/.secret-file​ 处。

Note:
以句点开头的文件会在 ​ls -l​ 的输出中被隐藏起来； 列举目录内容时你必须使用 ​ls -la​ 才能看到它们。

使用场景：仅对 Pod 中一个容器可见的 Secret 

考虑一个需要处理 HTTP 请求，执行某些复杂的业务逻辑，之后使用 HMAC 来对某些消息进行签名的程序。因为这一程序的应用逻辑很复杂， 其中可能包含未被注意到的远程服务器文件读取漏洞， 这种漏洞可能会把私钥暴露给攻击者。

这一程序可以分隔成两个容器中的两个进程：前端容器要处理用户交互和业务逻辑， 但无法看到私钥；签名容器可以看到私钥，并对来自前端的简单签名请求作出响应 （例如，通过本地主机网络）。

采用这种划分的方法，攻击者现在必须欺骗应用服务器来做一些其他操作， 而这些操作可能要比读取一个文件要复杂很多。

Secret 的类型 

创建 Secret 时，你可以使用 Secret 资源的 ​type ​字段，或者与其等价的 ​kubectl ​命令行参数（如果有的话）为其设置类型。 Secret 类型有助于对 Secret 数据进行编程处理。

Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。 针对这些类型，Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。

内置类型	用法
Opaque	用户定义的任意数据
kubernetes.io/service-account-token	服务账号令牌
kubernetes.io/dockercfg	~/.dockercfg 文件的序列化形式
kubernetes.io/dockerconfigjson	~/.docker/config.json 文件的序列化形式
kubernetes.io/basic-auth	用于基本身份认证的凭据
kubernetes.io/ssh-auth	用于 SSH 身份认证的凭据
kubernetes.io/tls	用于 TLS 客户端或者服务器端的数据
bootstrap.kubernetes.io/token	启动引导令牌数据

通过为 Secret 对象的 ​type ​字段设置一个非空的字符串值，你也可以定义并使用自己 Secret 类型。如果 ​type ​值为空字符串，则被视为 ​Opaque ​类型。

Kubernetes 并不对类型的名称作任何限制。不过，如果你要使用内置类型之一， 则你必须满足为该类型所定义的所有要求。

如果你要定义一种公开使用的 Secret 类型，请遵守 Secret 类型的约定和结构， 在类型名签名添加域名，并用 ​/​ 隔开。 例如：​cloud-hosting.example.net/cloud-api-credentials​。

Opaque Secret 

当 Secret 配置文件中未作显式设定时，默认的 Secret 类型是 ​Opaque​。 当你使用 ​kubectl ​来创建一个 Secret 时，你会使用 ​generic ​子命令来标明 要创建的是一个 ​Opaque ​类型 Secret。 例如，下面的命令会创建一个空的 ​Opaque ​类型 Secret 对象：

kubectl create secret generic empty-secret
kubectl get secret empty-secret
        

输出类似于

NAME           TYPE     DATA   AGE
empty-secret   Opaque   0      2m6s

​DATA ​列显示 Secret 中保存的数据条目个数。 在这个例子种，​0​ 意味着我们刚刚创建了一个空的 Secret。

服务账号令牌 Secret 

类型为 ​kubernetes.io/service-account-token​ 的 Secret 用来存放标识某 服务账号的令牌。 使用这种 Secret 类型时，你需要确保对象的注解 ​kubernetes.io/service-account-name​ 被设置为某个已有的服务账号名称。某个 Kubernetes 控制器会填写 Secret 的其它字段，例如 ​kubernetes.io/service-account.uid​ 注解以及 ​data ​字段中的 ​token ​键值，使之包含实际的令牌内容。

下面的配置实例声明了一个服务账号令牌 Secret：

apiVersion: v1
kind: Secret
metadata:
  name: secret-sa-sample
  annotations:
    kubernetes.io/service-account.name: "sa-name"
type: kubernetes.io/service-account-token
data:
  # 你可以像 Opaque Secret 一样在这里添加额外的键/值偶对
  extra: YmFyCg==

Kubernetes 在创建 Pod 时会自动创建一个服务账号 Secret 并自动修改你的 Pod 以使用该 Secret。该服务账号令牌 Secret 中包含了访问 Kubernetes API 所需要的凭据。

如果需要，可以禁止或者重载这种自动创建并使用 API 凭据的操作。 不过，如果你仅仅是希望能够安全地访问 API 服务器，这是建议的工作方式。

Docker 配置 Secret 

你可以使用下面两种 ​type ​值之一来创建 Secret，用以存放访问 Docker 仓库 来下载镜像的凭据。

• ​kubernetes.io/dockercfg ​
• ​kubernetes.io/dockerconfigjson​

​kubernetes.io/dockercfg​ 是一种保留类型，用来存放 ​~/.dockercfg​ 文件的序列化形式。 该文件是配置 Docker 命令行的一种老旧形式。使用此 Secret 类型时，你需要确保 Secret 的 ​data ​字段中包含名为 ​.dockercfg​ 的主键，其对应键值是用 base64 编码的某 ​~/.dockercfg​ 文件的内容。

类型 ​kubernetes.io/dockerconfigjson​ 被设计用来保存 JSON 数据的序列化形式， 该 JSON 也遵从 ​~/.docker/config.json​ 文件的格式规则，而后者是 ​~/.dockercfg​ 的新版本格式。使用此 Secret 类型时，Secret 对象的 ​data ​字段必须包含 ​.dockerconfigjson​ 键，其键值为 base64 编码的字符串包含 ​~/.docker/config.json​ 文件的内容。

下面是一个 ​kubernetes.io/dockercfg​ 类型 Secret 的示例：

apiVersion: v1
kind: Secret
metadata:
  name: secret-dockercfg
type: kubernetes.io/dockercfg
data:
  .dockercfg: |
        "<base64 encoded ~/.dockercfg file>"

Note:
如果你不希望执行 base64 编码转换，可以使用 ​stringData​ 字段代替。

当你使用清单文件来创建这两类 Secret 时，API 服务器会检查 ​data ​字段中是否 存在所期望的主键，并且验证其中所提供的键值是否是合法的 JSON 数据。 不过，API 服务器不会检查 JSON 数据本身是否是一个合法的 Docker 配置文件内容。

kubectl create secret docker-registry secret-tiger-docker \
  --docker-email=tiger@acme.example \
  --docker-username=tiger \
  --docker-password=pass113 \
  --docker-server=my-registry.example:5000

上面的命令创建一个类型为 ​kubernetes.io/dockerconfigjson​ 的 Secret。 如果你对 ​.data.dockerconfigjson​ 内容进行转储并执行 base64 解码：

{
  "auths": {
    "my-registry.example:5000": {
      "username": "tiger",
      "password": "pass113",
      "email": "tiger@acme.com",
      "auth": "dGlnZXI6cGFzczExMw=="
    }
  }
}

Note:
​auths ​值是 base64 编码的，其内容被屏蔽但未被加密。 任何能够读取该 Secret 的人都可以了解镜像库的访问令牌。

基本身份认证 Secret 

​kubernetes.io/basic-auth​ 类型用来存放用于基本身份认证所需的凭据信息。 使用这种 Secret 类型时，Secret 的 ​data ​字段必须包含以下两个键：

• ​username​: 用于身份认证的用户名；
• ​password​: 用于身份认证的密码或令牌。

以上两个键的键值都是 base64 编码的字符串。 当然你也可以在创建 Secret 时使用 ​stringData ​字段来提供明文形式的内容。 下面的 YAML 是基本身份认证 Secret 的一个示例清单：

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: admin      #  kubernetes.io/basic-auth 类型的必需字段
  password: t0p-Secret # kubernetes.io/basic-auth 类型的必需字段

提供基本身份认证类型的 Secret 仅仅是出于方便性考虑。 你也可以使用 ​Opaque ​类型来保存用于基本身份认证的凭据。 不过，使用预定义的、公开的 Secret 类型（​kubernetes.io/basic-auth​） 有助于帮助其他用户理解 Secret 的目的，并且对其中存在的主键形成一种约定。 API 服务器会检查 Secret 配置中是否提供了所需要的主键。

SSH 身份认证 Secret

Kubernetes 所提供的内置类型 ​kubernetes.io/ssh-auth​ 用来存放 SSH 身份认证中 所需要的凭据。使用这种 Secret 类型时，你就必须在其 ​data ​（或 ​stringData​） 字段中提供一个 ​ssh-privatekey​ 键值对，作为要使用的 SSH 凭据。

下面的清单是一个 SSH 公钥/私钥身份认证的 Secret 示例：

apiVersion: v1
kind: Secret
metadata:
  name: secret-ssh-auth
type: kubernetes.io/ssh-auth
data:
  # 此例中的实际数据被截断
  ssh-privatekey: |
          MIIEpQIBAAKCAQEAulqb/Y ...

提供 SSH 身份认证类型的 Secret 仅仅是出于用户方便性考虑。 你也可以使用 ​Opaque ​类型来保存用于 SSH 身份认证的凭据。 不过，使用预定义的、公开的 Secret 类型（​kubernetes.io/ssh-auth​） 有助于其他人理解你的 Secret 的用途，也可以就其中包含的主键名形成约定。 API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。

Caution:
SSH 私钥自身无法建立 SSH 客户端与服务器端之间的可信连接。 需要其它方式来建立这种信任关系，以缓解“中间人（Man In The Middle）” 攻击，例如向 ConfigMap 中添加一个 ​known_hosts ​文件。

TLS Secret

Kubernetes 提供一种内置的 ​kubernetes.io/tls Secret​ 类型，用来存放 TLS 场合通常要使用的证书及其相关密钥。 TLS Secret 的一种典型用法是为 Ingress 资源配置传输过程中的数据加密，不过也可以用于其他资源或者直接在负载中使用。 当使用此类型的 Secret 时，Secret 配置中的 ​data ​（或 ​stringData​）字段必须包含 ​tls.key​ 和 ​tls.crt​ 主键，尽管 API 服务器实际上并不会对每个键的取值作进一步的合法性检查。

下面的 YAML 包含一个 TLS Secret 的配置示例：

apiVersion: v1
kind: Secret
metadata:
  name: secret-tls
type: kubernetes.io/tls
data:
  # 此例中的数据被截断
  tls.crt: |
        MIIC2DCCAcCgAwIBAgIBATANBgkqh ...
  tls.key: |
        MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ...

提供 TLS 类型的 Secret 仅仅是出于用户方便性考虑。 你也可以使用 ​Opaque ​类型来保存用于 TLS 服务器与/或客户端的凭据。 不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。

当使用 ​kubectl ​来创建 TLS Secret 时，你可以像下面的例子一样使用 ​tls ​子命令：

kubectl create secret tls my-tls-secret \
  --cert=path/to/cert/file \
  --key=path/to/key/file

这里的公钥/私钥对都必须事先已存在。用于 ​--cert​ 的公钥证书必须是 RFC 7468 中 5.1 节 中所规定的 DER 格式，且与 ​--key​ 所给定的私钥匹配。 私钥必须是 DER 格式的 PKCS #8 （参见  RFC 7468 第 11节）。

Note:
类型为 ​kubernetes.io/tls​ 的 Secret 中包含密钥和证书的 DER 数据，以 Base64 格式编码。 如果你熟悉私钥和证书的 PEM 格式，base64 与该格式相同，只是你需要略过 PEM 数据中所包含的第一行和最后一行。
例如，对于证书而言，你 不要 包含 ​--------BEGIN CERTIFICATE-----​ 和 ​-------END CERTIFICATE----​ 这两行。

启动引导令牌 Secret 

通过将 Secret 的 ​type ​设置为 ​bootstrap.kubernetes.io/token​ 可以创建 启动引导令牌类型的 Secret。这种类型的 Secret 被设计用来支持节点的启动引导过程。 其中包含用来为周知的 ConfigMap 签名的令牌。

启动引导令牌 Secret 通常创建于 ​kube-system​ 名字空间内，并以 ​bootstrap-token-<令牌 ID> ​的形式命名；其中 ​<令牌 ID>​ 是一个由 6 个字符组成 的字符串，用作令牌的标识。

以 Kubernetes 清单文件的形式，某启动引导令牌 Secret 可能看起来像下面这样：

apiVersion: v1
kind: Secret
metadata:
  name: bootstrap-token-5emitj
  namespace: kube-system
type: bootstrap.kubernetes.io/token
data:
  auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4=
  expiration: MjAyMC0wOS0xM1QwNDozOToxMFo=
  token-id: NWVtaXRq
  token-secret: a3E0Z2lodnN6emduMXAwcg==
  usage-bootstrap-authentication: dHJ1ZQ==
  usage-bootstrap-signing: dHJ1ZQ==

启动引导令牌类型的 Secret 会在 ​data ​字段中包含如下主键：

• ​token-id​：由 6 个随机字符组成的字符串，作为令牌的标识符。必需。
• ​token-secret​：由 16 个随机字符组成的字符串，包含实际的令牌机密。必需。
• ​description​：供用户阅读的字符串，描述令牌的用途。可选。
• ​expiration​：一个使用 RFC3339 来编码的 UTC 绝对时间，给出令牌要过期的时间。可选。
• ​usage-bootstrap-<usage>​：布尔类型的标志，用来标明启动引导令牌的其他用途。
• ​auth-extra-groups​：用逗号分隔的组名列表，身份认证时除被认证为 system:bootstrappers 组之外，还会被添加到所列的用户组中。

上面的 YAML 文件可能看起来令人费解，因为其中的数值均为 base64 编码的字符串。 实际上，你完全可以使用下面的 YAML 来创建一个一模一样的 Secret：

apiVersion: v1
kind: Secret
metadata:
  # 注意 Secret 的命名方式
  name: bootstrap-token-5emitj
  # 启动引导令牌 Secret 通常位于 kube-system 名字空间
  namespace: kube-system
type: bootstrap.kubernetes.io/token
stringData:
  auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token"
  expiration: "2020-09-13T04:39:10Z"
  # 此令牌 ID 被用于生成 Secret 名称
  token-id: "5emitj"
  token-secret: "kq4gihvszzgn1p0r"
  # 此令牌还可用于 authentication （身份认证）
  usage-bootstrap-authentication: "true"
  # 且可用于 signing （证书签名）
  usage-bootstrap-signing: "true"

不可更改的 Secret 

FEATURE STATE: Kubernetes v1.21 [stable]

Kubernetes 允许你将特定的 Secret（和 ConfigMap）标记为 不可更改（Immutable）。 禁止更改现有 Secret 的数据有下列好处：

• 防止意外（或非预期的）更新导致应用程序中断
• （对于大量使用 Secret 的集群而言，至少数万个不同的 Secret 供 Pod 挂载）， 通过将 Secret 标记为不可变，可以极大降低 kube-apiserver 的负载，提升集群性能。 kubelet 不需要监视那些被标记为不可更改的 Secret。

将 Secret 标记为不可更改 

你可以通过将 Secret 的 ​immutable ​字段设置为 ​true ​创建不可更改的 Secret。 例如：

apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
immutable: true

你也可以更改现有的 Secret，令其不可更改。

Note:
一旦一个 Secret 或 ConfigMap 被标记为不可更改，撤销此操作或者更改 ​data ​字段的内容都是 不 可能的。 只能删除并重新创建这个 Secret。现有的 Pod 将维持对已删除 Secret 的挂载点 -- 建议重新创建这些 Pod。

Secret 的信息安全问题

尽管 ConfigMap 和 Secret 的工作方式类似，但 Kubernetes 对 Secret 有一些额外的保护。

Secret 通常保存重要性各异的数值，其中很多都可能会导致 Kubernetes 中 （例如，服务账号令牌）或对外部系统的特权提升。 即使某些个别应用能够推导它期望使用的 Secret 的能力， 同一名字空间中的其他应用可能会让这种假定不成立。

只有当某个节点上的 Pod 需要某 Secret 时，对应的 Secret 才会被发送到该节点上。 如果将 Secret 挂载到 Pod 中，kubelet 会将数据的副本保存在在 ​tmpfs ​中， 这样机密的数据不会被写入到持久性存储中。 一旦依赖于该 Secret 的 Pod 被删除，kubelet 会删除来自于该 Secret 的机密数据的本地副本。

同一个 Pod 中可能包含多个容器。默认情况下，你所定义的容器只能访问默认 ServiceAccount 及其相关 Secret。你必须显式地定义环境变量或者将卷映射到容器中，才能为容器提供对其他 Secret 的访问。

针对同一节点上的多个 Pod 可能有多个 Secret。不过，只有某个 Pod 所请求的 Secret 才有可能对 Pod 中的容器可见。因此，一个 Pod 不会获得访问其他 Pod 的 Secret 的权限。

Warning:
节点上的所有特权容器都可能访问到该节点上使用的所有 Secret。

针对开发人员的安全性建议 

• 应用在从环境变量或卷中读取了机密信息内容之后仍要对其进行保护。例如， 你的应用应该避免用明文的方式将 Secret 数据写入日志，或者将其传递给不可信的第三方。
• 如果你在一个 Pod 中定义了多个容器，而只有一个容器需要访问某 Secret， 定义卷挂载或环境变量配置时，应确保其他容器无法访问该 Secret。
• 如果你通过清单来配置某 Secret， Secret 数据以 Base64 的形式编码，将此文件共享，或者将其检入到某源码仓库， 都意味着 Secret 对于任何可以读取清单的人都是可见的。 Base64 编码 不是 一种加密方法，与明文相比没有任何安全性提升。
• 部署与 Secret API 交互的应用时，你应该使用 RBAC 这类鉴权策略来限制访问。
• 在 Kubernetes API 中，名字空间内对 Secret 对象的 ​watch ​和 ​list ​请求是非常强大的能力。 在可能的时候应该避免授予这类访问权限，因为通过列举 Secret， 客户端能够查看对应名字空间内所有 Secret 的取值。

针对集群管理员的安全性建议

Caution:
能够创建使用 Secret 的 Pod 的用户也可以查看该 Secret 的取值。 即使集群策略不允许某用户直接读取 Secret 对象，这一用户仍然可以通过运行一个 Pod 来访问 Secret 的内容。

• 保留（使用 Kubernetes API）对集群中所有 Secret 对象执行 ​watch ​或 ​list ​操作的能力， 这样只有特权级最高、系统级别的组件能够执行这类操作。
• 在部署需要通过 Secret API 交互的应用时，你应该通过使用 RBAC 这类鉴权策略来限制访问。
• 在 API 服务器上，对象（包括 Secret）会被持久化到 etcd 中； 因此：
• 只应准许集群管理员访问 etcd（包括只读访问）；
• 为 Secret 对象启用静态加密， 这样这些 Secret 的数据就不会以明文的形式保存到 etcd 中；
• 当 etcd 的持久化存储不再被使用时，请考虑彻底擦除存储介质；
• 如果存在多个 etcd 实例，请确保 etcd 使用 SSL/TLS 来完成其对等通信。