kubernetes 中的 ConfigMap 和 Secret

为什么要有这俩玩意儿?

我们在kubernetes上部署应用的时候,经常会需要传一些配置给我们的应用,比如数据库地址啊,用户名密码啊之类的。我们要做到这个,有好多种方案,比如:

  • 我们可以直接在打包镜像的时候写在应用配置文件里面,但是这种方式的坏处显而易见而且非常明显。
  • 我们可以在配置文件里面通过env环境变量传入,但是这样的话我们要修改env就必须去修改yaml文件,而且需要重启所有的container才行。
  • 我们可以在应用启动的时候去数据库或者某个特定的地方拿,没问题!但是第一,实现起来麻烦;第二,如果配置的地方变了怎么办?

当然还有别的方案,但是各种方案都有各自的问题。

而且,还有一个问题就是,如果说我的一个配置,是要多个应用一起使用的,以上除了第三种方案,都没办法进行配置的共享,就是说我如果要改配置的话,那得一个一个手动改。假如我们有100个应用,就得改100份配置,以此类推……

kubernetes对这个问题提供了一个很好的解决方案,就是用ConfigMapSecret

创建ConfigMap

ConfigMap让我们能够从容器镜像中把配置的详细信息给解耦出来。通过ConfigMap我们能够把配置以key-value对的形式传递到container或者别的系统组件(比如Controller)里面。我们可以通过两种方式来创建ConfigMap:

From Literal Values

我们可以用kubectl create来创建一个ConfigMap,然后通过kubectl get来获取:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Create the ConfigMap
$ kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2
configmap "my-config" created

# Get the ConfigMap Details for my-config
$ kubectl get configmaps my-config -o yaml
apiVersion: v1
data:
key1: value1
key2: value2
kind: ConfigMap
metadata:
creationTimestamp: 2017-05-31T07:21:55Z
name: my-config
namespace: default
resourceVersion: "241345"
selfLink: /api/v1/namespaces/default/configmaps/my-config
uid: d35f0a3d-45d1-11e7-9e62-080027a46057

-o yaml的作用是通过yaml的形式来返回我们所要求的配置信息。

From Configuration File

除了上面的方式,我们还可以直接通过配置文件来创建(好吧,虽然我感觉是同一种,只不过是放到文件里面了而已……),首先,我们得有一个配置文件,假设名字叫做myconfigmap.yaml

1
2
3
4
5
6
7
8
apiVersion: v1
kind: ConfigMap
metadata:
name: customer1
data:
TEXT1: Customer1_Company
TEXT2: Welcomes You
COMPANY: Customer1 Company Technology Pct. Ltd.

然后,我们可以通过kubectl create -f来创建:

1
2
$ kubectl create -f myconfigmap.yaml
configmap "customer1" created

使用ConfigMap

我们可以有两种方法来使用ConfigMap:

通过env

我们可以设置env从ConfigMap读取:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
....
containers:
- name: rsvp-app
image: teamcloudyuga/rsvpapp
env:
- name: MONGODB_HOST
value: mongodb
- name: TEXT1
valueFrom:
configMapKeyRef:
name: customer1
key: TEXT1
- name: TEXT2
valueFrom:
configMapKeyRef:
name: customer1
key: TEXT2
- name: COMPANY
valueFrom:
configMapKeyRef:
name: customer1
key: COMPANY

....

这样,我们的container就可以读取到ConfigMap里面存储的信息了。

不过一般情况下,我个人推荐使用另一种方式:

通过Volume

这种方式我比较推荐,因为随着ConfigMap被修改(比如你想要更新一些设置),container里面对应的文件内容也会被修改,这样可以不用重启Container就让应用能够得到最新的配置信息。

这个内容需要一些Volume相关的知识,在此不做更多讲解,大家可以去参考官方文档

创建Secret

通过上面的部分,我们可以看到ConfigMap是用来做一些配置信息的,那么如果我们有一些机密信息比如说密钥、密码之类的信息,应该存在哪里呢?看到这个名字大家应该就明白了吧,kubernetes提供了Secret来存储相关的信息。

具体为什么要存在Secret里面,Secret和ConfigMap有什么区别,后面会讲到。

创建Secret

我们可以通过kubectl create secret来通过一个文件创建一个secret,如下:

1
2
3
4
5
6
7
8
9
10
# Create a file with password
$ echo 'mysqlpassword' > password.txt

# Make sure there is no trailing newline in the file, after our password.
# To remove any newline, we can use the tr command:
$ tr -Ccsu '\n' < password.txt > .strippedpassword.txt && mv .strippedpassword.txt password.txt

# Create the Secret
$ kubectl create secret generic my-password --from-file=password.txt
secret "my-password" created

我们也可以手动创建一个Secret,不过要注意,所有的secret的data都要以base64进行加密:

1
2
3
4
5
6
7
8
9
10
11
12
$ cat password.txt | base64
bXlzcWxwYXN3b3JkCg==

# and then use it in the configuration file:

apiVersion: v1
kind: Secret
metadata:
name: my-password
type: Opaque
data:
password: bXlzcWxwYXN3b3JkCg==

使用Secret

获取Secret

我们可以通过getdescribe来获取Secret,不过我们发现,kubectl并没有向我们返回Secret具体的内容:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ kubectl get secret my-password
NAME TYPE DATA AGE
my-password Opaque 1 8m

$ kubectl describe secret my-password
Name: my-password
Namespace: default
Labels: <none>
Annotations: <none>

Type Opaque

Data
====
password.txt: 13 bytes

在Pod里面使用

和ConfigMap一样,我们可以通过设置成env或者挂载成volume来使容器可以使用我们的secret。

具体格式如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
.....
spec:
containers:
- image: wordpress:4.7.3-apache
name: wordpress
env:
- name: WORDPRESS_DB_HOST
value: wordpress-mysql
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: my-password
key: password.txt
.....

关于如何在Volume中使用的还是需要自行查询文档学习。

扯淡的Secret

好了,总算正文部分完了,可以讲讲Secret和ConfigMap的关系了,以及讲讲Secret到底有多扯淡……

其实目前Secret的实现,就是ConfigMap把value用base64 encode了一下……

所以,其实不存在任何安全性……

只要decode一下就能出现原来结果,相当于明文存储……

base64这玩意儿都不能叫做加密,只能叫做编码……

所以我们都不说encrypt,而是encode和decode……

当然,k8s社区有在计划对Secret进行下一步的安全性增强,当然这是后话了……

反正目前为止,Secret基本和ConfigMap一样是明文存储……

知道有多扯淡了吧……