Multus-CNI中Delegate插件访问Kubernetes API的权限问题分析

在Kubernetes网络插件生态中，Multus-CNI作为多网络接口管理解决方案，其厚插件模式（thick plugin）在v4.0.2版本中存在一个值得关注的技术问题。当Delegate插件（如userspace-cni）需要访问Kubernetes API时，由于执行环境隔离导致服务账号令牌不可见，这引发了我们对CNI插件权限模型的深入思考。

问题本质

厚插件模式下，Multus通过chroot到/hostroot环境执行Delegate插件，这种设计原本是为了确保插件能正确访问主机网络命名空间。然而副作用是：插件无法访问Multus Pod自身挂载的/var/run/secrets/kubernetes.io/serviceaccount目录，因为该目录存在于容器文件系统中而非主机上。

技术背景

Kubernetes网络插件通常需要两类API访问：

1. 读取操作：获取Pod注解、UID等元数据（如userspace-cni需要获取共享目录配置）
2. 写入操作：更新网络状态注解（类似k8s.v1.cni.cncf.io/network-status）

传统解决方案是复用Multus的kubeconfig，但在chroot环境下这变得不可行。值得注意的是，这种模式在thin插件中同样存在问题，因为thin插件直接运行在主机环境。

解决方案方向

1. 独立凭证管理： Delegate插件应当维护自己的kubeconfig配置，而非依赖Multus的凭证。这包括：

• 通过DaemonSet预置RBAC权限
• 使用独立的ServiceAccount
• 将凭证挂载到主机特定路径

2. 凭证注入模式：

• 通过ConfigMap传递集群CA证书
• 使用TokenRequest API动态获取短期令牌
• 将凭证写入hostPath供插件访问

3. 架构改进建议：

• 在Delegate插件中实现凭证自动发现机制
• 支持通过环境变量指定kubeconfig路径
• 建立标准的凭证传递规范

实践启示

这个案例揭示了CNI插件开发中的重要原则：网络插件应该设计为自包含的组件，明确区分控制平面（API访问）和数据平面（网络配置）。在Multus生态中，Delegate插件需要：

1. 声明清晰的RBAC需求
2. 实现灵活的凭证加载逻辑
3. 处理主机与容器环境的路径差异
4. 考虑凭证的轮换与更新机制

对于已经遇到此问题的开发者，短期解决方案可以修改Delegate插件代码，使其支持从预定义的主机路径加载凭证。长期来看，建立跨CNI插件的统一凭证管理规范将是更可持续的方向。

演进趋势

随着Kubernetes网络需求的复杂化，未来可能出现：

1. 标准化的CNI插件凭证API
2. 基于CSI风格的Secret存储方案
3. 服务网格风格的mTLS认证集成
4. 无服务账号的Workload Identity方案