简要说明：我必须将一个项目从当前使用ECS的AWS迁移到Azure，因为不赞成使用其ACS（等效于ECS），因此将在其中使用AKS。
这是一个常规的Django应用，其配置变量是从托管在私有S3存储桶上的server-config.json获取的，EC2实例在S3FullAccess下具有正确的作用，
我一直在尝试重现相同的行为，但是使用Azure Blob Storage来重现，但没有成功：-（。
我尝试使用Service Principal概念并将其添加到具有AKS Cluster角色的Storage Blob Data Owner中，但这似乎不起作用。总体而言，这真是令人沮丧的经历-也许我只是很难掌握使用权限/范围的正确方法。 AKS Cluster创建自己的资源组这一事实令人难以理解-但我也尝试将策略附加到它，但无济于事。然后，我转到Microsoft指示的解决方案。
我设法通过其指示的解决方案aad-pod-identity将我的AKS吊舱与正确的User Managed Identity绑定在一起，但是我感觉好像缺少了一些东西。我为身份分配了Storage Blob Data Owner/Contributor，但是当我进入吊舱并尝试访问Blob（使用python sdk）时，仍然收到resource not found消息。
我到底想实现什么？还是我必须使用Azure Keyvault /类似的东西来更改解决方案？
答案 0 :(得分：1)
首先，您可以使用AKS Engine，它现在或多或少是Kubernetes的ACS。
关于对Blob存储的访问，您不必使用托管服务标识，您可以只使用帐户名\密钥（安全性稍差一些，但出错的可能性小得多，并且存在更多示例）。根据{{3}}存储blob贡献者的说法，如果您分配了适当的权限，那么您可能会遇到resource not found错误的事实很可能意味着您的auth部分很好，您只是无法访问该资源。范围。要使此功能100％起作用，只需在订阅级别授予您的身份提供者访问权限，这样就可以保证正常工作。
我找到了一个在MSI（this）中使用python的示例。您应该从此开始（并授予您的身份提供者访问权限）并确认您可以列出资源组。在什么情况下，使读取Blob起作用应该是微不足道的。