KubeBYON 用户 vCluster 权限边界与信任收敛规划

最后更新：2026-05-23

本文档记录 KubeBYON 在“平台如何访问用户虚拟集群”上的当前边界、风险认知与后续改进方向。

它不是对当前实现的宣传文案，而是一个面向未来版本的产品 / 架构改进说明。

1. 问题范围

本文关注的是：

• 用户的 vCluster（虚拟集群）
• 平台后端对用户 vCluster 的默认访问权限
• 如何让用户更容易信任“平台不会进行未授权访问”

本文不重点讨论宿主集群本身的权限问题。

原因是：

• 宿主 Kubernetes / k3s 本来就是托管方自己搭建和维护的基础设施
• KubeBYON 在宿主集群侧天然需要较高编排权限，才能创建 / 更新 / 删除 vCluster
• Helm 部署现在默认使用宿主集群 scoped RBAC，而不是直接绑定内置 cluster-admin；rbac.clusterAdmin=true 仅作为回退选项

因此，这里的核心问题不是“平台是否能管理自己的宿主集群”，而是：

平台在用户 vCluster 内是否必须长期持有高权限身份，以及如何把这类权限收敛到更小、可审计、可控的范围。

2. 当前实现下的真实边界

截至 2026-05-23，当前实现中的关键事实包括：

1. KubeBYON 会读取宿主集群中导出的 vCluster kubeconfig Secret
2. 平台后端会使用该 kubeconfig 访问用户 vCluster
3. 目前并未把用户 vCluster 内的能力拆分成多套最小权限身份
4. 从效果上看，平台默认持有的是较高权限管理能力

这些能力当前被用于：

• 生成 / 读取集群连接信息与 kubeconfig
• 在 kube-system 中创建 bootstrap token Secret
• 读取节点状态
• 执行节点运维操作（cordon / uncordon / drain / delete）
• 写入 / 删除 Admission Webhook 配置
• 在启用托管业务流量入口时，在用户 vCluster 内安装 / 升级 / 删除托管 ingress controller
• 通过后端代理执行受限 kubectl 命令

这意味着：

• 普通租户之间已经有应用层隔离
• 但平台本身仍应被视为用户 vCluster 的高权限受信任方

3. 为什么这会成为后续产品化问题

在当前阶段，这种设计有现实价值：

• 实现更直接
• 便于快速落地集群编排与运维功能
• 对单机 / 自托管 / 小规模环境更友好

但它也带来几个产品化问题：

1. 用户难以确认平台是否具备“默认不访问”的约束
2. 用户难以区分“平台日常自动化能力”和“人工高权限排障能力”
3. 平台一旦保留常驻高权限身份，信任更多依赖制度与承诺，而不是系统设计
4. 通用 kubectl 代理会进一步放大这种感知风险

因此，这个问题应被明确视为：

未来生产化与企业级信任建设的重要方向之一。

4. 需要明确承认的架构事实

即使未来收敛了应用层默认权限，仍然需要诚实面对以下事实：

4.1 共享宿主集群场景下，不存在“绝对不可触达”

如果用户 vCluster 运行在托管方控制的宿主集群中，那么宿主集群管理员理论上仍然可能通过：

• 读取 vCluster 导出的 Secret
• 访问 vCluster 控制面 Pod
• 介入网络、存储或运行时层

来接触用户 vCluster。

因此，KubeBYON 的后续目标不是宣称：

“托管方在任何意义上都绝对无法接触用户 vCluster”

而是更现实地做到：

• 平台应用默认不常驻持有不必要的 full admin 能力
• 必须高权限时走更窄权限或临时授权
• 所有高敏感访问都有审计、可通知、可追责

4.2 更强隔离需要更强部署形态

如果需要更强保证，通常要走：

• 单租户专有宿主集群
• 独立基础设施隔离
• 私有化 / 自托管

这类能力不属于当前共享托管形态下可完全由应用层 RBAC 解决的问题。

5. 哪些功能确实需要较高权限，哪些不一定

并不是所有平台能力都必须依赖用户 vCluster 内的 cluster-admin。

5.1 不一定需要 full cluster-admin

以下能力通常可以收敛为只读或窄权限：

