helm-diff 默认脱敏Secret，通过redactSecrets()在YAML生成前过滤data/stringData字段为REDACTED；但若启用--show-secrets、RBAC越权或绕过插件逻辑，仍可能泄露敏感信息。
helm-diff 默认会脱敏 Secret，但若漏配参数或权限失控，仍可能泄露敏感值——安全预审的关键不在“有没有 diff”，而在“谁在看、怎么看、看什么”。
— 为什么 helm diff upgrade 默认不显示 Secret 明文
helm-diff 在 diff/diff.go#L290-L338 中强制对 Secret 类型资源执行 redactSecrets()：所有 data 和 stringData 字段被替换为 REDACTED 或长度占位符（如 password: REDACTED # (12 bytes)）。这不是 UI 层面的隐藏，而是渲染后 YAML 生成前的结构化过滤。
但这个保护仅在以下条件下生效：
- 未传入
--show-secrets或--show-secrets-decoded - RBAC 权限未越界（例如没被授予
get secret全集群权限） - 运行时上下文未绕过插件逻辑（比如误用
helm template | kubectl diff替代helm diff）
— --suppress-secrets 不是默认开关，而是冗余参数
从 2025 年起，--suppress-secrets 已成冗余选项。当前版本（v3.9+ / v4.0+）中该行为已固化为默认策略，源码中无条件触发 redactSecrets()。显式加这个参数不会报错，但也不会改变行为——它只是历史兼容残留。
真正需要警惕的是反向操作：
-
--show-secrets：强制输出 base64 解码后的明文（危险！CI 中严禁启用） -
--show-secrets-decoded：仅解码不校验，仍暴露原始值（需配合 RBAC 严格限制使用人） - 省略
--namespace且 Helm context 具备 cluster-scope 权限：可能导致跨命名空间 Secret 被意外纳入比对范围
— RBAC 权限必须按命名空间收敛，不能靠 --namespace 补救
--namespace myapp 只影响 helm-diff 的资源查询目标，不约束其底层 Kubernetes client 的实际访问能力。如果绑定的 ServiceAccount 拥有 cluster-admin，它依然能读取所有命名空间的 Secret 清单——即使最终只比对 myapp 下的资源，过程中的权限调用已构成风险。
最小可行 RBAC 应明确限定：
- 使用
Role（非ClusterRole） -
resources列表只含真实用到的类型：deployments、services、configmaps、secrets（如有必要） -
verbs仅保留get和list，禁用watch（diff 不需要实时流） - ServiceAccount 与 RoleBinding 必须部署在目标命名空间内
— CI/CD 中判断“安全变动”的退出码陷阱
--detailed-exitcode 返回值常被误解：
-
0：无变更（安全） -
2：有变更（需人工确认） -
1：命令执行失败（如网络超时、YAML 解析错误、RBAC 拒绝）——这才是最危险的信号
很多流水线只检查 != 0 就阻断发布，却忽略 exit code 1 可能意味着 “helm-diff 根本没拿到 Secret 列表，因而没做脱敏，直接把原始 manifest 当作无差异输出了”。建议在 CI 脚本中显式捕获并日志记录完整退出码，并对 1 做告警而非静默跳过。
真正难防的不是镜像升级或副本增减，而是那些不会触发 ~ 符号却改写安全边界的变更：CRD 字段语义变化、PodSecurityPolicy 替换为 PodSecurity 配置、serviceAccountName 指向高权限账号——这些 helm-diff 看不见，必须靠独立的策略扫描工具补位。
