在 这篇文章 中我们介绍了ConfigMap
的使用,一般情况下ConfigMap
是用来存储一些非安全的配置信息,如果涉及到一些安全相关的数据的话用ConfigMap
就非常不妥了,因为ConfigMap
是明文存储的,这个时候就需要用到另外一个资源对象了:Secret
,Secret
用来保存敏感信息,例如密码、OAuth 令牌和 ssh key等等,将这些信息放在Secret
中比放在Pod
的定义中或者docker
镜像中来说更加安全和灵活。
Secret
有三种类型:
Opaque :base64
编码格式的 Secret,用来存储密码、密钥等;但数据也可以通过 base64 –decode解码得到原始数据,所有加密性很弱。
kubernetes.io/dockerconfigjson :用来存储私有docker registry
的认证信息。
kubernetes.io/service-account-token :用于被serviceaccount
引用,serviceaccout 创建时Kubernetes
会默认创建对应的secret
。Pod
如果使用了serviceaccount
,对应的secret
会自动挂载到Pod
目录/run/secrets/kubernetes.io/serviceaccount
中。
Opaque Secret Opaque 类型的数据是一个 map 类型,要求value是base64
编码格式,比如我们来创建一个用户名为 admin,密码为 admin321 的 Secret 对象,首先我们先把这用户名和密码做 base64 编码,
1 2 3 4 $ echo -n "admin" | base64 YWRtaW4= $ echo -n "admin321" | base64 YWRtaW4zMjE=
然后我们就可以利用上面编码过后的数据来编写一个YAML
文件:
1 2 3 4 5 6 7 8 apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque data: username: YWRtaW4= password: YWRtaW4zMjE=
然后同样的我们就可以使用kubectl
命令来创建了:
1 2 $ kubectl create -f secret.yaml secret "mysecret" created
利用get secret
命令查看:
1 2 3 4 $ kubectl get secret NAME TYPE DATA AGE default-token-n9w2d kubernetes.io/service-account-token 3 33d mysecret Opaque 2 40s
其中default-token-cty7pdefault-token-n9w2d
为创建集群时默认创建的 secret,被serviceacount/default 引用。
使用describe
命令,查看详情:
1 2 3 4 5 6 7 8 9 10 11 12 $ kubectl describe secret mysecret Name: mysecret Namespace: default Labels: <none> Annotations: <none> Type: Opaque Data ==== password: 8 bytes username: 5 bytes
我们可以看到利用describe
命令查看到的Data
没有直接显示出来,如果想看到Data
里面的详细信息,同样我们可以输出成YAML
文件进行查看:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 $ kubectl get secret mysecret -o yaml apiVersion: v1 data: password: YWRtaW4zMjE= username: YWRtaW4= kind: Secret metadata: creationTimestamp: "2021-03-06T07:52:54Z" name: mysecret namespace: default resourceVersion: "432924061" selfLink: /api/v1/namespaces/default/secrets/mysecret uid: 008c99cc-230a-4224-9f41-b5cadccd71ec type: Opaque
创建好Secret
对象后,有两种方式来使用它:
环境变量 首先我们来测试下环境变量的方式,同样的,我们来使用一个简单的busybox
镜像来测试下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 apiVersion: v1 kind: Pod metadata: name: secret1-pod spec: containers: - name: secret1 image: busybox command: [ "/bin/sh" , "-c" , "env" ] env: - name: USERNAME valueFrom: secretKeyRef: name: mysecret key: username - name: PASSWORD valueFrom: secretKeyRef: name: mysecret key: password
主要上面环境变量中定义的secretKeyRef
关键字,和configMapKeyRef
是不是比较类似,一个是从Secret
对象中获取,一个是从ConfigMap
对象中获取,创建上面的Pod
:
1 2 $ kubectl create -f secret1-pod.yaml pod "secret1-pod" created
然后我们查看Pod
的日志输出:
1 2 3 4 5 $ kubectl logs secret1-pod ... USERNAME=admin PASSWORD=admin321 ...
可以看到有 USERNAME 和 PASSWORD 两个环境变量输出出来。
Volume 挂载 同样的我们用一个Pod
来验证下Volume
挂载,创建一个Pod
文件:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 apiVersion: v1 kind: Pod metadata: name: secret2-pod spec: containers: - name: secret2 image: busybox command: ["/bin/sh", "-c" , "ls /etc/secrets" ] volumeMounts: - name: secrets mountPath: /etc/secrets volumes: - name: secrets secret: secretName: mysecret
创建Pod
:
1 2 $ kubectl create -f secret-pod2.yaml pod "secret2-pod" created
然后我们查看输出日志:
1 2 3 $ kubectl logs secret2-pod password username
可以看到secret
把两个key挂载成了两个对应的文件。当然如果想要挂载到指定的文件上面,可以在secretName
下面添加items
指定 key 和 path,参考ConfigMap
中的方法去测试下。
kubernetes.io/dockerconfigjson 除了上面的Opaque
这种类型外,我们还可以来创建用户docker registry
认证的Secret
,直接使用kubectl create
命令创建即可,如下:
1 2 $ kubectl create secret docker-registry myregistry --docker-server=DOCKER_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL secret "myregistry" created
然后查看Secret
列表:
1 2 3 4 5 $ kubectl get secret NAME TYPE DATA AGE default-token-n9w2d kubernetes.io/service-account-token 3 33d myregistry kubernetes.io/dockerconfigjson 1 15s mysecret Opaque 2 34m
注意看上面的TYPE
类型,myregistry
是不是对应的kubernetes.io/dockerconfigjson
,同样的可以使用describe
命令来查看详细信息:
1 2 3 4 5 6 7 8 9 10 11 $ kubectl describe secret myregistry Name: myregistry Namespace: default Labels: <none> Annotations: <none> Type: kubernetes.io/dockerconfigjson Data ==== .dockerconfigjson: 152 bytes
同样的可以看到Data
区域没有直接展示出来,如果想查看的话可以使用-o yaml
来输出展示出来:
1 2 3 4 5 6 7 8 9 10 11 12 13 $ kubectl get secret myregistry -o yaml apiVersion: v1 data: .dockerconfigjson: eyJhdXRocyI6eyJET0NLRVJfU0VSVkVSIjp7InVzZXJuYW1lIjoiRE9DS0VSX1VTRVIiLCJwYXNzd29yZCI6IkRPQ0tFUl9QQVNTV09SRCIsImVtYWlsIjoiRE9DS0VSX0VNQUlMIiwiYXV0aCI6IlJFOURTMFZTWDFWVFJWSTZSRTlEUzBWU1gxQkJVMU5YVDFKRSJ9fX0= kind: Secret metadata: creationTimestamp: 2018-06-19T16:01:05Z name: myregistry namespace: default resourceVersion: "3696966" selfLink: /api/v1/namespaces/default/secrets/myregistry uid: f91db707-73d9-11e8-a101-525400db4df7 type: kubernetes.io/dockerconfigjson
可以把上面的data.dockerconfigjson
下面的数据做一个base64
解码,看看里面的数据是怎样的呢?
1 2 $ echo eyJhdXRocyI6eyJET0NLRVJfU0VSVkVSIjp7InVzZXJuYW1lIjoiRE9DS0VSX1VTRVIiLCJwYXNzd29yZCI6IkRPQ0tFUl9QQVNTV09SRCIsImVtYWlsIjoiRE9DS0VSX0VNQUlMIiwiYXV0aCI6IlJFOURTMFZTWDFWVFJWSTZSRTlEUzBWU1gxQkJVMU5YVDFKRSJ9fX0= | base64 -d {"auths":{"DOCKER_SERVER":{"username":"DOCKER_USER","password":"DOCKER_PASSWORD","email":"DOCKER_EMAIL","auth":"RE9DS0VSX1VTRVI6RE9DS0VSX1BBU1NXT1JE"}}}
如果我们需要拉取私有仓库中的docker
镜像的话就需要使用到上面的myregistry
这个Secret
:
1 2 3 4 5 6 7 8 9 10 apiVersion: v1 kind: Pod metadata: name: foo spec: containers: - name: foo image: 192.168 .1 .100 :5000/test:v1 imagePullSecrets: - name: myregistry
kubernetes.io/service-account-token 另外一种Secret
类型就是kubernetes.io/service-account-token
,用于被serviceaccount
引用。serviceaccout 创建时 Kubernetes 会默认创建对应的 secret。Pod 如果使用了 serviceaccount,对应的secret会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount
目录中。
这里我们使用一个nginx
镜像来验证一下,大家想一想为什么不是呀busybox
镜像来验证?当然也是可以的,但是我们就不能在command
里面来验证了,因为token是需要Pod
运行起来过后才会被挂载上去的,直接在command
命令中去查看肯定是还没有 token 文件的。
1 2 3 4 5 6 7 8 9 10 11 12 13 $ kubectl run secret-pod3 --image nginx:1.7.9 deployment.apps "secret-pod3" created $ kubectl get pods NAME READY STATUS RESTARTS AGE ... secret-pod3-78c8c76db8-7zmqm 1/1 Running 0 13s ... $ kubectl exec secret-pod3-78c8c76db8-7zmqm ls /run/secrets/kubernetes.io/serviceaccount ca.crt namespace token $ kubectl exec secret-pod3-78c8c76db8-7zmqm cat /run/secrets/kubernetes.io/serviceaccount/token eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tbjl3MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjMzY2FkOWQxLTU5MmYtMTFlOC1hMTAxLTUyNTQwMGRiNGRmNyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.0FpzPD8WO_fwnMjwpGIOphdVu4K9wUINwpXpBOJAQ-Tawd0RTbAUHcgYy3sEHSk9uvgnl1FJRQpbQN3yVR_DWSIlAtbmd4dIPxK4O7ZVdd4UnmC467cNXEBqL1sDWLfS5f03d7D1dw1ljFJ_pJw2P65Fjd13reKJvvTQnpu5U0SDcfxj675-Z3z-iOO3XSalZmkFIw2MfYMzf_WpxW0yMFCVkUZ8tBSTegA9-NJZededceA_VCOdKcUjDPrDo-CNti3wZqax5WPw95Ou8RJDMAIS5EcVym7M2_zjGiqHEL3VTvcwXbdFKxsNX-1VW6nr_KKuMGKOyx-5vgxebl71QQ
Secret 与 ConfigMap 对比 最后我们来对比下Secret
和ConfigMap
这两种资源对象的异同点:
相同点:
key/value 的形式
属于某个特定的namespace
可以导出到环境变量
可以通过目录/文件形式挂载
通过volume
挂载的配置信息均可热更新
不同点:
Secret 可以被ServerAccount
关联
Secret 可以存储docker register
的鉴权信息,用在ImagePullSecret
参数中,用于拉取私有仓库的镜像
Secret 支持Base64
加密
Secret 分为 kubernetes.io/service-account-token、kubernetes.io/dockerconfigjson、Opaque 三种类型,而Configmap
不区分类型