自定义CSI驱动对接Kubernetes RBAC API是否必须指定ClusterRole

首先明确结论：绝大多数场景下，为CSI驱动配置ClusterRole是强制要求，无法绕开的核心原因和CSI驱动的工作逻辑、Kubernetes的资源权限模型直接相关，具体原因如下：

• CSI驱动需要感知全集群的存储相关资源：包括集群维度的PersistentVolume（PV）、StorageClass、VolumeAttachment、CSINode等资源，这些都属于集群级资源，不属于任何命名空间，普通的命名空间级别Role根本没有权限操作集群级资源，只有ClusterRole能定义集群级资源的操作权限。
• CSI驱动的核心组件（provisioner、attacher、resizer等sidecar以及驱动本体）通常需要监听全集群的PVC创建、卷挂载/卸载、卷扩容等请求，这些跨命名空间的监听操作也必须通过ClusterRole授予对应权限才能正常执行。
• 只有一种极端场景可以不用全局ClusterRole：如果你的CSI驱动完全不需要操作任何集群级资源，仅在单个固定命名空间内提供本地存储能力，且不需要对接Kubernetes原生的PV/PVC调度体系，可以仅配置命名空间级Role，但这种场景已经完全脱离了标准CSI驱动的设计规范，没有通用性。

如果你之前测试发现绕不开ClusterRole，属于正常情况，标准CSI驱动的RBAC配置都需要遵循以下逻辑：

1. 定义ClusterRole，配置CSI驱动所需的集群级资源、跨命名空间资源操作权限
2. 创建ClusterRoleBinding，将该ClusterRole绑定到CSI驱动对应的ServiceAccount上
3. 如果驱动有部分命名空间内的操作需求，可以额外补充命名空间级的Role和RoleBinding，但不能替代ClusterRole的作用。

注意：不要为了减少权限随意删减ClusterRole中的规则，需要严格按照你使用的CSI sidecar官方给出的权限列表配置，避免出现驱动无权限处理存储请求的问题。

内容的提问来源于stack exchange，提问作者Anto74