• 集群基础信息读取
• 节点 / Pod / Event 等只读查询
• kubeconfig 可用性探测
• 部分观测与诊断能力

5.2 需要较高权限，但可以拆成专门角色

A. Token Issuer

用途：

• 在 kube-system 中创建 bootstrap token Secret

特点：

• 需要 secrets 写权限
• 但不一定需要 full cluster-admin
• 可以限制在指定 namespace 与指定 Secret 类型 / 命名前缀

B. Node Operator

用途：

• cordon / uncordon / drain / delete

特点：

• 需要对 nodes、驱逐相关资源有 cluster-scoped 权限
• 权限不小，但可以独立于其他能力单独授予

C. Webhook Manager

用途：

• 管理 Mutating / Validating Webhook 配置

特点：

• 需要 cluster-scoped 权限
• 但仍可以只授予与 webhook 相关的资源，而不是整个集群 full admin

D. Managed Ingress Operator

用途：

• 在用户 vCluster 内安装、更新、卸载托管 ingress controller

特点：

• 需要对 namespace、deployment、service、ingressclass 等资源有较高权限
• 可以考虑与通用运维 / 节点运维权限拆开
• 如果未来托管业务流量入口能力继续扩大，这一角色更应独立建模

5.3 当前最值得优先收敛的能力

当前最需要谨慎处理的是：

• 后端通用 kubectl 代理

原因：

• 它天然更接近“平台代用户执行管理员动作”
• 即使做了命令与 flag 限制，也仍然属于高敏感能力

因此，后续应优先考虑：

• 默认关闭
• 拆成只读模式与紧急支持模式
• 或缩减为明确白名单操作，而不是通用命令代理

6. 建议的目标模型

未来版本中，用户 vCluster 内的权限模型建议至少拆成以下几类身份：

额外建议：

• 将后端 kubectl 代理拆成：
  • 只读代理
  • 支持态高权限代理
• 不再默认让所有平台自动化能力共用同一套高权限 kubeconfig

7. 产品与系统层面的改进方向

7.1 默认原则

后续产品化应遵循以下原则：

1. 默认最小权限
2. 默认不保留不必要的常驻高权限
3. 高敏感访问必须留痕
4. 高敏感访问尽量让用户可见
5. 紧急访问必须具备时间边界

7.2 推荐功能项

建议作为未来版本的正式改进项：

• 收敛平台对用户 vCluster 的默认高权限访问
• 将用户 vCluster 内权限拆分为多套最小权限角色
• 默认关闭或收窄通用 kubectl 代理
• 引入 break-glass 紧急访问模式
• 让高敏感平台访问产生用户可见的审计 / 通知事件
• 为 kubeconfig 下载、后端代理命令、人工支持访问补齐审计记录
• 为托管业务入口相关的控制器安装 / 升级 / DNS 自动化补齐更清晰的审计边界
• 支持更清晰的“共享托管 / 专有部署 / 自托管”信任说明

8. 分阶段落地方向

P0：先补清晰边界与可见性

• 文档中明确当前信任边界
• 对高敏感操作补齐审计事件
• 在控制台中让用户能看到平台访问痕迹
• 默认关闭或收窄高风险后端代理入口

P1：拆分默认权限

• 把用户 vCluster 内的只读、token、节点运维、webhook 管理、managed ingress 管理拆成独立身份
• 避免多种能力共用一套长期高权限 kubeconfig
• 让产品配置能表达“是否允许平台执行某类敏感动作”

P2：引入短时授权与支持流程

• 临时签发高权限身份
• 增加审批 / 过期 / 回收
• 支持用户可见的 break-glass 记录

P3：更强信任版本

• 单租户专有部署
• 自托管版本
• 更强的 Secret / KMS 管理

9. 当前文档定位

本文是一个未来改进方向文档，其作用是：

1. 明确承认当前平台的真实权限边界
2. 避免用不准确的话术过度承诺“平台绝对无法访问用户 vCluster”
3. 为后续企业级信任、审计与权限收敛设计留出路线图

它与：

• docs/architecture/current-architecture.md
• docs/architecture/managed-workload-ingress-plan.md
• docs/api/http-api.md

一起构成“当前实现 + 风险认知 + 后续方向”的完整说明。