Kubernetes ConfigMap 和 Secret 生成器

数据开发人员安全

[iotools_kubernetes_configmap_secret_generator]

指导

Kubernetes ConfigMap 和 Secret 生成器

从简单的 KEY=value 对列表构建可直接用于 kubectl 的 Kubernetes ConfigMap 和 Secret 模板。生成器会验证资源名称是否符合 RFC 1123 规范，对 Secret 值进行 base64 编码，并输出干净的 YAML 文件，可直接管道传输到 Kubernetes 集群。您的数据不会离开浏览器。 data 字段 kubectl apply -f -。

如何使用

选择资源类型： ConfigMap 用于非敏感配置或密钥用于凭据、令牌和证书。
输入一个小写资源名称（符合 RFC 1123 规范），并可选地指定命名空间。
对于 Secrets，选择密钥类型（Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls，等等）并决定是否自动 base64 编码值（data:）或保持原始形式（stringData:).
粘贴您的键值对，每行一个。如果需要，添加标签和注解。 KEY=value per line. Add labels and annotations if you need them.
复制生成的 YAML 或将其下载为一个 .yaml 文件，以便直接用于 kubectl apply.

特征

一个工具完成 ConfigMap 和 Secret 的生成 – 在不丢失输入的情况下，可在不同资源类型之间切换。
自动 base64 编码 – Secret 值使用完整的 UTF-8 支持进行编码，因此包含非 ASCII 字符的密码和令牌可以正确地往返传输。
stringData 模式 – 当您希望生成可人工编辑的模板时，跳过编码；Kubernetes 会在应用时自动进行 base64 编码。
所有标准 Secret 类型 - Opaque, kubernetes.io/dockerconfigjson, kubernetes.io/tls, kubernetes.io/basic-auth, kubernetes.io/ssh-auth，并且 kubernetes.io/service-account-token.
实时 RFC 1123 验证 – 在提交前捕获无效的名称、命名空间和数据键，避免被拒绝。 kubectl apply 拒绝它们。
标签、注解和不可变标志 – 添加元数据，并为不应更改的资源启用不可变标志。
智能 YAML 引号处理 – 看起来像数字、布尔值或包含特殊字符的值会自动被引号包围；多行值使用块缩进。
100% 客户端 – 键和值永远不会离开浏览器；没有任何内容被上传、记录或传输。

 常问问题

Kubernetes 中 ConfigMap 和 Secret 有什么区别？

ConfigMap 以明文键值对的形式存储非敏感配置，而 Secret 专用于存储凭据、令牌等敏感信息。Secret 值以 base64 编码存储，Kubernetes 可以以更严格的权限将其挂载，与加密-at-rest 提供者集成，并限制哪些节点可以接收这些信息。
为什么 Kubernetes Secret 值要进行 base64 编码？

Base64 编码使二进制数据可以在 YAML/JSON 中安全传输，而不会破坏结构或产生无效字符。这并非加密，因此任何拥有集群 API 读取权限的人都可以解码这些值。真正的安全防护来自 RBAC、加密-at-rest 和审计日志。
在什么情况下应将 ConfigMap 或 Secret 设置为不可变？

当您预计不会更改该 ConfigMap 或 Secret 时，应将其设置为不可变，以减少大型集群中 kubelet 的负载。不可变资源会跳过基于监听的刷新，因此 kubelet 将停止发出周期性的 GET 请求。代价是，要更改值，必须删除并重新创建该资源。
Secret 模板中 data 和 stringData 有什么区别？

data 字段必须包含 base64 编码的值；API 服务器会原样存储。stringData 字段接受原始的 UTF-8 字符串，API 服务器会在创建或更新时自动进行 base64 编码。如果两者都存在，对于重叠的键，stringData 优先。在手动编写密钥时使用 stringData，而在与已编码工具集成时使用 data。