【问题标题】:Is there any real use of user-assigned managed identity if all my resources are in the same subscription?如果我的所有资源都在同一个订阅中,是否真正使用用户分配的托管标识?
【发布时间】:2020-02-21 15:56:39
【问题描述】:

我正在尝试在某个订阅中创建 HDInsight 群集。现在,我选择的默认存储类型是 ADLS Gen2 类型,并且存储实例存在于同一订阅中(此处的 UI 无论如何都会仅列出同一订阅中的 ADLS Gen2 存储帐户)。然后正如您在下面的屏幕截图中看到的那样,UI 还要求将用户分配的服务身份作为必填字段。我不明白这里这个身份的真正需要。由于集群和 ADLS Gen2 将在同一个订阅中,因此集群无论如何都能够访问存储——因为,它发生的方式是在集群部署期间动态获取存储密钥,因为它们在相同的订阅。这就是存储连接的方式。因此,如果无论如何都发生这种情况,那么指定用户分配的托管标识有什么需要呢?我还验证了输入用户分配的托管标识的选项仅在我们选择存储类型为 ADLS Gen2 而不是 ADLS Gen1 和 Azure 存储时显示。 ADLS Gen2 具有 blob 和目录接口。但这些只是接口,在它下面无论如何都是一个具有访问密钥的 blob 存储。事实上 ADLS Gen1 没有任何类似访问密钥的东西,因为它只提供目录接口,我们仍然不需要为用户指定用户分配的托管标识那,所以我想知道为什么 ADLS Gen2 会询问是否所有资源都在同一个订阅中。

【问题讨论】:

  • 也许它不使用存储访问密钥,而是使用托管标识对存储进行 AAD 身份验证?
  • 这就是问题所在,如果可以选择让它使用访问密钥,为什么它是一个“必填”字段,为什么它必须只使用托管标识?
  • 因为 MI 更安全:您可以为其分配受限权限 - 存储密钥提供完全控制权,并且不太可能泄露秘密。

标签: azure-active-directory azure-data-lake azure-hdinsight azure-managed-identity azure-data-lake-gen2


【解决方案1】:

常见挑战:在构建云应用程序时,如何管理代码中的凭据以对云服务进行身份验证。保持凭据安全是一项重要任务。理想情况下,凭据永远不会出现在开发人员工作站上,也不会检查到源代码控制中。 Azure Key Vault 提供了一种安全存储凭据、机密和其他密钥的方法,但您的代码必须对 Key Vault 进行身份验证才能检索它们。

Azure Active Directory (Azure AD) 中的 Azure 资源托管标识功能解决了这个问题。该功能在 Azure AD 中为 Azure 服务提供了一个自动管理的标识。您可以使用该标识向任何支持 Azure AD 身份验证的服务(包括 Key Vault)进行身份验证,而无需在您的代码中添加任何凭据。

托管标识是在 Azure Active Directory (Azure AD) 中注册的标识,其凭据由 Azure 管理。使用托管标识,您无需在 Azure AD 中注册服务主体或维护证书等凭据。

可在 Azure HDInsight 中使用托管标识,以允许您的集群访问 Azure AD 域服务、访问 Azure Key Vault 或访问 Azure Data Lake Storage Gen2 中的文件。

用户分配的托管标识创建为独立的 Azure 资源。通过创建过程,Azure 在 Azure AD 租户中创建一个受正在使用的订阅信任的身份。创建标识后,可以将标识分配给一个或多个 Azure 服务实例。用户分配标识的生命周期与其分配到的 Azure 服务实例的生命周期分开管理。

参考:Managed identities in Azure HDInsight

希望这会有所帮助。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-12-13
    • 1970-01-01
    • 2020-11-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-05-20
    • 1970-01-01
    相关资源
    最近更新 更多