Kubernetes之Secret

Kubernetes之Secret

1.使用Secret给容器传递敏感数据

在k8s中，有环境变量和configmap给容器传递非敏感数据，但是通常会包含一些敏感数据，如证书和私钥，需要保证安全性。

1.1 介绍secret

为了存储与分发此类信息，Kubernetes提供了一种称为Secret的单独资源对象。Secret结构与ConfigMap类似，均是键/值对的映射。Secret的使用方法也与ConfigMap相同，可以

将Secret条目作为环境变量传递给容器将Secret条目暴露为卷中的文件

Kubernetes通过仅仅将Secret分发到需要访问Secret的pod所在的机器节点来保障其安全性。另外，Secret只会存储在节点的内存中，永不写入物理存储，这样从节点上删除Secret时就不需要擦除磁盘了。

对于主节点本身（尤其是etcd)，Secret通常以非加密形式存储，这就需要保障主节点的安全从而确保存储在Secret中的敏感数据的安全性。这种保障不仅仅是对etcd存储的安全性保障，同样包括防止未授权用户对API服务器的访问，这是因为任何人都能通过创建pod并将Secret挂载来获得此类敏感数据。从Kubernetes1.7开始，etcd会以加密形式存储Secret,某种程度提高了系统的安全性。正因为如此，从Secret与ConfigMap中做出正确选择是势在必行的，选择依据相对简单：

采用ConfigMap存储非敏感的文本配置数据。采用Secret存储天生敏感的数据，通过键来引用。如果一个配置文件同时包含敏感与非敏感数据，该文件应该被存储在Secret中。

1.2 默认令牌Secret介绍

首先分析一种默认被挂载至所有容器的Secret,对任意一个pod使用命令kubectl describe pod,输出往往包含如下信息:

Volumes： default-token-cfee9: Type: Secret (a volume populated by a Secret) SecretName: default-token-cfee9

每个pod都会被自动挂载上一个secret卷，这个卷引用的是前面kubectl describe输出中的一个叫作default-token-cfee9的Secret。由于Secret也是资源对象，因此可以通过kubectl get secrets命令从Secret列表中找到这个default-token Secret：

$ kubectl get secretsNAME TYPE DATA AGEdefault-token-cfee9 kubernetes.io/service-account-token 3 39d

同样可以使用kubectl describe多了解一下这个Secret,如下面的代码所示。

#代码7.20 描述一个Secret$ kubectl describe secretsName: default-token-cfee9Namespace: defaultLabels: Annotations: kubernetes.io/service-account.name=default kubernetes.io/service-account.uid=cc04bb39-b53f-42010af00237Type: kubernetes.io/service-account-tokenData====ca.crt: 1139 bytes #包含下面3个条目namespace: 7 bytes token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

可以看出这个Secret包含三个条目---ca.crt、namespace与token,包含了从pod内部安全访问KubernetesAPI服务器所需的全部信息。尽管你希望做到应用程序对Kubernetes的完全无感知，然而在除了直连Kubernetes别无他法的情况下，你将会使用到secret卷提供的文件。

kubectl describe pod命令会显示secret卷被挂载的位置：

Mounts： /var/run/secrets/kubernetes.io/serviceaccount from

注意:default-tokenSecret默认会被挂载至每个容器。可以通过设置pod定义中的automountServiceAccountToken字段为false,或者设置pod使用的服务账户中的相同字段为false来关闭这种默认行为（服务账户章节会做详细讲解)。

己经说过Secret类似于ConfigMap，由于该Secret包含三个条目，可通过kubectl exec观察到被secret卷挂载的文件夹下包含三个文件:

$ kubectl exec mypod ls /var/run/secrets/kubernetes.io/serviceaccount/ca.crtnamespacetoken

下一小节中将会讲解应用程序是如何使用这些文件来访问API服务器的。

1.3 创建Secret

现在创建一个小型Secret。改进fortune-serving的Nginx容器的配置，使其能够服务于HTTPS流量。你需要创建私钥和证书，由于需要确保私钥的安全性，可将其与证书同时存入Secret。

首先在本地机器上生成证书与私钥文件。

$ openssl genrsa -out 2048$ openssl req -new -x509 -key -out -days 3650 -subj /CN=kubia-example.com

现在为了更好地理解Secret,额外创建一个内容为字符串bar的虚拟文件foo。过会儿就会理解为何要这样做：

$ echo bar > foo

现在使用kubectl create secret命令由这三个文件创建Secret:

$ kubectl create secret generic fortune---from-file= --from-file=--from-file=foosecret "fortune-对比 ConfigMap 与 Secret

Secret与ConfigMap仍有比较大的差别，这也是为何kubernetes开发者们在支持了Secret—段时间之后仍会选择创建ConfigMap。创建的Secret的YAML格式定义如下面的代码清单所示。

#代码7.21 Secret的YAML格式定义$ kubectl get secret fortune--o yamlapiVersion: v1data: foo: YmFyCg== LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURCekNDQ... LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcE...kind: Secret...

将其与之前创建的ConfigMap的YAML格式定义做对比：

#代码7.22 Config的YAML格式定义$ kubectl get configmap fortune-config -o yamlapiVersion: v1data: my-nginx-config.conf: | server { ... } sleep-interval: | 25kind: ConfigMap...

注意到两者的区别了吗？ Secre条目的内容会被以Base64格式编码，而ConfigMap直接以纯文本展示。这种区别导致在处理YAML和JSON格式的Secret时会稍许有些麻烦，需要在设置和读取相关条目时对内容进行编解码。

为二进制数据创建Secret

