k8s secret
Secret 概览 ^
secret 卷用来给 Pod 传递敏感信息，例如密码。你可以将 Secret 存储在 Kubernetes API 服务器上，然后以文件的形式挂在到 Pod 中，无需直接与 Kubernetes 耦合。
Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。
由于创建 Secret 可以独立于使用它们的 Pod， 因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。 Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施， 例如避免将机密数据写入非易失性存储。
Secret 类似于 ConfigMap 但专门用于保存机密数据。
说明：
- 使用前你必须在 Kubernetes API 中创建 secret。
- 容器以 subPath 卷挂载方式挂载 Secret 时，将感知不到 Secret 的更新。
要使用 Secret，Pod 需要引用 Secret。 Pod 可以用三种方式之一来使用 Secret：
- 作为挂载到一个或多个容器上的 卷 中的文件。
- 作为容器的环境变量
- 由 kubelet 在为 Pod 拉取镜像时使用
Kubernetes 控制平面也使用 Secret； 例如，引导令牌 Secret 是一种帮助自动化节点注册的机制。
Secret 对象的名称必须是合法的 DNS 子域名。 在为创建 Secret 编写配置文件时，你可以设置 data 与/或 stringData 字段。 data 和 stringData 字段都是可选的。data 字段中所有键值都必须是 base64 编码的字符串。如果不希望执行这种 base64 字符串的转换操作，你可以选择设置 stringData 字段，其中可以使用任何字符串作为其取值。
Secret 的类型
创建 Secret 时，你可以使用 Secret 资源的 type 字段， 或者与其等价的 kubectl 命令行参数（如果有的话）为其设置类型。 Secret 的 type 有助于对不同类型机密数据的编程处理。
Secret 主要使用的有以下几种类型：
Opaque： 用户定义的任意数据。base64 编码格式的 Secret，用来存储密码、密钥等；但数据也可以通过base64 –decode解码得到原始数据，所有加密性很弱。kubernetes.io/dockercfg:~/.dockercfg文件的序列化形式kubernetes.io/dockerconfigjson：用来存储私有docker registry的认证信息，~/.docker/config.json文件的序列化形式kubernetes.io/service-account-token：服务账号令牌。用于ServiceAccount, ServiceAccount 创建时 Kubernetes 会默认创建一个对应的 Secret 对象，Pod 如果使用了 ServiceAccount，对应的 Secret 会自动挂载到 Pod 目录/run/secrets/kubernetes.io/serviceaccount中kubernetes.io/ssh-auth：用于 SSH 身份认证的凭据kubernetes.io/basic-auth：用于基本身份认证的凭据kubernetes.io/tls: 用于 TLS 客户端或者服务器端的数据bootstrap.kubernetes.io/token：用于节点接入集群的校验
通过为 Secret 对象的 type 字段设置一个非空的字符串值，你也可以定义并使用自己 Secret 类型。如果 type 值为空字符串，则被视为 Opaque 类型。 Kubernetes 并不对类型的名称作任何限制。不过，如果你要使用内置类型之一， 则你必须满足为该类型所定义的所有要求。
Opaque Secret
当 Secret 配置文件中未作显式设定时，默认的 Secret 类型是 Opaque。 当你使用 kubectl 来创建一个 Secret 时，你会使用 generic 子命令来标明 要创建的是一个 Opaque 类型 Secret。 例如，下面的命令会创建一个空的 Opaque 类型 Secret 对象：
1 | kubectl create secret generic empty-secret |
输出类似于
1 | NAME TYPE DATA AGE |
DATA 列显示 Secret 中保存的数据条目个数。 在这个例子种，0 意味着我们刚刚创建了一个空的 Secret。
Docker 配置 Secret
kubernetes.io/basic-auth
该类型用来存放用于基本身份认证所需的凭据信息，使用这种 Secret 类型时，Secret 的 data 字段必须包含以下两个键：
username: 用于身份认证的用户名password: 用于身份认证的密码或令牌
以上两个键的键值都是 base64 编码的字符串。 然你也可以在创建 Secret 时使用 stringData 字段来提供明文形式的内容。下面的 YAML 是基本身份认证 Secret 的一个示例清单：
1 | apiVersion: v1 |
提供基本身份认证类型的 Secret 仅仅是出于用户方便性考虑，我们也可以使用 Opaque 类型来保存用于基本身份认证的凭据。不过使用内置的 Secret 类型的有助于对凭据格式进行统一处理，并且 API 服务器也会检查 Secret 配置中是否提供了所需要的主键。
kubernetes.io/ssh-auth
该类型用来存放 SSH 身份认证中所需要的凭据，使用这种 Secret 类型时，你就必须在其 data（或 stringData）字段中提供一个 ssh-privatekey 键值对，作为要使用的 SSH 凭据。
如下所示是一个 SSH 身份认证 Secret 的配置示例：
1 | apiVersion: v1 |
同样提供 SSH 身份认证类型的 Secret 也仅仅是出于用户方便性考虑，我们也可以使用 Opaque 类型来保存用于 SSH 身份认证的凭据，只是使用内置的 Secret 类型的有助于对凭据格式进行统一处理，并且 API 服务器也会检查 Secret 配置中是否提供了所需要的主键。
TLS Secret
Kubernetes 提供一种内置的 kubernetes.io/tls Secret 类型，用来存放证书 及其相关密钥（通常用在 TLS 场合）。 此类数据主要提供给 Ingress 资源，用以终结 TLS 链接，不过也可以用于其他 资源或者负载。当使用此类型的 Secret 时，Secret 配置中的 data （或 stringData）字段必须包含 tls.key 和 tls.crt 主键，尽管 API 服务器 实际上并不会对每个键的取值作进一步的合法性检查。
下面的 YAML 包含一个 TLS Secret 的配置示例：
1 | apiVersion: v1 |
提供 TLS 类型的 Secret 仅仅是出于用户方便性考虑。 你也可以使用 Opaque 类型来保存用于 TLS 服务器与/或客户端的凭据。 不过，使用内置的 Secret 类型的有助于对凭据格式进行归一化处理，并且 API 服务器确实会检查 Secret 配置中是否提供了所需要的主键。
当使用 kubectl 来创建 TLS Secret 时，你可以像下面的例子一样使用 tls 子命令：
1 | kubectl create secret tls my-tls-secret \ |
这里的公钥/私钥对都必须事先已存在。用于 --cert 的公钥证书必须是 .PEM 编码的 （Base64 编码的 DER 格式），且与 --key 所给定的私钥匹配。 私钥必须是通常所说的 PEM 私钥格式，且未加密。对这两个文件而言，PEM 格式数据 的第一行和最后一行（例如，证书所对应的 --------BEGIN CERTIFICATE----- 和 -------END CERTIFICATE----）都不会包含在其中。
kubernetes.io/service-account-token
类型为 kubernetes.io/service-account-token 的 Secret 用来存放标识某 服务账号的令牌。使用这种 Secret 类型时，你需要确保对象的注解 kubernetes.io/service-account-name 被设置为某个已有的服务账号名称。 某个 Kubernetes 控制器会填写 Secret 的其它字段，例如 kubernetes.io/service-account.uid 注解以及 data 字段中的 token 键值，使之包含实际的令牌内容。
下面的配置实例声明了一个服务账号令牌 Secret：
1 | apiVersion: v1 |
Kubernetes 在创建 Pod 时会自动创建一个服务账号 Secret 并自动修改你的 Pod 以使用该 Secret。该服务账号令牌 Secret 中包含了访问 Kubernetes API 所需要的凭据。
如果需要，可以禁止或者重载这种自动创建并使用 API 凭据的操作。 不过，如果你仅仅是希望能够安全地访问 API 服务器，这是建议的工作方式。
参考 ServiceAccount 文档了解服务账号的工作原理。你也可以查看 Pod 资源中的 automountServiceAccountToken 和 serviceAccountName 字段文档，了解 从 Pod 中引用服务账号。
bootstrap.kubernetes.io/token
通过将 Secret 的 type 设置为 bootstrap.kubernetes.io/token 可以创建 启动引导令牌类型的 Secret。这种类型的 Secret 被设计用来支持节点的启动引导过程。 其中包含用来为周知的 ConfigMap 签名的令牌。
启动引导令牌 Secret 通常创建于 kube-system 名字空间内，并以 bootstrap-token-<令牌 ID> 的形式命名；其中 <令牌 ID> 是一个由 6 个字符组成 的字符串，用作令牌的标识。
以 Kubernetes 清单文件的形式，某启动引导令牌 Secret 可能看起来像下面这样：
1 | apiVersion: v1 |
启动引导令牌类型的 Secret 会在 data 字段中包含如下主键：
token-id：由 6 个随机字符组成的字符串，作为令牌的标识符。必需。token-secret：由 16 个随机字符组成的字符串，包含实际的令牌机密。必需。description：供用户阅读的字符串，描述令牌的用途。可选。expiration：一个使用 RFC3339 来编码的 UTC 绝对时间，给出令牌要过期的时间。可选。usage-bootstrap-<usage>：布尔类型的标志，用来标明启动引导令牌的其他用途。auth-extra-groups：用逗号分隔的组名列表，身份认证时除被认证为system:bootstrappers组之外，还会被添加到所列的用户组中。
上面的 YAML 文件可能看起来令人费解，因为其中的数值均为 base64 编码的字符串。 实际上，你完全可以使用下面的 YAML 来创建一个一模一样的 Secret：
1 | apiVersion: v1 |
