Kubernetes教程

Kubernetes Secret配置

一、Secret

Secret 是 Kubernetes 中用于保存敏感信息的特殊对象。它可以包含密码、令牌、密钥等少量机密数据,并且可以被挂载到 Pod 的规约或镜像中使用。使用 Secret 的好处是,可以将机密数据与应用程序代码分离,从而增加安全性。

在创建 Secret 时,可以独立于使用该 Secret 的 Pod 进行操作。这意味着在创建、查看和编辑 Pod 的过程中,相对于 ConfigMap,Secret 的风险较小。此外,Kubernetes 和集群中的应用程序通常会采取额外的措施来保护 Secret 数据,例如避免将敏感信息写入非易失性存储。

需要注意的是,Secret 类似于 ConfigMap,但其主要目的是保存敏感数据。详情可参阅《Kubernetes ConfigMap配置》。

注意:默认情况下,Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储(etcd)中。 任何拥有 API 访问权限的人都可以检索或修改 Secret,任何有权访问 etcd 的人也可以。 此外,任何有权限在命名空间中创建 Pod 的人都可以使用该访问权限读取该命名空间中的任何 Secret; 这包括间接访问,例如创建 Deployment 的能力。

为了安全地使用 Secret,请执行以下步骤:

1、为 Secret 启用静态加密。

2、以最小特权访问 Secret 并启用或配置 RBAC 规则。

3、限制 Secret 对特定容器的访问。

4、考虑使用外部 Secret 存储驱动。

二、使用Secret

Secret 可以将用于以下场景:

  • 设置容器的环境变量;
  • 向 Pod 提供 SSH 密钥或密码等凭据;
  • 允许 kubelet 从私有镜像仓库中拉取镜像。

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

1、在 Secret 卷中带句点的文件

通过定义以句点(.)开头的主键,可以“隐藏”数据, 这些主键代表的是以句点开头的文件或“隐藏”文件。 例如,当以下 Secret 被挂载到 secret-volume 卷上时,该卷中会包含一个名为 .secret-file 的文件,并且容器 dotfile-test-container 中此文件位于路径 /etc/secret-volume/.secret-file 处。

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

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: registry.k8s.io/busybox
command:
- ls
- "-l"
- "/etc/secret-volume"
volumeMounts:
- name: secret-volume
readOnly: true
mountPath: "/etc/secret-volume"

2、仅对 Pod 中一个容器可见的 Secret

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

这一程序可以分隔成两个容器中的两个进程:前端容器要处理用户交互和业务逻辑, 但无法看到私钥,目前签名容器可以看到私钥,并对来自前端的简单签名请求作出响应 (例如,通过本地主机网络)。采用这种划分的方法,攻击者现在必须欺骗应用服务器来做一些其他操作, 而这些操作可能要比读取一个文件要复杂很多。

3、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 时可以指定 type 字段或等效的 kubectl 命令行参数来设置 Secret 的类型。这有助于对 Secret 数据进行编程处理。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。

1、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。

2、ServiceAccount 令牌 Secret

类型为 kubernetes.io/service-account-token 的 Secret 用来存放标识某 ServiceAccount 的令牌凭据,这是为 Pod 提供长期有效 ServiceAccount 凭据的传统机制。在 Kubernetes v1.22 及更高版本中,推荐的方法是通过使用 TokenRequest API 来获取短期自动轮换的 ServiceAccount 令牌。可以使用以下方法获取这些短期令牌:

直接调用 TokenRequest API,或者使用像 kubectl 这样的 API 客户端。 例如,可以使用 kubectl create token 命令;在 Pod 清单中请求使用投射卷挂载的令牌,Kubernetes 会创建令牌并将其挂载到 Pod 中;当挂载令牌的 Pod 被删除时,此令牌会自动失效。

注意:只有在无法使用 TokenRequest API 来获取令牌, 并且能够接受因为将永不过期的令牌凭据写入到可读取的 API 对象而带来的安全风险时, 才应该创建 ServiceAccount 令牌 Secret。

使用这种 Secret 类型时,需要确保对象的注解 kubernetes.io/service-account-name 被设置为某个已有的 ServiceAccount 名称, 如果同时创建 ServiceAccount 和 Secret 对象,应该先创建 ServiceAccount 对象。当 Secret 对象被创建之后,某个 Kubernetes 控制器会填写 Secret 的其它字段,例如 kubernetes.io/service-account.uid 注解和 data 字段中的 token 键值(该键包含一个身份认证令牌)。

