3. Helm 架构回顾：Tiller（已弃用）与 Helm 3 的客户端-only 架构对权限的影响
Helm 的架构演进是理解 Kubernetes 集群权限边界的关键分水岭。从 Helm 2 的 Tiller 服务端组件到 Helm 3 的 客户端-only 模式，权限模型发生了根本性变化。理解这一变化，是后续设计安全 Chart 和审计链路的基础。
3.1 Helm 2 架构：Tiller 的“超级权限”困境
Helm 2 在集群内部署了一个名为 Tiller 的服务端组件。Tiller 通常运行在 kube-system 命名空间，并拥有集群级别的 cluster-admin 权限。其工作流程如下：
- 客户端（helm CLI） 将 Chart 和 Values 发送给 Tiller。
- Tiller 在服务端渲染模板，生成 Kubernetes 资源清单。
- Tiller 使用自身的 ServiceAccount 直接调用 Kubernetes API 创建资源。
cluster-admin 权限意味着任何能访问 Tiller 的用户（或 CI 系统）都间接获得了集群的超级管理员权限。这违反了最小权限原则，且无法对用户进行细粒度的权限隔离。
下表对比了 Helm 2 与 Helm 3 在权限模型上的核心差异：
| 对比维度 | Helm 2 (Tiller) | Helm 3 (客户端-only) |
|---|---|---|
| 架构模式 | 客户端 + 服务端 (Tiller) | 纯客户端 |
| 权限主体 | Tiller 的 ServiceAccount | 执行 helm 命令的用户/ServiceAccount |
| 默认权限范围 | 集群管理员 (cluster-admin) | 由 kubeconfig 中的用户权限决定 |
| 权限隔离 | 困难，所有用户共享 Tiller 权限 | 原生支持，基于 kubeconfig 的 RBAC |
| 审计追踪 | 模糊，操作者身份难以追溯 | 清晰，直接关联到 kubeconfig 用户 |
3.2 Helm 3 架构：客户端-only 与权限回归
Helm 3 彻底移除了 Tiller，回归到纯粹的客户端架构。所有操作（模板渲染、资源安装、升级、删除）都在 helm CLI 所在的环境中完成，然后直接使用 当前用户的 kubeconfig 所携带的凭据与 Kubernetes API 交互。
这一变化带来了以下关键影响：
- 权限回归到用户： 用户能做什么，完全取决于其 kubeconfig 中配置的 RBAC 权限。不再有“Tiller 后门”。
- 原生审计支持： Kubernetes API Server 的审计日志可以直接记录到操作者的身份（User Info），审计链路清晰完整。
- 命名空间隔离： 用户只能在其有权限的命名空间中部署 Chart，天然支持多租户场景。
下面的 SVG 图直观展示了两种架构在权限流上的本质区别：
3.3 权限模型变化对审计链路的影响
Helm 3 的客户端-only 架构使得审计链路从“模糊”变为“精确”。在 Helm 2 中，Kubernetes 审计日志只能记录到 Tiller 的 ServiceAccount，无法区分具体是哪个用户通过 Tiller 执行了操作。而在 Helm 3 中，审计日志直接记录执行 helm 命令的用户身份。
以下是一个简化的审计日志对比示例：
# Helm 2 审计日志（模糊）
{
"user": { "username": "system:serviceaccount:kube-system:tiller" },
"verb": "create",
"resource": "deployments",
"namespace": "default"
}
# Helm 3 审计日志（精确）
{
"user": { "username": "alice@example.com" },
"verb": "create",
"resource": "deployments",
"namespace": "default"
}
user 字段设置为可识别的员工 ID 或服务账号名称。
3.4 迁移到 Helm 3 的权限检查清单
从 Helm 2 迁移到 Helm 3 时，需要重新审视和调整权限策略。以下清单可以帮助你完成平滑迁移：
| 步骤 | 操作内容 | 说明 |
|---|---|---|
| 1 | 移除 Tiller 部署 | 使用 kubectl delete deployment tiller -n kube-system 清理 |
| 2 | 创建命名空间级 RBAC | 为每个团队/项目创建独立的 Role 和 RoleBinding |
| 3 | 配置 kubeconfig | 确保每个用户的 kubeconfig 包含正确的命名空间上下文 |
| 4 | 启用审计日志 | 在 API Server 配置中启用审计策略，记录 RequestResponse 级别 |
| 5 | 测试权限边界 | 使用 helm install --dry-run --debug 验证权限是否按预期工作 |
通过以上分析可以看出，Helm 3 的架构演进不仅仅是技术上的简化，更是安全模型的一次重要回归——将权限控制权交还给 Kubernetes 原生的 RBAC 体系，为后续的审计链路建设奠定了坚实的基础。