采用Base64编码的原因很简单Secret的条目可以涵盖二进制数据，而不仅仅是纯文本。Base64编码可以将二进制数据转换为纯文本以YAML或JSON格式展示。

提示:Secret甚至可以被用来存储非敏感二进制数据。不过值得注意的是Secret限于1MB。

stringData字段介绍

由于并非所有的敏感数据都是二进制形式，Kubernetes允许通过Secret的stringData字段设置条目的纯文本值，如下面的代码清单所示。

#代码7.23 通过stringdata字段向Secret添加纯文本条目值kind: Secret apiVersion: v1 stringData： #stringData可用来社会资非二进制数据 foo: plain text #值为被Base64编码data： LSOtLSlCRUdJTiBDRVJUSUZJQOFURSOtLSOtCklJSURCekNDQ… LSOtLSlCRUdJTiBSUOEgUFJJVkFURSBLRVktLSOtLQpNSUlFcE....

stringData字段是只写的（注意：是只写，非只读），可以被用来设置条目值。通过kubectl get -o yaml获取Secret的YAML格式定义时，不会显示stringData字段。相反，stringData字段中的所有条目（如上面示例中的foo条目）会被Base64编码之展示在data字段下。

在pod中读取Secret条目

通过secret卷将Secret暴露给容器之后，Secret条目的值会被解码并真实形式（纯文本或二进制）写入对应的文件。通过环境变量暴露Secret条目亦是如此。在这两种情况下，应用程序均无须主动解码，可直接读取文件内容或者查找环境变量。

1.5 在pod中使用Secret

fortune-ConfigMap以开启HTTPS

为了开启HTTPS，需要再次修改这个ConfigMap对应的配置条目：

$ kubectl edit configmap fortune-config

文本编辑器打开后，修改条目my-nginx-config.conf的内容，如下面的代码清单所示。

#代码7.24 修改fortune-config ConfigMap的数据...data: my-nginx-config.conf: | server { listen 80; listen 443 ssl; server_name kubia-example.com; ssl_certificate certs/ ssl_certificate_key certs/ 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: |...

上面配置了服务器从/etc/nginx/certs中读取证书与密钥文件，因此之后需要将secret卷挂载于此。

挂载fortune-secret至pod

接下来需要创建一个新的fortune-pod，将含有证书与密钥的secret卷挂载至pod中的web-server容器，如下面的代码清单所示。

#代码7.25 fortune-v1kind: Podmetadata: name: fortune- 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/中读取证书和密钥文件，需将secert卷挂载于此 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: - name: certs #这里引用fortune-Secret来定义secret卷 secret: secretName: fortune-default-token以及卷、卷挂载并不包含在这一定义中，因为这些组件被自动加入pod定义，图中不予展示。

注意：与configMap卷相同，secret卷同样支持通过defaultModes属性指定卷中文件的默认权限。

测试Nginx是否正使用Secret中的证书与密钥

pod运行之后，开启端口转发隧道将HTTPS流量转发至pod的443端口，并用curl向服务器发送请求：

$ kubectl port-forward fortune-8443:443 &Forwarding from 127.0.0.1:8443 -> 443Forwarding from [::1]:8443 -> 443$ curl -k

若服务器配置正确，会得到一个响应，检查响应中服务器证书是否与之前生成的证书匹配。curl命令添加选项-v开启详细日志，如下面的代码清单所示。

#显示Nginx发送的服务器证书$ curl -k -v* About to connect() to localhost port 8443 (#0)* Trying ::1...* Connected to localhost (::1) port 8443 (#0)* Initializing NSS with certpath: sql:/etc/pki/nssdb* skipping SSL peer certificate verification* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384* Server certificate:* subject: CN=kubia-example.com #证书与之前创建并存储于Secret中的证书匹配* start date: aug 16 18:43:13 2016 GMT * expire date: aug 14 18:43:13 2026 GMT * common name: kubia-example.com * issuer: CN=kubia-example.com

Secret卷存储于内存

通过挂载secret卷至文件夹/etc/nginx/certs将证书与私钥成功传递给容器。secret卷采用内存文件系统列出容器的挂载点，如下面的代码清单所示。

$ kubectl exec fortune--c web-server -- mount | grep certstmpfs on /etc/nginx/certs type tmpfs (ro,relatime)

由于使用的是tmpfs，存储在Secret中的数据不会写入磁盘，这样就无法被窃取。

通过环境变量暴露Secret条目

除卷之外，Secret的独立条目可作为环境变量被暴露，就像ConfigMap中sleep-interval条目做的那样。举个例子，若想将Secret中的键foo暴露为环境变量FOO_SECRET，需要在容器定义中添加如下片段。

#代码7.27 Secret条目暴露为环境变量env: - name: FOO_SECRET valueFrom: secretKeyRef: #通过Secret条目设置环境变量 name: fortune- #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除了是一个公共镜像仓库，还支持在上面创建私有仓库。通过浏览器登录​​kubectl create secret docker-registry mydockerhubsecret \--docker-username=myusername --docker-password=mypassword \--docker-emai1=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.yamlapiVersion: v1kind: Podmetadata: name: private-podspec: imagePullSecrets: #能够从私有镜像仓库中拉取镜像 - name: mydockerhubsecret containers: - image: username/private:tag name: main

不需要为每个pod指定镜像拉取Secret

假设某系统中通常运行大量pod,你可能会好奇是否需要为每个pod都添加相同的镜像拉取Secret。幸运的是，情况并非如此。有一种通过添加Secret至ServiceAccount使所有pod都能自动添加上镜像拉取Secret。这里不做解释。

作者：​​小家电维修​​

​

转世燕还故榻,为你衔来二月的花。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。