下面的配置实例声明了一个 ServiceAccount 令牌 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:
extra: YmFyCg==

创建了 Secret 之后,等待 Kubernetes 在 data 字段中填充 token 主键。

3、Docker 配置 Secret

如果要创建 Secret 用来存放用于访问容器镜像仓库的凭据,则必须选用以下 type 值之一来创建 Secret:

  • kubernetes.io/dockercfg:存放 ~/.dockercfg 文件的序列化形式,它是配置 Docker 命令行的一种老旧形式。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: |
eyJhdXRocyI6eyJodHRwczovL2V4YW1wbGUvdjEvIjp7ImF1dGgiOiJvcGVuc2VzYW1lIn19fQo=

如果不希望执行 base64 编码转换,可以使用 stringData 字段代替。

当使用清单文件通过 Docker 配置来创建 Secret 时,Kubernetes API 服务器会对 data 字段进行检查。它会检查是否存在期望的主键,并验证提供的键值是否是合法的 JSON 数据。但是,API 服务器并不会检查 JSON 数据本身是否包含有效的 Docker 配置文件内容。

还可以使用 kubectl 创建一个 Secret 来访问容器仓库时, 当没有 Docker 配置文件时可以这样做:

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

此命令创建一个类型为 kubernetes.io/dockerconfigjson 的 Secret。

从这个新的 Secret 中获取 .data.dockerconfigjson 字段并执行数据解码:

kubectl get secret secret-tiger-docker -o jsonpath='{.data.*}' | base64 -d

输出等价于以下 JSON 文档(这也是一个有效的 Docker 配置文件):

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

注意

  • auths 值是 base64 编码的,其内容被屏蔽但未被加密。 任何能够读取该 Secret 的人都可以了解镜像库的访问令牌。
  • 建议使用凭据提供程序来动态、 安全地按需提供拉取 Secret。

4、基本身份认证 Secret

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

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

以上两个键的键值都是 base64 编码的字符串。 当然也可以在 Secret 清单中的使用 stringData 字段来提供明文形式的内容。

以下清单是基本身份验证 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 的 stringData 字段不能很好地与服务器端应用配合使用。

提供基本身份认证类型的 Secret 是为了方便使用者,虽然使用 Opaque 类型来保存基本身份认证凭据是可行的,但使用预定义的、公开的 Secret 类型(如 kubernetes.io/basic-auth)可以提供更好的可读性和一致性。这样可以使他人更容易理解 Secret 的目的,并且确保在不同环境中使用相同的主键。

5、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 的用途,并且确保在不同环境中使用相同的主键。

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

6、TLS Secret

kubernetes.io/tls Secret 类型用来存放 TLS 场合通常要使用的证书及其相关密钥。

TLS Secret 的一种典型用法是为 Ingress 资源配置传输过程中的数据加密,不过也可以用于其他资源或者直接在负载中使用。 当使用此类型的 Secret 时,Secret 配置中的 data (或 stringData)字段必须包含 tls.key 和 tls.crt 主键,尽管 API 服务器实际上并不会对每个键的取值作进一步的合法性检查。作为使用 stringData 的替代方法,可以使用 data 字段来指定 base64 编码的证书和私钥。

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

