Kubernetes Secret-Trying

dream789

Secret介绍
　　参考文档
　　Secret的主要作用是保管私密数据，比如密码，OAuth Tokens,SSH Key等信息。这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更加安全，也更方便管理。
　　Secret一旦被创建，则可以通过以下三种方式来使用：

• 在创建Pod时，通过为pod指定Service Account来自动使用该Secret，主要用于API Server鉴权的过程
  
• 通过挂载Secret到Pod来使用它
  
• Docker镜像下载时使用，通过指定Pod的spc.ImagePullSecret来引用。一般用于私有仓库登录拉取镜像
  

　　Kubernetes会自动创建包含用于访问API的凭据的Secret，并自动修改您的pod以使用此类Secret。这是Kubernetes 默认的行为，我们也可以通过自定义的方式禁用或者创建我们所需要的Secret。

自定义Secret

使用命令创建账号密码形式的Secrets
　　如果在集群中，pod需要访问数据库，那么我们可以使用文件的方式定义一个Secret，在本地主机上创建一个./username.txt和./password.txt的文件：
　　

# echo "admin" > ./username.txt　　
# echo "123456" > ./password.txt
　　
# kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
　　

　　

　　查看Secret信息：
　　

# kubectl get secret/db-user-pass -o wide　　
NAME           TYPE      DATA      AGE
　　
db-user-pass   Opaque    2         1m
　　

　　
# kubectl describe secrets/db-user-pass
　　
Name:         db-user-pass
　　
Namespace:    default
　　
Labels:      
　　
Annotations:  
　　

　　
Type:  Opaque
　　

　　
Data
　　
====
　　
password.txt:  7 bytes
　　
username.txt:  6 bytes
　　

　　

　　这里并不会显示文件中的具体信息。

使用YAML文件创建Secret
　　使用YMAL创建Secert时，每个账号密码的项目必须是转换为base64的编码。
　　

[root@node-1 secret]# echo -n 'admin' | base64　　
YWRtaW4=
　　
[root@node-1 secret]# echo -n '123456' | base64  # 不能有空格或换行符，或使用 base64 | tr -d '\n'
　　
MTIzNDU2
　　

　　

　　创建YAML文件:
　　

apiVersion: v1　　
kind: Secret
　　
metadata:
　　name: mysecret
　　
type: Opaque
　　
data:
　　username: YWRtaW4=    # 账号密码使用base64的编码方式
　　password: MTIzNDU2
　　

　　查看具体信息：
　　

[root@node-1 secret]# kubectl get secret mysecret  -o yaml　　
apiVersion: v1
　　
data:
　　password: MTIzNDU2
　　username: YWRtaW4=
　　
kind: Secret
　　
metadata:
　　creationTimestamp: 2018-07-18T09:02:20Z
　　name: mysecret
　　namespace: default
　　resourceVersion: "898655"
　　selfLink: /api/v1/namespaces/default/secrets/mysecret
　　uid: 47369a09-8a69-11e8-9c5f-000c295f81fb
　　
type: Opaque
　　

　　

　　如果要查看密码，可以对编码解密：
　　

# echo 'YWRtaW4=' | base64 --decode　　
admin
　　

　　
# echo 'MTIzNDU2' | base64 -d
　　
123456
　　

Secret的使用
　　当创建好一个Secret后，可以通过多种方式使用Secret,一般有如下场景：

• 在创建Pod时，通过Pod指定Service Account来自动使用该Secret
  
• 通过挂载该Secret到Pod来使用。
  
• 在私有仓库下载Docker镜像时，可以指定Pod的参数 spec.ImagePullSecrets来引用。
  

通过挂载到Pod的方式引用
　　通过如下步骤：

• 创建一个Secret,也可以使用现有的Secret,多个Pod可以使用同一个Secret
  
• 定义Pod时，添加参数.spec.volumes[]，可以自定义卷名，在.spec.volumes[].secret.secretName参数中指定Secret对象名。
  
• 给每一个需要使用到此Secret的容器添加参数.spec.containers[].volumeMounts[]，指定.spec.containers[].volumeMounts[].readOnly = true 和 .spec.containers[].volumeMounts[].mountPath参数来存放Secret到未使用的空目录中。
  
• 修改镜像或者通过目录的方式，使程序能够通过使用目录路径的方式找到Secret,每个存放在Secret中的key值，都会以文件的形式挂载到挂载目录中。
  

　　这里给出一个示例：
　　

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
　　

　　

　　在使用Secret时，需要注意以下几点：

