7.5 使用Secret给容器传递敏感数据
7.5 使用Secret给容器传递敏感数据
到目前为止传递给容器的所有信息都是比较常规的非敏感数据。然而正如本章开头提到的，配置通常会包含一些敏感数据，如证书和私钥，需要确保其安全性。
7.5.1 介绍Secret
为了存储与分发此类信息，Kubernetes提供了一种称为Secret的单独资源对象。Secret结构与ConfigMap类似，均是键/值对的映射。Secret的使用方法也与ConfigMap相同，可以
- 将Secret条目作为环境变量传递给容器
- 将Secret条目暴露为卷中的文件
Kubernetes通过仅仅将Secret分发到需要访问Secret的pod所在的机器节点来保障其安全性。另外，Secret只会存储在节点的内存中，永不写入物理存储，这样从节点上删除Secret时就不需要擦除磁盘了。
对于主节点本身（尤其是etcd）,Secret通常以非加密形式存储，这就需要保障主节点的安全从而确保存储在Secret中的敏感数据的安全性。这种保障不仅仅是对etcd存储的安全性保障，同样包括防止未授权用户对API服务器的访问，这是因为任何人都能通过创建pod并将Secret挂载来获得此类敏感数据。从Kubernetes 1.7开始，etcd会以加密形式存储Secret，某种程度提高了系统的安全性。正因为如此，从Secret与ConfigMap中做出正确选择是势在必行的，选择依据相对简单：
- 采用ConfigMap存储非敏感的文本配置数据。
- 采用Secret存储天生敏感的数据，通过键来引用。如果一个配置文件同时包含敏感与非敏感数据，该文件应该被存储在Secret中。
第5章中已经使用过Secret以存储Ingress资源的TLS证书。接下来将更深入地探讨Secret的细节。
7.5.2 默认令牌Secret介绍
首先来分析一种默认被挂载至所有容器的Secret，对任意一个pod使用命令kubectl describe pod，输出往往包含如下信息：
Volume:
kube-api-access-r8tkm:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
每个pod都会被自动挂载上一个Projected卷，这个卷引用的是前面 kubectl describe 输出中的一个叫作kube-api-access-r8tkm的Secret。
dkube-api-access 被自动创建且对应的卷被自动挂载到每个pod上
由于Secret也是资源对象，因此可以通过 kubectl get secrets 命令从Secret列表中找到这个 default-token Secret：
$ kubectl get secrets
NAME TYPE DATA AGE
default-token-kwqxk kubernetes.io/service-account-token 3 2d12h
同样可以使用 kubectl describe 多了解一下这个Secret，如下面的代码清单所示。
代码清单7.20 描述一个Secret
$ kubectl describe secrets default-token-kwqxk
可以看出这个Secret包含三个条目——ca.crt、namespace与token，包含了从pod内部安全访问Kubernetes API服务器所需的全部信息。尽管你希望做到应用程序对Kubernetes的完全无感知，然而在除了直连Kubernetes别无他法的情况下，你将会使用到secret卷提供的文件。
kubectl describe pod 命令会显示secret卷被挂载的位置：
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-r8tkm (ro)
注意 default-token Secret 默认会被挂载至每个容器。可以通过设置pod定义中的automountServiceAccountToken字段为false，或者设置pod使用的服务账户中的相同字段为false来关闭这种默认行为（本书后面会对服务账户进行讲解）。
我们已经说过Secret类似于ConfigMap，由于该Secret包含三个条目，可通过 kubectl exec 观察到被secret卷挂载的文件夹下包含三个文件：
$ kubectl exec fortune-configmap-volume -c web-server -- ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
token
下一章中将会看到应用程序是如何使用这些文件来访问API服务器的。
7.5.3 创建Secret
现在你将创建自己地小型Secret。改进fortune-serving的Nginx容器的配置，使其能够服务于HTTPS流量。你需要创建私钥和证书，由于需要确保私钥的安全性，可将其与证书同时存入Secret。
首先在本地机器上生成证书与私钥文件，当然也可以直接使用本书代码归档中的相应文件（fortune-https文件夹下的证书与密钥文件）：
参考第五章的 5.4.4 配置Ingress处理TLS传输
现在为了帮助你更好地理解Secret，额外创建一个内容为字符串bar的虚拟文件foo。过会儿你就会理解为何要这样做：
$ echo bar > foo
现在使用kubectl create secret命令由这三个文件创建Secret：
$ kubectl create secret generic fortune-https --from-file=https.key --from-file=https.cert --from-file=foo
与创建ConfigMap的过程类似，这里创建了一个名为 fortune-https 的 generic Secret ，它包含有两个条目：https.key 和 https.cert ，分别对应于两个同名文件的内容。如前所述，同样可以用 --from-file=fortune-https 囊括整个文件夹中的所有文件，替代单独指定每个文件的创建方式。
注意 这里创建了一个 generic Secret ，在此之前你可能在第5章通过 kubectl create secret tls 创建过一个 tls Secret 。两种方式创建的Secret的条目名称不同。
7.5.4 对比ConfigMap与Secret
Secret与ConfigMap仍有比较大的差别，这也是为何Kubernetes开发者们在支持了Secret一段时间之后仍会选择创建ConfigMap。创建的Secret的YAML格式定义如下面的代码清单所示。
代码清单7.21 Secret的YAML格式定义
$ kubectl get secret fortune-https -o yaml
apiVersion: v1
data:
foo: YmFyCg==
https.cert: LS0tLS1CRUdJTiBDRVJUSUZJQ------------------------------------------------------------------------------------------OXURSSng1ZkduWDl1S0ZsNTY3VkhOd09KTkIKVnZQN=MzB0UUw4ckFML21kUT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
https.key: LS0tLS1CRUdJTiBSU0EgUFJJV-----------------------------------------------------------------------------------------------3phR1k5dHZDMnZPMnpPRnNkM0piR2x2UytGSkVZdkhkTmdhUmc9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
kind: Secret
metadata:
creationTimestamp: "2021-07-11T13:16:33Z"
name: fortune-https
namespace: custom
resourceVersion: "144112"
uid: 4f5ee1ac-eeab-4ead-a483-0f28e427cebb
type: Opaque
将其与之前创建的ConfigMap的YAML格式定义做对比：
代码清单7.22 Config的YAML格式定义
$ kubectl get configmap fortune-config -o yaml
注意到两者的区别了吗？Secret条目的内容会被以Base64格式编码，而ConfigMap直接以纯文本展示。这种区别导致在处理YAML和JSON格式的Secret时会稍许有些麻烦，需要在设置和读取相关条目时对内容进行编解码。
为二进制数据创建Secret
采用Base64编码的原因很简单。Secret的条目可以涵盖二进制数据，而不仅仅是纯文本。Base64编码可以将二进制数据转换为纯文本，以YAML或JSON格式展示。
提示 Secret甚至可以被用来存储非敏感二进制数据。不过值得注意的是，Secret的大小限于1MB。
stringData字段介绍
由于并非所有的敏感数据都是二进制形式，Kubernetes允许通过Secret的stringData字段设置条目的纯文本值，如下面的代码清单所示。
代码清单7.23 通过stringData字段向Secret添加纯文本条目值
apiVersion: v1
stringData: #stringData用来设置非二进制数据
foo:plain text #不被Base64编码
data:
foo: YmFyCg==
https.cert: LS0tLS1CRUdJTiBDRVJUSUZJQ------------------------------------------------------------------------------------------OXURSSng1ZkduWDl1S0ZsNTY3VkhOd09KTkIKVnZQN=MzB0UUw4ckFML21kUT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
https.key: LS0tLS1CRUdJTiBSU0EgUFJJV-----------------------------------------------------------------------------------------------3phR1k5dHZDMnZPMnpPRnNkM0piR2x2UytGSkVZdkhkTmdhUmc9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=
kind: Secret
metadata:
creationTimestamp: "2021-07-11T13:16:33Z"
name: fortune-https
namespace: custom
resourceVersion: "144112"
uid: 4f5ee1ac-eeab-4ead-a483-0f28e427cebb
type: Opaque
stringData字段是只写的（注意：是只写，非只读），可以被用来设置条目值。通过 kubectl get -o yaml 获取Secret的YAML格式定义时，不会显示stringData字段。相反，stringData字段中的所有条目（如上面示例中的foo条目）会被Base64编码之后展示在data字段下。
在pod中读取Secret条目
通过secret卷将Secret暴露给容器之后，Secret条目的值会被解码并以真实形式（纯文本或二进制）写入对应的文件。通过环境变量暴露Secret条目亦是如此。在这两种情况下，应用程序均无须主动解码，可直接读取文件内容或者查找环境变量。
7.5.5 在pod中使用Secret
fortune-https Secret 已经包含了证书与密钥文件，接下来需要做的是配置Nginx服务器去使用它们。
修改 fortune-config ConfigMap以开启HTTPS
为了开启HTTPS，需要再次修改这个ConfigMap对应的配置条目：
$ kubectl edit configmap fortune-config
文本编辑器打开后，修改条目my-nginx-config.con的内容，如下面的代码清单所示。
代码清单7.24 修改 fortune-config ConfigMap的数据
apiVersion: v1
data:
my-nginx-config.conf: |
server {
listen 80;
listen 443 ssl;
server_name www.kubia-example.com;
ssl_certificate certs/https.crt; #相对位置
ssl_certificate_key certs/https.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
sleep-interval: |
25
kind: ConfigMap
metadata:
creationTimestamp: "2021-07-11T11:39:04Z"
name: fortune-config
namespace: custom
resourceVersion: "141957"
uid: a0d46cf3-8d29-44f9-bfac-1e077e75743e
上面配置了服务器从 /etc/nginx/certs 中读取证书与密钥文件，因此之后需要将secret卷挂载于此。
挂载fortune-secret至pod
接下来需要创建一个新的fortune-https pod，将含有证书与密钥的secret卷挂载至pod中的web-server容器，如下面的代码清单所示。
代码清单7.25 fortune-https pod的YAML格式定义：fortune-pod-https.yaml
apiVersion: v1
kind: Pod
metadata:
name: fortune-https
spec:
containers:
- image: luksa/fortune:env
name: html-generator
env:
- name: INTERVAL
valueFrom:
configMapKeyRef:
name: fortune-config
key: sleep-interval
volumeMounts:
- name: html
mountPath: /var/htdocs
- image: nginx:alpine
name: web-server
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
readOnly: true
- name: config
mountPath: /etc/nginx/conf.d
readOnly: true
- name: certs #配置nginx 从 /etc/nginx/certs 中读取证书和密钥.需要将secret卷挂载于此
mountPath: /etc/nginx/certs/
readOnly: true
ports:
- containerPort: 80
- containerPort: 443
volumes:
- name: html
emptyDir: {}
- name: config
configMap:
name: fortune-config
items:
- key: my-nginx-config.conf
path: https.conf
- name: certs #这里引用fortune-https Secret来定义secret卷
secret:
secretName: fortune-https
注意 与configMap卷相同，secret卷同样支持通过defaultModes属性指定卷中文件的默认权限。
测试Nginx是否正使用Secret中的证书与密钥
pod运行之后，开启端口转发隧道将HTTPS流量转发至pod的443端口，并用curl向服务器发送请求：
$ kubectl port-forward fortune-https 8443:443 &
Forwarding from 127.0.0.1:8443 -> 443
$ curl https://localhost:8443 -k
Handling connection for 8443
You have many friends and very few living enemies.
若服务器配置正确，会得到一个响应，检查响应中服务器证书是否与之前生成的证书匹配。curl命令添加选项-v开启详细日志，如下面的代码清单所示。
$ curl https://localhost:8443 -k -v
* About to connect() to localhost port 8443 (#0)
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
Handling connection for 8443
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=www.kubia-example.com
* start date: Feb 28 07:24:46 2021 GMT
* expire date: Feb 26 07:24:46 2031 GMT
* common name: www.kubia-example.com
* issuer: CN=www.kubia-example.com
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8443
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.19.6
< Date: Sun, 28 Feb 2021 07:36:49 GMT
< Content-Type: text/html
< Content-Length: 64
< Last-Modified: Sun, 28 Feb 2021 07:36:37 GMT
< Connection: keep-alive
< ETag: "603b4805-40"
< Accept-Ranges: bytes
<
You are fighting for survival in your own sweet and gentle way.
* Connection #0 to host localhost left intact
Secret卷存储于内存
通过挂载secret卷至文件夹 /etc/nginx/certs 将证书与私钥成功传递给容器。secret卷采用内存文件系统列出容器的挂载点，如下面的代码清单所示。
$ kubectl exec fortune-https -c web-server -- mount | grep certs
tmpfs on /etc/nginx/certs type tmpfs (ro,relatime)
由于使用的是tmpfs，存储在Secret中的数据不会写入磁盘，这样就无法被窃取。
通过环境变量暴露Secret条目
除卷之外，Secret的独立条目可作为环境变量被暴露，就像ConfigMap中 sleep-interval 条目做的那样。举个例子，若想将Secret中的键foo暴露为环境变量 FOO_SECRET ，需要在容器定义中添加如下片段。
代码清单7.27 Secret条目暴露为环境变量
apiVersion: v1
kind: Pod
metadata:
name: env-single-secret
spec:
containers:
- name: envars-test-container
image: nginx
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef: #通过secret条目设置环境变量
name: fortune-https #secret的键
key: foo #secret的名称
上面片段与设置INTERVAL环境变量的基本一致，除了这里是使用secretKeyRef字段来引用Secret，而非configMapKeyRef，后者用以引用ConfigMap。
Kubernetes允许通过环境变量暴露Secret，然而此特性的使用往往不是一个好主意。应用程序通常会在错误报告时转储环境变量，或者是启动时打印在应用日志中，无意中暴露了Secret信息。另外，子进程会继承父进程的所有环境变量，如果是通过第三方二进制程序启动应用，你并不知道它使用敏感数据做了什么。
提示 由于敏感数据可能在无意中被暴露，通过环境变量暴露Secret给容器之前请再三思考。为了确保安全性，请始终采用secret卷的方式暴露Secret。
了解镜像拉取Secret
你已经学会了如何传递Secret给应用程序并使用它们包含的数据。Kubernetes自身在有些时候希望我们能够传递证书给它，比如从某个私有镜像仓库拉取镜像时。这一点同样需通过Secret来做到。
到目前为止所使用的容器镜像均存储在公共仓库，从上面拉取镜像时无须任何特殊的证书。不过大部分组织机构不希望它们的镜像开放给所有人，因此会使用私有镜像仓库。部署一个pod时，如果容器镜像位于私有仓库，Kubernetes需拥有拉取镜像所需的证书。让我们看一下该怎么做。
在Docker Hub上使用私有镜像仓库
Docker Hub除了是一个公共镜像仓库，还支持在上面创建私有仓库。通过浏览器登录 https://hub.docker.com ，找到对应的镜像仓库，勾选指定的复选框，将仓库标记为私有。
运行一个镜像来源于私有仓库的pod时，需要做以下两件事：
- 创建包含Docker镜像仓库证书的Secret。
- pod定义中的imagePullSecrets字段引用该Secret。
创建用于Docker镜像仓库鉴权的Secret
创建一个包含Docker镜像仓库鉴权证书的Secret与7.5.3节中创建generic Secret并没有什么不同。同样使用kubectl create secret命令，仅仅是类型与参数选项的不同：
$ kubectl create secret docker-registry mydockerhubsecret \
--docker-username=myusername --docker-password=mypassword \
--docker-email=my.email@provider.com
这里创建了一个docker-registry类型的 mydockerhubsecret Secret，创建时需指定Docker Hub的用户名、密码以及邮箱。通过kubectl describe观察新建Secret的内容时会发现仅有一个条目.dockercfg，相当于用户主目录下的.dockercfg文件。该文件通常在运行docker login命令时由Docker自动创建。
在pod定义中使用docker-registry Secret
为了Kubernetes从私有镜像仓库拉取镜像时能够使用Secret，需要在pod定义中指定docker-registry Secret的名称，如下面的代码清单所示。
代码清单7.28 指定镜像拉取Secret的pod定义：pod-with-private-image.yaml
apiVersion: v1
kind: Pod
metadata:
name: private-pod
spec:
imagePullSecrets: #能够从私有镜像仓库中拉取镜像
- name: mydockerhubsecret
containers:
- image: username/private:tag
name: main
上述pod定义中，字段imagePullSecrets引用了 mydockerhubsecret Secret。建议你尝试一下这个特性，因为很可能在不久之后就会与私有镜像打交道。
不需要为每个pod指定镜像拉取Secret
假设某系统中通常运行大量pod，你可能会好奇是否需要为每个pod都添加相同的镜像拉取Secret。幸运的是，情况并非如此。第12章中将会学习到如何通过添加Secret至ServiceAccount使所有pod都能自动添加上镜像拉取Secret。