apiVersion: v1
kind: Secret
metadata:
name: secret-tls
type: kubernetes.io/tls
data:
# 值为 base64 编码,这样会掩盖它们,但不会提供任何有用的机密性级别
tls.crt: |
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWJzQ0FnMytNQTBHQ1NxR1NJYjNE
UUVCQlFVQU1JR2JNUXN3Q1FZRFZRUUdFd0pLVURFT01Bd0cKQTFVRUNCTUZWRzlyZVc4eEVEQU9C Z05WQkFjVEIwTm9kVzh0YTNVeEVUQVBCZ05WQkFvVENFWnlZVzVyTkVSRQpNUmd3RmdZRFZRUUxF
dzlYWldKRFpYSjBJRk4xY0hCdmNuUXhHREFXQmdOVkJBTVREMFp5WVc1ck5FUkVJRmRsCllpQkRR
VEVqTUNFR0NTcUdTSWIzRFFFSkFSWVVjM1Z3Y0c5eWRFQm1jbUZ1YXpSa1pDNWpiMjB3SGhjTk1U
TXcKTVRFeE1EUTFNVE01V2hjTk1UZ3dNVEV3TURRMU1UTTVXakJMTVFzd0NRWURWUVFHREFKS1VE RVBNQTBHQTFVRQpDQXdHWEZSdmEzbHZNUkV3RHdZRFZRUUtEQWhHY21GdWF6UkVSREVZTUJZR0Ex
VUVBd3dQZDNkM0xtVjRZVzF3CmJHVXVZMjl0TUlHYU1BMEdDU3FHU0liM0RRRUJBUVVBQTRHSUFE
Q0JoQUo5WThFaUhmeHhNL25PbjJTbkkxWHgKRHdPdEJEVDFKRjBReTliMVlKanV2YjdjaTEwZjVN
Vm1UQllqMUZTVWZNOU1vejJDVVFZdW4yRFljV29IcFA4ZQpqSG1BUFVrNVd5cDJRN1ArMjh1bklI
QkphVGZlQ09PekZSUFY2MEdTWWUzNmFScG04L3dVVm16eGFLOGtCOWVaCmhPN3F1TjdtSWQxL2pW
cTNKODhDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUVVGQUFPQmdRQU1meTQzeE15OHh3QTUKVjF2T2NS
OEtyNWNaSXdtbFhCUU8xeFEzazlxSGtyNFlUY1JxTVQ5WjVKTm1rWHYxK2VSaGcwTi9WMW5NUTRZ
RgpnWXcxbnlESnBnOTduZUV4VzQyeXVlMFlHSDYyV1hYUUhyOVNVREgrRlowVnQvRGZsdklVTWRj
UUFEZjM4aU9zCjlQbG1kb3YrcE0vNCs5a1h5aDhSUEkzZXZ6OS9NQT09Ci0tLS0tRU5EIENFUlRJ
RklDQVRFLS0tLS0K 
# 在这个例子中,密钥数据不是真正的 PEM 编码的私钥
tls.key: |
RXhhbXBsZSBkYXRhIGZvciB0aGUgVExTIGNydCBmaWVsZA==

提供 TLS 类型的 Secret 仅仅是出于方便性考虑,可以创建 Opaque 类型的 Secret 来保存用于 TLS 身份认证的凭据。 不过,使用已定义和公开的 Secret 类型有助于确保自己项目中的 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 编码, 并且必须与 --key 的给定私钥匹配。

7、启动引导令牌 Secret

bootstrap.kubernetes.io/token 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>:一组布尔类型的标志,用于标识启动引导令牌的其他用途。这些标志可以根据具体情况命名为 usage-bootstrap-xxx,其中 xxx 是用途的名称;
  • auth-extra-groups:一个用逗号分隔的组名列表,用于身份认证时将额外添加到被认证用户的组中。这些组名除了 system:bootstrappers 组之外会被添加进去。

也可以在 Secret 的 stringData 字段中提供值,而无需对其进行 base64 编码:

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 的 stringData 字段不能很好地与服务器端应用配合使用。

四、使用Secret

1、创建Secret

创建 Secret 有以下几种可选方式:

  • 使用 kubectl;
  • 使用配置文件;
  • 使用 Kustomize 工具。

2、对 Secret 名称与数据的约束

创建 Kubernetes Secret 对象时,其名称必须是合法的 DNS 子域名。 在 Secret 的 YAML 配置文件中,数据可以通过 data 和 stringData 字段指定,并且这两个字段都是可选的。

在 data 字段中,键值对中的值必须是 base64 编码的字符串。但是,在 stringData 字段中可以使用任何字符串作为值,而不需要进行编码操作。

Secret 中的键名必须是合法的 DNS 子域名,只能包含字母、数字、-、_ 或 . 字符。 如果在 stringData 和 data 字段中都存在同名键,则以 stringData 中的键值对为准,其将覆盖 data 字段中的同名键值对。

3、尺寸限制

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

4、编辑 Secret

正常情况下可以编辑一个已有的 Secret,除非它是不可变更的。 要编辑一个 Secret,可使用以下方法之一:

  • 使用 kubectl;
  • 使用配置文件。

也可以使用 Kustomize 工具编辑数据,但是这种方法会用编辑过的数据创建新的 Secret 对象。

5、使用 Secret

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

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

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

6、可选的 Secret

