3. Helm 核心概念：Chart、Release、Repository、Values，以及 Helm v3 的安全特性
在深入 Cilium 的 Helm 交付与准入控制之前，必须牢固掌握 Helm 自身的核心抽象与安全模型。Helm v3 相比 v2 在架构与安全性上发生了根本性变化，理解这些概念是后续编写 Cilium Chart 和配置准入控制策略的基础。
3.1 四大核心抽象
Helm 将 Kubernetes 资源的打包、配置与部署抽象为四个核心概念，它们构成了 Helm 的操作模型。
| 概念 | 定义 | 类比（类比操作系统） | 关键特征 |
|---|---|---|---|
| Chart | Kubernetes 资源的打包格式，包含模板、默认值、依赖和元数据。 | 软件安装包（.deb/.rpm） | 版本化、可依赖、可签名 |
| Release | Chart 在目标集群中的一次运行实例，包含部署状态与历史记录。 | 运行中的进程实例 | 每个 Release 有唯一名称、版本号、修订历史 |
| Repository | Chart 的存储与分发索引，通常托管在 HTTP 服务器上。 | APT/YUM 软件源 | 通过 index.yaml 索引，支持 OCI 注册表 |
| Values | Chart 模板的输入参数，用于定制化部署行为。 | 配置文件或环境变量 | 支持默认值、层级覆盖、类型校验 |
实践要点： 在 Cilium 部署中，
values.yaml 控制着从 CNI 插件选择、IPAM 模式到 Hubble 可观测性组件的全部行为。理解 Values 的覆盖优先级（--set > 自定义 values 文件 > Chart 默认值）是避免配置冲突的关键。
3.2 Helm v3 架构变革与安全特性
Helm v3 移除了 Tiller 服务端组件，将 Release 信息直接存储在 Kubernetes Secret 中。这一架构变化带来了显著的安全提升。
架构变化： Helm v2 中 Tiller 拥有集群级权限，成为安全攻击面。v3 完全依赖用户本地
kubeconfig 的 RBAC 权限，实现了“以用户身份运行”的安全模型。
3.2.1 Helm v3 核心安全特性清单
- 无 Tiller 架构： 消除服务端特权组件，避免权限提升与横向移动风险。
- Release 信息加密存储： Release 对象以 Secret 形式保存在目标命名空间，默认使用
secrets存储后端，支持加密。 - Chart 签名与验证： 使用 GnuPG 对 Chart 包进行数字签名，确保来源可信与完整性。
- OCI 注册表支持： Chart 可存储在 OCI 兼容的容器镜像仓库中，复用镜像签名、扫描与访问控制策略。
- 基于 Kubernetes RBAC 的权限控制： 用户只能在其
kubeconfig授权的命名空间和资源范围内操作。
安全警示： 虽然 Helm v3 移除了 Tiller，但 Release Secret 默认未加密。在生产环境中，建议启用 Kubernetes 静态加密（Encryption at Rest）来保护 Release 中的敏感配置数据。
3.3 Helm v3 安全架构与操作流程
下图展示了 Helm v3 的安全架构与一次典型的 Chart 安装流程，重点突出无 Tiller 架构下的身份认证与数据流。
3.4 Chart 签名与验证实践
Helm v3 支持使用 GnuPG 对 Chart 进行签名，确保 Chart 在传输和存储过程中未被篡改。这是准入控制链中“来源可信”的第一道防线。
3.4.1 签名与验证流程
- 生成 GPG 密钥对：
gpg --full-generate-key - 导出公钥：
gpg --export > public.key - 签名 Chart：
helm package --sign --key 'your-key-name' --keyring ~/.gnupg/secring.gpg ./mychart - 验证 Chart：
helm verify --keyring ./public.key ./mychart-0.1.0.tgz
生产建议： 在 CI/CD 流水线中，将 Chart 签名步骤集成到发布阶段，并将公钥分发给所有需要验证 Chart 的集群或工具（如 Kyverno、OPA Gatekeeper）。对于 Cilium 这类基础设施组件，建议使用硬件安全模块（HSM）或密钥管理服务（KMS）保护签名密钥。
3.5 Values 的层级结构与覆盖优先级
Values 是 Helm 模板化的核心输入。理解其层级结构与覆盖优先级，对于编写可复用的 Cilium Chart 至关重要。
3.5.1 Values 覆盖优先级（从低到高）
| 优先级 | 来源 | 示例 | 适用场景 |
|---|---|---|---|
| 1（最低） | Chart 内置 values.yaml |
image.tag: "v1.14.0" |
提供安全、合理的默认值 |
| 2 | 父 Chart 的 values.yaml |
子 Chart 继承父 Chart 的默认值 | 多 Chart 依赖场景 |
| 3 | 用户自定义 values 文件 | helm install -f my-values.yaml |
环境差异化配置（开发/生产） |
| 4（最高） | --set 命令行参数 |
--set image.tag=v1.15.0 |
临时覆盖、CI/CD 参数注入 |
3.5.2 全局 Values 与子 Chart 作用域
在 Helm 依赖管理中，global 字段允许父 Chart 将值传递给所有子 Chart，而子 Chart 的 Values 默认作用域在其自身名称下。
# 父 Chart values.yaml
global:
registry: "docker.io"
cilium:
image:
tag: "v1.15.0"
hubble:
enabled: true
最佳实践： 在 Cilium 的 Helm Chart 中，使用
global 字段传递镜像仓库地址、集群名称等全局参数；使用 cilium 作用域下的字段控制 Cilium 特定组件的配置。避免在子 Chart 中直接引用父 Chart 的非全局字段，以保持模板的可移植性。
3.6 Helm v3 安全特性总结
下表对比了 Helm v2 与 v3 在关键安全维度上的差异，帮助理解 v3 的安全优势。
| 安全维度 | Helm v2 | Helm v3 |
|---|---|---|
| 服务端组件 | Tiller（集群级权限） | 无（客户端直接调用 API） |
| Release 存储 | ConfigMap（默认命名空间） | Secret（目标命名空间） |
| 权限模型 | Tiller 的 ServiceAccount | 用户 kubeconfig 的 RBAC |
| Chart 签名 | 支持（需插件） | 原生支持（helm verify） |
| OCI 支持 | 不支持 | 原生支持（v3.8+） |
| 命名空间隔离 | 弱（Tiller 跨命名空间） | 强（Release 在目标命名空间） |
迁移注意： 从 Helm v2 迁移到 v3 时，需使用
helm 2to3 插件迁移 Release 数据。迁移后，原有 Tiller 的 ServiceAccount 和 ClusterRoleBinding 应被清理，避免遗留权限风险。