• 需要使用的Secret都需要通过spec.volumes参数指定。
  
• 如果在一个Pod中有多个容器，那么每个容器都需要指定一个volumeMounts的挂载目录，但是spec.volumes 值需要指定一个即可。
  
• 你可以根据自己的需要将多个文件存放在一个Secret，也可以使用多个Secret。
  

　　我们也可以控制Secret的key文件在挂载卷中的映射路径，可以使用.spec.volumes[].secret.items来指定key的路径：
　　

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
　　items:          # 这里为usrname的key指定了一个单独的路径 /etc/foo/my-group/my-username
　　- key: username
　　path: my-group/my-username   # password 将使用默认的/etc/foo/password
　　

　　

　　如果使用.spec.volumes[].secret.items参数，那么只有在items中被指定的key才能被投射到指定的目录。要使用Secret中的所有key，所有key都必须列在items字段中。 所有列出的key必须存在于相应的Secret中。 否则，不会创建volume。

Secret 文件的权限设置
　　我们可以设置Secret的文件的权限，默认情况下文件的权限是0644. 我们可以根据需要，指定整个挂载目录的权限来覆盖单个Key文件的权限：
　　

apiVersion: v1　　
kind: Pod
　　
metadata:
　　name: mypod
　　
spec:
　　containers:
　　- name: mypod
　　image: redis
　　volumeMounts:
　　- name: foo
　　mountPath: "/etc/foo"
　　volumes:
　　- name: foo
　　secret:
　　secretName: mysecret
　　defaultMode: 256      # 这里是使用十进制表示的，转换为8进制为0400
　　

　　这样在指定的挂载卷下，所有被Secret创建的文件都有400的权限。需要注意的是，JSON参数不支持八进制的表示方式，所以使用十进制的256方式来表示400权限。但是在使用YAML格式的文件定义Pod时可以正常使用八进制的表示方式。
　　同理，也可以指定key的路径，并分配权限：
　　

apiVersion: v1　　
kind: Pod
　　
metadata:
　　name: mypod
　　
spec:
　　containers:
　　- name: mypod
　　image: redis
　　volumeMounts:
　　- name: foo
　　mountPath: "/etc/foo"
　　volumes:
　　- name: foo
　　secret:
　　secretName: mysecret
　　items:
　　- key: username
　　path: my-group/my-username
　　mode: 511     #这里表示0777的权限。
　　

　　在安装Secret卷的容器内，keys显示为文件，key值基于64进行解码并存储在这些文件中。 但是在这些文件中是以明文方式存储的，容器中的程序负责从文件中读取秘密。
　　即使已经被挂载到卷中使用的Secret，也依然会随着Secret的更新而自动更新。 Kubelet将会在每个同步周期内检测当前被挂载的Secret是否是最新的。

　　容器中使用subPath volume 方式挂载的Secret将不会被更新。

以环境变量的方式使用Secret
　　使用环境变量的方式有如下特性：

• 可以创建一个新的Secret,也可以使用现有的，多个Pod可以共用一个Secret。
  
• 在定义Pod时，修改需要引用Secret的Container的配置参数，添加Secret,在env[].valueFrom.secretKeyRef参数中指定Secret的Key。
  
• 修改镜像或使用命令行模式，使应用能通过环境变量找到Secret的key.
  

　　如下示例：
　　

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

　　在此示例中，Secret会以环境变量的方式加载到容器中：
　　

$ echo $SECRET_USERNAME　　
admin
　　
$ echo $SECRET_PASSWORD
　　
123456
　　

拉取镜像时使用imagePullSecrets
　　在设置的私有仓库中拉取镜像时，我们可以使用imagePullSecrets来作为仓库的登录密码。
　　可以通过两种方式来使用imagePullSecrets：

• 手动指定imnagePullSecrets
  
• 自动添加imagePullSecrets
  

在Pod中指定一个ImagePullSecret
　　使用命令行创建一个ImagePullSecret, 将大写的部分改为具体的参数：
　　

kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL　　
secret "myregistrykey" created.
　　

　　如果需要访问多个私有仓库，可以为每个仓库创建一个Secret, 当拉取镜像时，Kubelet会合并所有的imagePullSecrets到一个虚拟的.docker/config.json文件中。

　　Pods拉取镜像只能在自己的命名空间中识别Secrets，所以在有多个namespaces的情况下，需要给每namespace都执行相同的操作。

　　还可以使用yaml或json文件的方式来创建ImagePullSecret。不过需要注意以下三点：

• 在data选项中设置.dockerconfigjson的名称
  
