helm原生values.yaml不能直接进git，因其为纯文本且base64编码不等于加密，易被还原；helm-secrets通过本地加密（如age/pgp）、git存储密文、部署时解密，实现敏感配置“可版本化、不可明读”。
直接把密码、API密钥、证书等敏感配置写进 Helm 的 values.yaml 并提交到 Git 仓库，等于把钥匙挂在门上。Helm-secrets 插件通过本地加密 + Git 安全存储 + 部署时自动解密的机制，让敏感配置真正“可版本化、不可明读”。核心不是替换 Helm，而是给它加一层加密壳。
为什么 Helm 原生配置不能直接进 Git？
Helm 默认的 values.yaml 是纯文本文件。哪怕只存一个数据库密码：
- Base64 编码 ≠ 加密，
echo "U3VwZXJTZWNyZXQ=" | base64 -d一秒还原 - 一旦误提交，所有有仓库读权限的人（包括离职员工、CI 日志、审计快照）都能看到原始值
- 不同环境（dev/staging/prod）共用同一份 values 文件时，密钥混杂、轮换困难、审计无迹可循
helm-secrets 是怎么工作的？
它不改 Helm 流程，只在渲染前插入一道加密/解密环节：
Github Stars Analyzer
下载
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
-
开发阶段：用
sops（支持 AWS KMS / GCP KMS / Age / PGP）加密敏感字段，生成secrets.yaml.gpg或secrets.yaml.age - Git 存储：只提交加密后的文件，明文永不落地仓库；.gpg/.age 文件对 Git 来说就是普通二进制资产
- 部署阶段：Helmfile 或 Helm 调用 helm-secrets 插件，用本地已授权的密钥解密，再合并进 values 渲染 Chart
快速上手三步走
以 Age（轻量、免密钥服务器、推荐 DevOps 团队起步）为例：
-
1. 安装与初始化：
brew install age && age-keygen -o age.agekey（macOS）
把公钥age.agekey.pub配置到 CI 环境或共享密钥管理服务中 -
2. 加密敏感文件：
echo -n 'my-db-password' | age -r age.agekey.pub > secrets.yaml.age
或批量加密完整 YAML：sops --encrypt --age age1ql... --input-type yaml values.secrets.yaml > values.secrets.yaml.age -
3. 在 helmfile.yaml 中声明使用：
releases:<br> - name: myapp<br> chart: ./charts/myapp<br> values:<br> - values.yaml<br> - values.secrets.yaml.age # 自动识别 .age 后缀并解密
和 Sealed Secrets 的关键区别
很多人混淆 helm-secrets 和 Sealed Secrets，它们解决的是不同环节的问题：
- helm-secrets：保护的是 Helm 模板渲染前的输入配置，加密发生在开发者本地或 CI，适用于 GitOps 流水线的“配置即代码”层
- Sealed Secrets：保护的是 Kubernetes 集群中最终生成的 Secret 对象，加密后内容可进 Git，由集群内控制器解密为原生 Secret，属于运行时资源层
- 两者可共存：用 helm-secrets 管理 Helm 值文件里的密钥，再用这些值生成 SealedSecret CRD 提交到 Git —— 双重防护
