使用服务主体为持久卷预配静态 Azure 文件答案

【问题标题】：Use Service Principal to provision static Azure Files for Persistent Volume使用服务主体为持久卷预配静态 Azure 文件
【发布时间】：2021-06-15 14:30:19
【问题描述】：

之前我使用的是在静态 azure 文件上设置 PV 的标准方法，即创建存储帐户和文件共享，使用存储帐户的帐户名和密码创建密码，然后创建 PV，如下所示：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: elastic-storage
  labels:
    usage: elastic-storage
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  mountOptions:
    - dir_mode=0777
    - file_mode=0777
    - uid=1000
    - gid=1000
    - mfsymlinks
    - nobrl
  persistentVolumeReclaimPolicy: Retain
  azureFile:
    secretName: azure-secret
    shareName: elasticsearchfile2
    readOnly: false

我现在想知道是否可以使用服务主体而不是使用存储帐户名称和密钥的 azure 机密来访问 azure 文件。

【问题讨论】：

标签： azure persistent-volumes azure-files

【解决方案1】：

这很容易理解。 Azure 支持RBAC（基于角色的访问）功能。并且可以在存储帐户中使用。就像两个不同的用户可以读取数据库中的相同数据，因为他们有足够的读取权限。因此，如果服务主体对存储帐户有足够的权限，那么它也可以访问存储帐户。

【讨论】：

我了解我的服务主体理论上可以访问存储帐户。我更关心在我的 pv.yaml 文件中使用的实际代码，以使用服务主体访问 azure 文件。目前我必须使用由存储帐户名称和密钥创建的 azure secret。
@Saligia 你的意思是你不知道如何使用服务主体创建密钥？
我想找到一种替代方法来使用机密来验证和使用 azure 文件。所以我想看看我是否可以使用服务主体凭据来实现这一点。
@Saligia 看来您无法使用卷的服务主体创建密钥。您会看到 Azure 文件共享的选项只有 shareName 和 secretName，存储帐户没有选项。如果使用服务原则，则无法指向正确的存储帐户。 Kubernetes设计的，可以反馈，但目前不支持。
我明白了，谢谢。我一直在寻找使用服务主体而不是使用秘密的方法，因为使用秘密意味着可以访问整个存储帐户，但是如果我们使用服务主体，我们可以限制对部分存储帐户的访问，即其中的 azure 文件案子。我想那时还不支持它，这很奇怪，因为我可以使用 blob 存储而不是文件共享来做到这一点。