• 将docker认证文件以base64编码方式编码，所得的结果配置在data[".dockerconfigjson"] 参数中。
  
• 设置类型为kubernetes.io/dockerconfigjson
  

　　通过如下步骤配置：

• 使用命令行登录私有docker Registry
  

　　

# docker login localhost:5000　　

　　登录成功之后，会创建一个.docker/config.json的文件，此文件包含了登录的账号密码信息：
　　

# cat .docker/config.json　　
{
　　"auths": {
　　"localhost:5000": {
　　"auth": "dGVzdDp0ZXN0MTIzCg=="  # 使用base64方式编码的账号密码
　　}
　　},
　　"HttpHeaders": {
　　"User-Agent": "Docker-Client/17.09.1-ce (linux)"
　　}
　　
}
　　

• 将此文件内容转换为base64编码：　　
  
  # cat /root/.docker/config.json | base64　　
  ewoJImF1dGhzIjogewoJCSJsb2NhbGhvc3Q6NTAwMCI6IHsKCQkJImF1dGgiOiAiZEdWemREcDBa
  　　
  WE4wTVRJekNnPT0iICAjIOS9v+eUqGJhc2U2NOaWueW8j+e8lueggeeahOi0puWPt+WvhueggQoJ
  　　
  CX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8x
  　　
  Ny4wOS4xLWNlIChsaW51eCkiCgl9Cn0K
  
  
• 创建YAML,将输出的结果配置到data[".dockerconfigjson"]参数中：　　
  
  apiVersion: v1　　
  kind: Secret
  　　
  metadata:
  　　
  name: myregistrykey
  　　
  namespace: awesomeapps
  　　
  data:
  　　
  .dockerconfigjson: ewoJImF1dGhzIjogewoJCSJsb2NhbGhvc3Q6NTAwMCI6IHsKCQkJImF1dGgiOiAiZEdWemREcDBa
  　　
  WE4wTVRJekNnPT0iICAjIOS9v+eUqGJhc2U2NOaWueW8j+e8lueggeeahOi0puWPt+WvhueggQoJ
  　　
  CX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8x
  　　
  Ny4wOS4xLWNlIChsaW51eCkiCgl9Cn0K
  　　
  type: kubernetes.io/dockerconfigjson
  
  

　　提示：

• 在执行过程中遇到报错信息:"no objects passed to create" ,说明base64编码的字符无效
  
• 如果遇到类似"Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...的报错，说明数据已成功取消base64编码，但无法解析为.docker/config.json文件
  

• 创建Pod时，添加Secret:
  

　　

apiVersion: v1　　
kind: Pod
　　
metadata:
　　name: foo
　　namespace: awesomeapps
　　
spec:
　　containers:
　　- name: foo
　　image: janedoe/awesomeapp:v1
　　imagePullSecrets:
　　- name: myregistrykey
　　

　　

添加ImagePullSecrets到 Service account (Pod 自动添加ImagePullSecrets)

• 创建了上述的ImagePullSecrets后，执行如下命令：
  

　　

# kubectl get secrets myregistrykey　　
NAME             TYPE                              DATA    AGE
　　
myregistrykey    kubernetes.io/.dockerconfigjson   1       1d
　　

　　
# kubectl patch serviceaccount default -p '{\"imagePullSecrets\": [{\"name\": \"myregistrykey\"}]}'
　　

　　

　　在默认的Service account的命名空间中使用这个Secret,并将它作为ImagePullSecret。

• 导出default得 Serviceaccount文件：
  

　　

kubectl get serviceaccounts default -o yaml > ./sa.yaml　　

• 编辑此文件，删除"resourceVersion"所在的行，添加 "imagePullSecrets:"参数：
  

　　

$ cat sa.yaml　　
apiVersion: v1
　　
kind: ServiceAccount
　　
metadata:
　　creationTimestamp: 2015-08-07T22:02:39Z
　　name: default
　　namespace: default
　　selfLink: /api/v1/namespaces/default/serviceaccounts/default
　　uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
　　
secrets:
　　
- name: default-token-uudge
　　
imagePullSecrets:
　　
- name: myregistrykey
　　

　　4.重新生成 ServiceAccount:
　　

$ kubectl replace serviceaccount default -f ./sa.yaml　　
serviceaccounts/default
　　

　　经过这样的配置之后，在当前namespaces中新创建的Pod都会自动添加如下参数：
　　

spec:　　imagePullSecrets:
　　- name: myregistrykey
　　

Secret的限制

使用Secret的注意事项

