Kubernetes 中的 ConfigMap 是如何保证安全的？

发表于 作者 IT之美

在 Kubernetes 中,ConfigMap 是一种资源对象,用于存储非敏感配置数据,可以用来向 Pod 传递配置信息。与 Secret 相比,ConfigMap 中的数据是明文存储的,主要用于存储非敏感的配置数据。

那么 Kubernetes 如何保证 ConfigMap 的安全?主要有以下几点:

  1. ConfigMap 数据明文存储:ConfigMap 中的数据是明文存储在 Etcd 中的,所以不适合存储敏感信息。
  2. ConfigMap 只有在被引用时才会被传播到节点上:与 Secret 类似,ConfigMap 也不会默认被传播到所有节点上,只有被 Pod 引用时才会传播到运行该 Pod 的节点上。
  3. ConfigMap 可以通过环境变量、命令行参数和 Volume 文件形式在 Pod 中使用:这些不同的使用形式可以根据具体场景选择,以控制 ConfigMap 数据的使用安全性。
  4. 节点上的 Volume 文件在Pod 删除后也会被删除:与 Secret 相同,这可以避免 ConfigMap 数据遗留在节点上。

ConfigMap 的工作流程基本与 Secret 相同,主要区别在于数据存储形式(明文 vs 加密)和传递给Pod 的方式。ConfigMap 的工作流程是:

  1. 创建一个 ConfigMap 对象,直接存储配置数据在数据字段中。
  2. 在 Pod 中以环境变量、命令行参数或 Volume 文件形式引用该 ConfigMap。
  3. 当 Pod 调度到节点上时,kubelet 获取 Pod 使用到的 ConfigMap 对象。
  4. 根据引用方式,kubelet 将 ConfigMap 数据注入到 Pod 或作为 Volume 映射到 Pod。
  5. Pod 中的容器可以通过对应的方式(环境变量、命令行参数或文件)获取 ConfigMap 数据。
  6. Pod 删除后,Volume 中的 ConfigMap 文件也被删除。

示例:

yaml
apiVersion: v1
kind: ConfigMap 
metadata: 
  name: myconfig
data: 
  LOG_LEVEL: DEBUG
  DB_Host: dbhost
yaml
apiVersion: v1  
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mypod
      image: redis  
      env:
        - name: LOG_LEVEL
          valueFrom:  
            configMapKeyRef:
              name: myconfig
              key: LOG_LEVEL
      args: ["--DB_Host=$(DB_Host)"] 
  restartPolicy: Never
  1. 创建一个 ConfigMap 对象,存储 LOG_LEVEL 和 DB_Host 配置数据。
  2. Pod 以环境变量和命令行参数形式引用该 ConfigMap。
  3. Pod 调度到节点后,kubelet 获取 myconfig ConfigMap 对象。
  4. Kubelet 将 ConfigMap 中的 LOG_LEVEL 设置为环境变量,DB_Host 设置为命令行参数。
  5. Pod 里的容器可以通过环境变量 $LOG_LEVEL 和命令行参数 –DB_Host 获取配置数据。
  6. Pod 删除后,相关的 ConfigMap 数据也被删除。

所以总结来说,ConfigMap 的安全性主要来源于:

  1. 数据明文存储,不适合敏感信息
  2. 只有被引用时才传播到节点
  3. 可以以环境变量、命令行参数或Volume文件形式使用
  4. 与Pod生命周期绑定, Pod删除时一起删除