为什么在配置映射时不需要对k8s机密进行base64编码？

Question

为什么在配置映射时不需要对k8s机密进行base64编码？

在创建配置图时,您只需执行以下操作:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
data:
  SOME_KEY: a string value

但是当你想要创建一个秘密时,你必须 echo -n "some secret string" | base64将其结果放在一个文件中,如下所示:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  SOME_KEY: c29tZSBzZWNyZXQgc3RyaW5n

我真的好奇为什么会有这种差异？kubernetes秘密只是base64编码的字符串？我希望秘密在kubernetes中加密存储.

Answer 1

秘密可以包含二进制数据(类型为map[string][]byte),字节数组在JSON序列化中进行base64编码.

ConfigMaps仅包含字符串数据(类型为map[string]string),因此JSON序列化只输出字符串.

在1.10中,ConfigMaps有一个新binaryData字段,允许存储二进制数据,这是基本的64编码,就像秘密一样.https://github.com/kubernetes/kubernetes/pull/57938

Answer 2

为什么k8s secret需要base64编码

这允许您提供二进制数据（证书等）作为机密，并且还可以转义任何棘手的字符，例如 " ' \ 等。

kubernetes 的秘密只是 base64 编码的字符串吗？

是的，默认情况下 kubernetes 的秘密是不加密的。您必须自行设置静态加密，请参阅https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

Answer 3

根据ConfigMap 的文档，ConfigMap 对象可以具有“data”和“binaryData”字段。data 字段设计为包含 UTF-8 字符串，而 binaryData 字段设计为包含作为 base64 编码字符串的二进制数据。因此，ConfigMaps 中也可以包含 base64 数据。但这个选项被定位为次要的，我想说，“数据”字段使用得非常频繁。

根据Secret 的文档，Secret 对象可以指定“data”和/或“stringData”。数据字段中所有键的值必须是 base64 编码的字符串。如果不需要转换为 Base64 字符串，您可以选择指定 stringData 字段，该字段接受任意字符串作为值。因此，在这里，与 ConfigMap 相反，二进制方法被认为是主要的，因为使用更频繁。

但我们应该明白，base64 编码不是加密，它不能保护您的秘密不被使用。所有有权访问命名空间 X 中的 Pod/Deployment 的人都可以访问该命名空间中的 Secret 对象。因此，这些人可以简单地将这些 Base64 字符串解码为普通字符串。

我还没有找到任何官方解释为什么存储 Secrets 数据的主要方式是 base64，但我有一个假设，它至少是为了视觉防御而设计的，以便让看到并记住它们的眼睛变得复杂。