• Secret以mount的方式载到Container时，将会验证所指向的Secret是否存在，如果Secret不存在,除非标明这个Secret是可选的参数，否则Pod中的Container将不会被启动，所以Secret必须在Pod创建之前被创建。
  
• Secret API对象存在于一个namespaces中，它只能被同一个namespaces的Pods使用。
  
• 每个单独的Secret大小都不能超过1MB，Kubernetes不鼓励创建大尺寸的Secret,因为这样将会占用API Server和kubelet的大量内存。当然创建过多的小的Secret也会占用大量内存，这个需要根据场景进行合理的规划。
  
• Secret只能应用于通过API Server创建的Pods，这包括使用kubectl命令创建的Pods和通过RC直接创建的Pods。不包含使用kubelet --manifest-url 参数， --config参数创建的Pod,使用REST API直接创建的也无法使用。
  
• 通过secretKeyRef引用已命名的Secret中不存在的key将阻止pod启动。
  
• 用于通过envFrom填充环境变量的密钥将具有可以被忽略的key，这些key可以被视为无效的环境变量时， 该pod将被允许启动。 此时，kubernetes将会生成一个事件，其原因是InvalidVariableNames，该消息将包含跳过的无效键列表,可以通过如下命令查看：　　
  
  $ 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.
  
  

Secret的加载过程
　　通过API Server创建pod时，API Sserver不会检查是否存在可以引用的Secret。 一旦pod被调度，kubelet将尝试获取Secret值。 如果由于该Secret不存在或由于暂时缺少与API服务器的连接而无法获取该Secret，则kubelet将定期重试。 它将报告有关pod的事件，说明它尚未启动的原因。 获取Secret后，kubelet将创建并安装包含它的卷。 在安装所有pod的卷之前，pod的容器都不会启动。
　　在Kubelet启动Pod中的Container后，Container中和Secret相关的Volume将不会被改变，即使Secret本身被修改了。
　　如果要使用更新后的Secret，必须删除旧的Pod,并重新创建一个新的Pod.

Secret的应用示例

Pod中使用SSH Key
　　创建一个包含SSH Key的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　　

　　提示：在发送自己的ssh密钥之前要仔细考虑：群集的其他用户可以访问该Secret。 使用您希望与您共享Kubernetes群集的所有用户都可以访问的Service Account，如果他们被泄露，可以撤销此Secret.

　　创建一个Pod,使用此Secret:
　　

kind: Pod　　
apiVersion: v1
　　
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"
　　

　　当容器的命令运行时，指定的key将会在如下目录被使用：
　　

/etc/secret-volume/ssh-publickey　　
/etc/secret-volume/ssh-privatekey
　　

　　然后容器可以自由地使用Secret数据来建立ssh连接。

为Pod加载生产/测试 认证信息
　　在不同环境中，可以指定不同的Secret,比如生产和测试Secret的进行区分。
　　首先，创建生产，测试两个不同的Secret：
　　

$ kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11　　
secret "prod-db-secret" created
　　
$ kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
　　
secret "test-db-secret" created
　　

　　注意：特殊字符如 '$', '*', '!'需要转义。如果密码中包含特殊字符，需要使用 \ 来进行转义，如，使用密码为：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:
　　

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"
　　

　　

　　两个Container中都会文件系统中找到如下文件,其中包含不同容器环境的值：
　　

/etc/secret-volume/username　　
/etc/secret-volume/password
　　

　　请注意两个pod的规格如何仅在一个字段中有所不同; 这有助于从常见的pod配置模板创建具有不同功能的pod。
　　您可以使用两个服务帐户进一步简化基本容器规范：一个称为prod-user，使用prod-db-secret，另一个称为test-user，带有test-db-secret。 然后，pod规范可以缩短为，例如：
　　

kind: Pod　　
apiVersion: v1
　　
metadata:
　　name: prod-db-client-pod
　　labels:
　　name: prod-db-client
　　
spec:
　　serviceAccount: prod-db-client
　　containers:
　　- name: db-client-container
　　image: myClientImage
　　

在Secret volume中隐藏密钥文件
　　如果想在Pod中使用.filename的方式隐藏密钥文件，可以使用如下的定义方式：
　　

kind: Secret　　
apiVersion: v1
　　
metadata:
　　name: dotfile-secret
　　
data:
　　.secret-file: dmFsdWUtMg0KDQo=
　　
---
　　
kind: Pod
　　
apiVersion: v1
　　
metadata:
　　name: secret-dotfiles-pod
　　
spec:
　　volumes:
　　- name: secret-volume
　　secret:
　　secretName: dotfile-secret
　　containers:
　　- name: dotfile-test-container
　　image: k8s.gcr.io/busybox
　　command:
　　- ls
　　- "-l"
　　- "/etc/secret-volume"
　　volumeMounts:
　　- name: secret-volume
　　readOnly: true
　　mountPath: "/etc/secret-volume"
　　

