Kubernetes Secret 报 illegal base64 data：先核对真正提交的清单

创建 Secret 时收到 illegal base64 data at input byte，本地展示的几个 data 值却似乎已经编码。先核对命令真正读取的文件，以及模板最终生成的请求内容。如果错误片段中的值与正在检查的清单不同，继续重编码这份清单也不会修复实际提交的另一份文件。

本文针对普通 Opaque Secret 的 data 值在 API 请求解析阶段无法解码的情况。它与 Secret 已创建后应用密码不对、拉取凭据无权限不同；先解决数据格式，再验收应用收到的原始内容。

对上文件、字段和值，保留凭据隐私

记录失败命令中的路径，确认当前目录、文件版本、模板输入和实际部署目标。CI、Helm 或脚本生成清单时，应检查最终渲染结果，而不只看模板中的变量名称。

错误消息有时会附上 data 附近的请求片段，其中可能包含凭据。Base64 可以解码，不能把它当成脱敏结果；保留记录时限制权限，分享日志前遮住相关值，不要把完整 Secret 放进公开工单。

下面是用于说明格式错误的示例，值是假数据：

apiVersion: v1
kind: Secret
metadata:
  name: example-credentials
  namespace: team-app
type: Opaque
data:
  API_KEY: "plain_token_with_underscore"

这里的 API_KEY 值不是标准 Base64。Secret 的 data 要放编码后的字节，不能直接把原始令牌或 URL-safe Base64 当成同一种格式。标准编码中的字符集、长度和填充都有规则，不能只看它由字母数字组成。

检查实际出错字段是否未编码、用了 - 或 _ 的 URL-safe 形式、复制漏了末尾字符，或多带了空格等内容。Secret 的键名允许下划线，不表示编码后的值也允许下划线。不要给未知字符串机械补两个等号，应该从可靠原始值重新生成正确编码。

如果配置流程持有原始字符串，可以使用 stringData，由 API 处理编码。以下是完整结构示例，名称、空间和令牌均为占位值：

apiVersion: v1
kind: Secret
metadata:
  name: example-credentials
  namespace: team-app
type: Opaque
stringData:
  API_KEY: "example-token"

stringData 中放原始字符串，不能再放一次 Base64 后期待应用收到原值。同一个键同时出现在 data 与 stringData 时，stringData 的值优先；避免在两处维护不同副本。

stringData 不适合直接套到所有配置管理流程，尤其 server-side apply 的字段管理有相应限制。使用这一方式前确认部署工具的处理规则；需要管理 data 的流程仍应从原始字节生成编码，保留现有声明方式。

清单里的明文和编码值都需要按凭据保管。不要为了格式错误，把真实令牌写进版本库或共享日志；如果已经泄露，修改编码形式不能消除泄露，需要按凭据流程轮换。

需要继续使用 data 时，从原始值编码，避免先编码一次又把结果当原文编码第二次。以下仅用假值说明无末尾换行的输入方式，Linux 上可使用：

printf '%s' 'example-token' | base64

输出再交给清单中的对应字段。真实凭据应通过已有安全文件或凭据管理工具取得，避免直接放进命令历史。多行输出的处理也应由生成工具完成，不手工删改编码的中间部分。

普通 echo 常在输入后追加换行。它不会让 Base64 变得非法，却可能使应用读到 example-token 后多一个换行，随后认证失败。需要原值没有换行时，输入端就应保留这一条件，不能从编码字符串末尾盲目删除 Cg== 来修复。

编码文本里的 CR、LF 与被编码原始值里的换行是两件事。标准解码器可能忽略编码文本的换行，但解码出的原始换行仍属于数据。不要把所有换行或所有空白都当成可随意删除的格式噪声。

新建 Secret 时，先确认目标 namespace 和名称没有已有业务对象，再按获准的部署流程创建。已有 Secret 更新前保存受控的旧版本，核对它是否 immutable、是否由其他控制器管理，以及应用采用文件还是环境变量读取。

格式通过并不表示新的凭据已进入运行中的应用。环境变量不会因 Secret 更新自动刷新；其他使用方式也应按应用和集群的更新机制处理。需要滚动替换时安排服务影响，不因一次格式修正删除整个工作负载。

成功标准是创建或更新不再发生 Base64 解析错误，并在受控环境中确认应用读到的值与预期原始字节一致、实际认证路径正常。核对时避免把凭据直接输出到终端日志。若 Secret 已能创建但应用仍拒绝密码，应重新检查原值、额外换行和认证权限，而不是继续重编码已正确的数据。

回退已有对象时恢复已保存的原版本及对应应用配置；这不会撤销已经发生的凭据轮换，也不能让外部服务重新接受已失效的旧令牌。原始令牌来源已经不可靠时，应先取得可验证的新值，不能用“清单被接受”证明内容正确。