Kubernetes-Secret

1. 简介

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

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

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

2. 4种创建方式

$ kubectl create secret -h
Create a secret using specified subcommand.

Available Commands:
  docker-registry 创建一个给 Docker registry 使用的 secret
  generic         从本地 file, directory 或者 literal value 创建一个 secret
  tls             创建一个 TLS secret

2.1 通过key-value创建

$ kubectl create secret generic secret-test-1 --from-literal=username=zhangtieniu --from-literal=password=123456

还有种简单的创建方式创建此种类型的ConfigMap

$ kubectl create secret generic secret-test-1 --from-env-file=./secret-env.txt

2.2 通过配置文件创建

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

2.3 通过配置文件的目录创建

$ kubectl create secret generic ssh-key-secret   --from-file=./

2.4 直接编写Secret文件

在创建 Secret 编写配置文件时，你可以设置 data 与/或 stringData 字段。 data 和 stringData 字段都是可选的。

data 字段中所有键值都必须是 base64 编码的字符串。

如果不希望执行这种 base64 字符串的转换操作，你可以选择设置 stringData 字段，其中可以使用任何字符串作为其取值。

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

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

在创建 Secret 时使用 stringData 字段来提供明文形式的内容。下面的 YAML 是基本身份认证 Secret 的一个示例清单：

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: zhangtieniu
  # 值必须为string类型，所以数值类型的密码必须加引号
  password: "123456"

直接编写secret data文件如下

apiVersion: v1
data:
  password: MTIzNDU2
  username: emhhbmd0aWVuaXU=
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth

3. 查看/解密secret信息

secret信息默认是使用base64加密的，所以可以通过base64解密来查看secret配置的auth信息

shell base64

加密：

base64 file

$ echo Hello World | base64
SGVsbG8gV29ybGQK

解密：

$ echo SGVsbG8gV29ybGQK | base64 -d
Hello World

4. secret type

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

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

4.1 Opaque

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

$ kubectl create secret generic test-secret

4.2 dockercfg/dockerconfigjson

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

kubernetes.io/dockercfg：旧版的docker login之后会在服务器上生成配置文件~/.dockercfg，用来记录docker仓库的auth信息
kubernetes.io/dockerconfigjson：新版的docker login之后会在服务器上生成配置文件~/.docker/config.json，用来记录docker仓库的auth信息

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>"

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

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

kubectl create secret docker-registry secret-tiger-docker \
  --docker-username=tiger \
  --docker-password=pass113 \
  --docker-email=tiger@acme.com

上面的命令创建一个类型为 kubernetes.io/dockerconfigjson 的 Secret。如果你对 data 字段中的 .dockerconfigjson 内容进行转储，你会得到下面的 JSON 内容，而这一内容是一个合法的 Docker 配置文件。

{
  "auths": {
    "https://index.docker.io/v1/": {
      "username": "tiger",
      "password": "pass113",
      "email": "tiger@acme.com",
      "auth": "dGlnZXI6cGFzczExMw=="
    }
  }
}

4.3 basic-auth

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
  password: t0p-Secret

提供基本身份认证类型的 Secret 仅仅是出于用户方便性考虑。你也可以使用 Opaque 类型来保存用于基本身份认证的凭据。

不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。

4.4 ssh-auth

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

下面的 YAML 是一个 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 类型的有助于对凭据格式进行归一化处理，并且 API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。

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

4.5 tls

Kubernetes 提供一种内置的 kubernetes.io/tls Secret 类型，用来存放证书及其相关密钥（通常用在 TLS 场合）。此类数据主要提供给 Ingress 资源，用以终结 TLS 链接，不过也可以用于其他资源或者负载。当使用此类型的 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 的公钥证书必须是 .PEM 编码的（Base64 编码的 DER 格式），且与 --key 所给定的私钥匹配。私钥必须是通常所说的 PEM 私钥格式，且未加密。对这两个文件而言，PEM 格式数据的第一行和最后一行（例如，证书所对应的 --------BEGIN CERTIFICATE----- 和 -------END CERTIFICATE----）都不会包含在其中。

5. 2种挂载方式

5.1 通过volume方式挂载

这里使用2.4创建的secret进行挂载

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
    imagePullPolicy: IfNotPresent
  volumes:
  - name: foo
    secret:
      secretName: secret-basic-auth

将 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
    imagePullPolicy: IfNotPresent
  volumes:
  - name: foo
    secret:
      secretName: secret-basic-auth
      items:
      - key: username
        path: my-group/my-username

将会发生什么呢：

username Secret 存储在 /etc/foo/my-group/my-username 文件中而不是 /etc/foo/username 中。
password Secret 没有被映射

如果使用了 spec.volumes[].secret.items，只有在 items 中指定的键会被映射。要使用 Secret 中所有键，就必须将它们都列在 items 字段中。所有列出的键名必须存在于相应的 Secret 中。否则，不会创建卷。

5.2 通过环境变量方式挂载

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: mycontainer
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: secret-basic-auth
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: secret-basic-auth
            key: password
    imagePullPolicy: IfNotPresent
  restartPolicy: Never

Secret 更新之后对应的环境变量不会被更新

如果某个容器已经在通过环境变量使用某 Secret，对该 Secret 的更新不会被容器马上看见，除非容器被重启。有一些第三方的解决方案能够在 Secret 发生变化时触发容器重启。

6. docker-registry auth

如4.2中描述的，可以使用以下的方式创建docker-registry secret

6.1 直接创建docker-registry secret

创建 Secret，命名为 regcred：

