如何管理 Kubernetes pod 的凭据以通过 CSI 存储驱动程序访问资源？
CSI 存储驱动程序为容器提供卷安装，由某种性质的存储支持。 OIDC 通过临时令牌提供联合身份验证，并且是用于管理进程对资源的访问的安全最佳实践（与手动轮换密钥相比）。在 Kubernetes 中，OIDC 通过应用于 pod 的服务帐户启用（为不同的 pod 组启用细化权限，即不同的工作负载）。
根据最小特权原则，人们通常希望严格限制对单个资源的所有访问，但需要它的特定工作负载除外。通常，这是通过将资源配置为仅授权与特定工作负载/pod 关联的服务帐户身份来实现的。当容器进程使用支持 OIDC 的 SDK 直接访问资源时（因为这样的 SDK 将透明地检索 kubernetes 提供给 pod 的服务帐户令牌，并使用它来建立和更新对资源的身份验证），这会非常顺利地工作。即使主容器不直接支持资源类型，通过添加 FUSE（用户空间驱动程序中的文件系统）side-car 容器，这种模型仍然是可能的。
将存储驱动程序重新实现为 CSI 而不是 pod side-car 应该会大大简化不同资源的配置，但是乍一看，CSI 驱动程序的一部分似乎位于单独的 pod/daemonset 中（建议使用单独的服务帐户个人工作量）。这意味着用户应该配置所有资源以允许对驱动程序的服务帐户进行全面访问，并且不能将权限范围限定到特定的单个 pod/工作负载。特别是，如果权限仅限于驱动程序级别，这将消除单个共享资源管理授予对不同客户端工作负载的不同级别的粒度访问权限的能力（例如：日志分析器不需要写权限，并且日志写入者不需要读取权限 - 每个写入者只能写入特定于应用程序的子路径）。 CSI 驱动程序是否能够承担其提供挂载的 pod 的服务角色？这是默认配置/模式还是需要额外代码？ （我想 CSI 驱动程序可能有机会从客户端 pod 中获取令牌；这会被认为是非标准行为吗？）否则，在使用 CSI 驱动程序时如何管理细粒度权限？