当在 Pod 中引用 Secret 时,可以将该 Secret 标记为可选,就像下面例子中所展示的那样。 如果可选的 Secret 不存在,Kubernetes 将忽略它。

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: true

默认情况下,Secret 是必需的。在所有非可选的 Secret 都可用之前,Pod 的所有容器都不会启动。如果 Pod 引用了非可选 Secret 中的特定键,并且该 Secret 确实存在,但缺少所指定的键, 则 Pod 在启动期间会失败。

7、在 Pod 以文件形式使用 Secret

如果要在 Pod 中访问来自 Secret 的数据,一种方式是让 Kubernetes 将该 Secret 的值以 文件的形式呈现,该文件存在于 Pod 中一个或多个容器内的文件系统内。

当卷中包含来自 Secret 的数据,而对应的 Secret 被更新,Kubernetes 会跟踪到这一操作并更新卷中的数据。更新的方式是保证最终一致性。对于以 subPath 形式挂载 Secret 卷的容器而言, 它们无法收到自动的 Secret 更新。

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

对 Secret 的更新操作既可以通过 API 的 watch 机制(默认)来传播, 基于设置了生命期的缓存获取,也可以通过 kubelet 的同步回路来从集群的 API 服务器上轮询获取。因此,从 Secret 被更新到新的主键被投射到 Pod 中,中间存在一个延迟, 这一延迟的上限是 kubelet 的同步周期加上缓存的传播延迟, 其中缓存的传播延迟取决于所选择的缓存类型, 对应上一段中提到的几种传播机制,延迟时长为 watch 的传播延迟、所配置的缓存 TTL 或者对于直接轮询而言是零。

8、以环境变量的方式使用 Secret

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

  • 对于 Pod 规约中的每个容器,针对要使用的每个 Secret 键,将对应的环境变量添加到 env[].valueFrom.secretKeyRef 中;
  • 更改镜像或命令行,以便程序能够从指定的环境变量找到所需要的值。

9、非法环境变量

如果 Pod 规约中环境变量定义会被视为非法的环境变量名,这些主键将在容器中不可用。 Pod 仍然可以启动。

Kubernetes 添加一个 Event,其 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.

10、容器镜像拉取 Secret

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

11、使用 imagePullSecrets

imagePullSecrets 字段是一个列表,包含对同一名字空间中 Secret 的引用。 可以使用 imagePullSecrets 将包含 Docker(或其他)镜像仓库密码的 Secret 传递给 kubelet。

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

12、在静态 Pod 中使用 Secret

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

五、Secret使用场景

1、作为容器环境变量

可以创建 Secret 并使用它为容器设置环境变量。

2、带 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 密钥。

注意:

  • 在提供自己的 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 连接。

3、带有生产、测试环境凭据的 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

注意:

特殊字符(例如 $、\、*、= 和 !)会被 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 规约:

  • prod-user 服务账号使用 prod-db-secret;
  • 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

在 Kubernetes 中,可以将某些 Secret 和 ConfigMap 标记为不可更改(Immutable)。这样做有以下好处:

  • 防止意外或非预期的更新导致应用程序中断。如果一个 Secret 或 ConfigMap 是不可更改的,那么试图对其进行更新操作将会失败,并在 Kubernetes 事件中记录一条错误消息。这可以帮助防止应用程序由于意外的更改而中断。
  • 对于大型使用 Secret 的集群,标记 Secret 为不可变可以显著降低 kube-apiserver 的负载,提高整个集群的性能。因为 kubelet 不需要监视被标记为不可更改的 Secret,所以它们不会被频繁地轮询和检查。这有助于减少 kube-apiserver 的负载,从而提高集群的性能。

需要注意的是,一旦将 Secret 或 ConfigMap 标记为不可更改,就不能再对其进行更新操作,除非先将其重新标记为可更改。因此,在将 Secret 或 ConfigMap 标记为不可更改之前,请确保这些对象的数据已经是最终版本。

1、将 Secret 标记为不可更改

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

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

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

一旦一个 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 的权限。

注意:在一个节点上以 privileged: true 运行的所有容器可以访问该节点上使用的所有 Secret。

广告合作
QQ群号:707632017

温馨提示:

1、本网站发布的内容(图片、视频和文字)以原创、转载和分享网络内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。邮箱:2942802716#qq.com。(#改为@)

2、本站原创内容未经允许不得转裁,转载请注明出处“站长百科”和原文地址。

目录