Kubernetes 1.20:CSI驱动程序中的Pod模拟和短命卷

作者:张世航(Google)

通常在 CSI 驱动程序安装诸如机密和证书之类的凭据,它必须针对存储提供程序进行身份验证才能访问凭据。但是,对这些凭据的访问是根据容器的身份而不是CSI驱动程序的身份来控制的。因此,CSI驱动程序需要某种方式来检索Pod的服务帐户令牌。

当前,有两种不理想的方法来实现此目的,或者是通过授予CSI驱动程序使用TokenRequest API的权限,或者是直接从主机文件系统中读取令牌。

它们都具有以下缺点:

  • 违反最小特权原则
  • 每个CSI驱动程序都需要重新实现获取Pod的服务帐户令牌的逻辑

第二种方法存在更多问题,原因是:

  • 令牌的受众默认为kube-apiserver
  • The token is not guaranteed to be available (e.g. AutomountServiceAccountToken=false)
  • 该方法不适用于以与Pod不同的(非root用户)用户身份运行的CSI驱动程序。看到 服务帐户令牌的文件许可部分
  • 该令牌可能是传统的Kubernetes服务帐户令牌,如果该令牌不会过期, BoundServiceAccountTokenVolume=false

Kubernetes 1.20 introduces an alpha feature, CSIServiceAccountToken, to improve the security posture. The new feature allows CSI drivers to receive pods' 绑定服务帐户令牌.

此功能还提供了一个重新发布卷的旋钮,以便可以刷新短命的卷。

吊舱模仿

使用GCP API

使用 工作量身份,Kubernetes服务帐户可以在访问Google Cloud API时作为Google服务帐户进行身份验证。如果CSI驱动程序需要代表要为其安装卷的Pod访问GCP API,则可以使用Pod的服务帐户令牌来 交换GCP代币. The pod's service account token is plumbed through the volume context in NodePublishVolume RPC calls when the feature CSIServiceAccountToken is enabled. For example: accessing Google秘密管理员 通过一个 机密存储CSI驱动程序.

使用保管箱

如果用户配置 Kubernetes作为身份验证方法, Vault uses the TokenReview API to validate the Kubernetes service account token. For CSI drivers using Vault as resources provider, they need to present the pod's service account to Vault. For example, 机密存储CSI驱动程序证书管理器CSI驱动程序.

短命卷

To keep short-lived volumes such as certificates effective, CSI drivers can specify RequiresRepublish=true in theirCSIDriver object to have the kubelet periodically call NodePublishVolume on mounted volumes. These republishes allow CSI drivers to ensure that the volume content is up-to-date.

下一步

此功能是Alpha版,预计将在1.21版中移至Beta版。请参阅以下KEP和CSI文档中的更多内容:

我们欢迎您的反馈!