kubectl create secret docker-registry regcred \
  --docker-server=<你的镜像仓库服务器> \
  --docker-username=<你的用户名> \
  --docker-password=<你的密码> \
  --docker-email=<你的邮箱地址>

在这里：

<your-registry-server> 是你的私有 Docker 仓库全限定域名（FQDN）。 DockerHub 使用 https://index.docker.io/v1/。
<your-name> 是你的 Docker 用户名。
<your-pword> 是你的 Docker 密码。
<your-email> 是你的 Docker 邮箱。

这样你就成功地将集群中的 Docker 凭证设置为名为 regcred 的 Secret。

如果已经有 Docker 凭据文件，则可以将凭据文件导入为 Kubernetes Secret，而不是执行上面的命令。基于已有的 docker 凭据创建 secret 解释了如何完成这一操作。

如果你在使用多个私有容器仓库，这种技术将特别有用。原因是 kubectl create secret docker-registry 创建的是仅适用于某个私有仓库的 Secret。

说明： Pod 只能引用位于自身所在名字空间中的 Secret，因此需要针对每个名字空间重复执行上述过程。

6.2 基于已有的 docker 凭据创建 secret

当我们直接使用 docker login 登录docker registry后，会生成~/.docker/config.json文件用于记录docker登录的auth信息

我们可以直接使用该文件来创建secret（其实在4.2中已经记录过）

4.2 中提到了，可以直接指定file地址用来创建kubernetes.io/dockerconfigjson（官方文档中摘抄的），但是本人测试时报错，可能是k8s版本的问题，但是以下的方式是经过测试没问题的

apiVersion: v1
kind: Secret
metadata:
  name: secret-dockercfg
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: ewogICJhdXRocyI6IHsKICAgICJodHRwczovL2luZGV4LmRvY2tlci5pby92MS8iOiB7CiAgICAgICJ1c2VybmFtZSI6ICJ0aWdlciIsCiAgICAgICJwYXNzd29yZCI6ICJwYXNzMTEzIiwKICAgICAgImVtYWlsIjogInRpZ2VyQGFjbWUuY29tIiwKICAgICAgImF1dGgiOiAiZEdsblpYSTZjR0Z6Y3pFeE13PT0iCiAgICB9CiAgfQp9Cg==

.dockerconfigjson 字段的值是 Docker 凭证的 base64 编码值，也就是把~/.docker/config.json 转成了base64值。

$ base64 ~/.docker/config.json
ewogICJhdXRocyI6IHsKICAgICJodHRwczovL2luZGV4LmRvY2tlci5pby92MS8iOiB7CiAgICAg
ICJ1c2VybmFtZSI6ICJ0aWdlciIsCiAgICAgICJwYXNzd29yZCI6ICJwYXNzMTEzIiwKICAgICAg
ImVtYWlsIjogInRpZ2VyQGFjbWUuY29tIiwKICAgICAgImF1dGgiOiAiZEdsblpYSTZjR0Z6Y3pF
eE13PT0iCiAgICB9CiAgfQp9Cg==

6.3 使用docker-registry secret

在创建 Pod 时，可以在 Pod 定义中增加 imagePullSecrets 部分来引用该 Secret，如下配置：

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  containers:
  - name: private-reg-container
    image: redis
  # 指定docker-registry secret
  imagePullSecrets:
  # docker-registry secret name
  - name: regcred

7. subPath

如果我们想挂载配置文件时，只覆盖指定mountPath下的指定文件（因为默认会把Secret中的信息挂载到mountPath下，此时mountPath下只有Secret的配置文件，mountPath下本来有的配置文件会被清除掉），那么需要使用subpath来指定要被覆盖的文件

我在volume的6.0中详细的写了相关的配置，感兴趣的可以了解下。

8. 挂载的 secret 会被自动更新

当已经存储于卷中被使用的 Secret 被更新时，被映射的键也将终将被更新。组件 kubelet 在周期性同步时检查被挂载的 Secret 是不是最新的。但是，它会使用其本地缓存的数值作为 Secret 的当前值。

缓存的类型可以使用 KubeletConfiguration 结构中的 ConfigMapAndSecretChangeDetectionStrategy 字段来配置。它可以通过 watch 操作来传播（默认），基于 TTL 来刷新，也可以将所有请求直接重定向到 API 服务器。因此，从 Secret 被更新到将新 Secret 被投射到 Pod 的那一刻的总延迟可能与 kubelet 同步周期 + 缓存传播延迟一样长，其中缓存传播延迟取决于所选的缓存类型。对应于不同的缓存类型，该延迟或者等于 watch 传播延迟，或者等于缓存的 TTL，或者为 0。

说明： 使用 Secret 作为子路径卷挂载的容器不会收到 Secret 更新。

9. 不可更改的 secret

Kubernetes 的特性 不可变的 Secret 和 ConfigMap 提供了一种可选配置，可以设置各个 Secret 和 ConfigMap 为不可变的。对于大量使用 Secret 的集群（至少有成千上万各不相同的 Secret 供 Pod 挂载），禁止变更它们的数据有下列好处：

防止意外（或非预期的）更新导致应用程序中断
通过将 Secret 标记为不可变来关闭 kube-apiserver 对其的监视，从而显著降低 kube-apiserver 的负载，提升集群性能。

这个特性通过 ImmutableEmphemeralVolumes 来控制，从 v1.19 开始默认启用。你可以通过将 Secret 的 immutable 字段设置为 true 创建不可更改的 Secret。例如：

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

posted @ 2022-01-25 00:45 张铁牛阅读(795) 评论(0) 编辑收藏举报

刷新页面返回顶部