两种数据写法
Secret 有两个存放键值的位置：data 要求值是 base64 编码后的字符串，stringData 允许直接写明文，API Server 在落库时会自动把它转成 data。这个不对称带来两条铁律：写入时用 stringData 最省心，因为不用手工编码；读取时永远只有 data，拿到的一定是 base64 形式，需要解码才能看到原文。
两种写法对比
| 维度 | data | stringData |
|---|---|---|
| 值的形态 | 必须是 base64 编码字符串 | 直接写明文，可用特殊字符 |
| 写入过程 | 原样存储，不做解码校验 | apiserver 自动转 base64 后存入 data |
| 读取结果 | 看到 base64 | 看不到 stringData，读出来仍是 data 的 base64 |
| 键名冲突 | 以 stringData 为准 | 同一次提交里同名键由它覆盖 |
| 适用建议 | 由工具生成清单时使用 | 人工编写、需要粘贴复杂口令时使用 |
典型使用场景
- 手工编写清单：把生成好的随机口令直接写进 stringData，避免每次都要 base64 编码
- 流水线渲染清单：CI 把变量填进 stringData 生成临时 Secret，再 apply 到集群
- 从外部系统导入凭据：脚本把导出的明文用 stringData 提交，减少一次手工编码步骤
- 核对线上凭据：用 jsonpath 取 data.password 再 base64 -d，确认与预期一致
- 生成镜像拉取凭据：kubectl create secret docker-registry 同样落到 data 的 .dockerconfigjson 键
两种写法示例
两种写法示例
apiVersion: v1
kind: Secret
metadata:
name: db-pass
type: Opaque
stringData:
password: 'S3cr3t-With-Special-Chars!' # 明文写，落库时自动转 base64
data:
username: YWRtaW4= # 等价于 echo -n admin | base64编码与解码
编码与解码
printf 'admin' | base64 # 生成 base64：务必用 printf 或 echo -n
printf 'YWRtaW4=' | base64 -d # 解码并原样输出，不加换行
kubectl get secret db-pass -o jsonpath='{.data.username}' | base64 -d; echo
kubectl get secret db-pass -o jsonpath='{.data}' | jq -r 'to_entries[] | "\(.key)=\(.value|@base64d)"'字段读法
| 字段 | 含义 | 注意点 |
|---|---|---|
| type | Secret 类型，Opaque 为通用类型 | kubernetes.io/tls、dockerconfigjson 等类型有固定键名要求 |
| data.<key> | base64 编码后的值 | 解码后不要贴进工单或聊天记录 |
| stringData.<key> | 清单里的明文写法 | read 对象时该字段不存在，它与 data 合并 |
| metadata.name | Secret 名 | 改名相当于新建，引用它的工作负载要同步改 |
base64 是编码而不是加密：任何能读到 Secret 对象的人都能立即还原明文。真正需要保护时依赖的是静态加密（EncryptionConfiguration，如 KMS 或 aescbc）与收紧的 RBAC，而不是编码形式。
kubectl create secret generic 带 --dry-run=client -o yaml 可以把已有明文文件转成清单再提交，比手工编码可靠；同一次提交里 data 与 stringData 出现相同键时以 stringData 为准，但不建议依赖这个行为。