【问题标题】:Update key vault's assiciated Azure AD tenant after subscriptin move without having to do a synchronized deployment of all dependent apps订阅移动后更新与 Azure AD 租户关联的密钥保管库,而无需同步部署所有相关应用
【发布时间】:2020-05-09 10:01:53
【问题描述】:

我正在将订阅从 Azure AD 的一个租户转移到另一个租户。我已查看并遵循this doc 中概述的流程。一切顺利。下一步是根据 this doc 更改已移动订阅的密钥保管库租户 ID。这就是我想不出一种方法来做到这一点,即不涉及更改和部署依赖于 Key Vault 的多个应用程序以及移动。理想情况下,我想将第二个租户(新租户)与密钥保管库相关联,在新租户中注册应用程序并让这些应用程序根据自己的发布周期更新配置,并且一旦所有应用程序都更新为使用新的 ClientID /Secret 在新的 Azure AD 租户中生成,我将删除旧的租户关联。但是,密钥保管库在任何给定时间只能与一个租户关联。可以使用什么策略来实现这种平稳过渡,而无需一次性同步部署所有相关应用程序?似乎唯一的解决方案是创建一个与新 AD 租户关联的新密钥库,注册应用程序并发布新的 ClientID/Secret 并让它们按照自己的部署计划上线。最终可以删除旧的密钥保管库。这似乎是一个相当麻烦的方法。有没有其他办法?

更复杂的是,存储帐户密钥配置为managed by key vault,所有应用程序都使用key vault to get access to storage,而不是直接使用存储帐户密钥。在这里,存储帐​​户也只能由单个密钥保管库链接和管理。

只有一个 Key Vault 对象应该管理存储帐户密钥。 不允许来自多个对象的密钥管理。

这意味着即使是创建新的密钥保管库并迁移所有应用程序以使用它们的方法也行不通,除非对存储密钥保管库链接的更新与使用此类存储的所有应用程序同步并部署。其中一些应用由不同时区的不同团队管理,因此同步部署相当困难,而且如果要回滚任何应用部署,它要么失去对存储帐户的访问权限,要么所有应用都必须回滚。

虽然订阅移动到不同的 Azure AD 租户的情况可能并不常见,但我确信它已经完成,这就是为什么我想获得一些指导来了解如何做到这一点而不必这样做所有依赖于密钥保管库的应用程序的同步部署。

更新 1

事实证明,在移动订阅后,密钥保管库访问处于非常混乱的状态。旧租户的用户甚至看不到密钥保管库,因为没有订阅,只要密钥保管库的租户仍然是旧的,新租户的用户就无法做任何事情(看不到密钥、机密、证书或更新访问策略) .如果密钥库更新到新租户,用户仍然看不到现有的密钥、机密和证书。他们确实可以访问以更新访问策略,但现有的密钥、机密和证书甚至无法从门户中查看。 Powershell 可以列出/查看这些但不能更新任何值!所以那里也有差异。 Key Vault 团队的某个人能否确认这些,或者租户移动中应该有一个大的红色警告,它会使对任何现有密钥、秘密和证书的访问无效。

【问题讨论】:

    标签: azure azure-active-directory azure-storage azure-keyvault


    【解决方案1】:

    让 KeyVault 移动租户会保留旧的租户值,这样现有的访问策略就不会失败。但是,当租户值更新为新租户时,旧的访问策略将失效,因为新租户中不存在身份,必须使用新身份重新创建。这是设计使然。虽然不是官方文档,但我前段时间在博客上写过:

    https://azidentity.azurewebsites.net/post/2018/05/16/azure-key-vault-known-portal-issues-the-directory-currently-selected-differs-from-this-key-vault-s-directory

    【讨论】:

    • 谢谢马特。症状和原因很清楚,但知道这是设计使然,如何在不中断任何使用密钥库的应用程序的情况下移动租户。细节在问题中,但如果需要,我可以澄清更多。
    • 您无法避免中断。对于使用该 Key Vault 的应用程序,您必须在新租户中使用新 SP 重新创建每个访问策略。
    猜你喜欢
    • 2017-07-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-11-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多