　　secret-volume中将会包换一个单独的文件 .secret-file ， 在dotfile-test-container容器中将会在如下路径存放此文件：
　　

/etc/secret-volume/.secret-file　　

使Secret只在一个容器中可见
　　考虑到应用程序需要回应HTTP请求，处理一些复杂的业务逻辑，使用HMAC签名的方式加密消息。由于应用逻辑的复杂性，在服务器中可能存在未被注意的远程文件读取漏洞，这可能会将私钥暴露给×××者。
　　这可以分为两个容器中的两个进程：一个前端容器，它处理用户交互和业务逻辑，但是看不到私钥; 和一个可以看到私钥的签名者容器，并响应来自前端的简单签名请求（例如，通过localhost网络）
　　使用这种分区方法，×××者现在必须欺骗应用程序服务器做一些相当随意的事情，这可能比让它读取文件更困难。

最佳实践
　　当部署与Secret API进行交互的应用时，应使用如RBAC等认证策略加以限制。
　　Secret通常具有跨越一系列重要性的价值，其中许多可能导致Kubernetes集群发生更改。
　　由于这些原因，使用wathc和list在namespace中操作Secret是非常高的的权限，我们应该尽量避免普通用户有此权限。应该仅为最高特权的系统级组件保留查看和列出群集中所有Secret的功能。
　　需要访问Secret API的应用程序应该根据需要执行get请求。 这使管理员可以限制对所有Secret 的访问，同时白名单列出对应用所需的各个实例的访问权限。
　　为了提高循环get的性能，客户端可以设计引用Secret的资源，然后使用watch此资源，在引用更改时重新请求Secret。此外，还提出了一种允许客户端watch单个资源的“bulk watch ”API，并且可能会在未来的Kubernetes版本中提供。

安全策略

保护
　　由于可以独立于使用它们的pod创建Secret对象，因此在创建，查看和编辑pod的工作流程中泄露Secret的风险较小。系统还可以对Secret对象采取额外的保护措施，例如尽可能避免将其写入磁盘。
　　如果该节点上的pod需要使用Secret，则仅将Secret发送到此节点，并且Secret不会被写入磁盘。它存储在tmpfs中。一旦删除依赖它的pod，它就会被删除。
　　在大多数Kubernetes项目维护的发行版中，用户与apiserver之间的通信以及从apiserver到kubelet的通信受SSL / TLS保护。通过这些通道传输时，有效保护了Secret。
　　节点上的Secret数据存储在tmpfs卷中，因此不会停留在节点上。
　　在同一节点上可能存在几个pod的Secret。但是，只有pod请求的Secret可能在其容器中可见。因此，一个Pod无法访问另一个pod的Secret。
　　Pod中可能有几个容器。但是，pod中的每个容器都必须在其volumeMounts中请求Secret卷，以使其在容器中可见。这可用于在Pod级别构建有用的安全分区。

风险

• 在API服务器中，Secret数据以明文形式存储在etcd中;因此：
  
  
  
  • 管理员应限制对管理员用户的etcd访问权限
    
  • API服务器中的Secret数据在etcd使用的磁盘上处于静止状态;管理员可能想要在不再使用时擦除/粉碎etcd使用的磁盘
    
  
  
• 如果通过JSON或YAML文件配置Secret，该文件的Secret数据编码为base64，共享此文件或将其签入到源存储库意味着该密钥已被泄露。 Base64编码不是加密方法，被认为与纯文本相同。
  
• 应用程序仍然需要在从卷读取后保护Secret值，例如不会意外地将其记录或传输给不受信任的一方。
  
• 可以创建使用Secret的用户也可以看到该Secret的值。即使apiserver策略不允许该用户读取Secret对象，用户也可以运行暴露Secret的pod。
  
• 如果运行了etcd的多个副本，则它们之间将共享Secret。默认情况下，etcd不保护与SSL / TLS的对等通信，但可以配置。
  
• 目前，任何在任何节点上具有root权限的人都可以通过kubelet从apiserver中读取任何Secret。计划的功能是仅向实际需要它们的节点发送Secret，以限制根漏洞对单个节点的影响。
  

　　提示：从1.7版本开始，已经支持在REST中对Secret数据加密。参考文档