Есть ли реальное использование назначаемой пользователем управляемой идентификации, если все мои ресурсы находятся в одной подписке?

Я пытаюсь создать кластер HDInsight в определенной подписке. Теперь тип хранилища по умолчанию, который я выбираю, имеет тип ADLS Gen2, и экземпляр хранилища существует в той же подписке (пользовательский интерфейс здесь в любом случае будет перечислять только учетные записи хранения ADLS Gen2 в той же подписке). И затем, как вы можете видеть на снимке экрана ниже, пользовательский интерфейс также запрашивает идентификатор службы, назначенный пользователем, в качестве обязательного поля. Я не понимаю настоящей необходимости этой идентичности здесь. Поскольку кластер и ADLS Gen2 будут в одной подписке, кластер в любом случае сможет получить доступ к хранилищу - поскольку это происходит так, что во время развертывания кластера ключи хранилища выбираются динамически, поскольку они находятся в та же подписка. Вот так и подключается хранилище. Итак, если это все равно произойдет, зачем указывать управляемую идентификацию, назначаемую пользователем? Я также подтвердил, что возможность ввести управляемое удостоверение, назначенное пользователем, отображается только тогда, когда мы выбираем тип хранилища как ADLS Gen2, а не для ADLS Gen1 и хранилища Azure. ADLS Gen2 имеет BLOB-объекты, а также интерфейс каталогов. Но это всего лишь интерфейсы, под ним в любом случае хранилище BLOB-объектов, которое имеет ключи доступа. Фактически, ADLS Gen1 не имеет ничего похожего на ключи доступа, поскольку он предоставляет только интерфейс каталога, тем не менее нам не нужно указывать управляемую идентификацию, назначенную пользователем для это, поэтому мне интересно, почему для ADLS Gen2 он спрашивает, все ли ресурсы находятся в одной подписке.

введите здесь описание изображения


comment
Может быть, он не использует ключи доступа к хранилищу, а вместо этого использует управляемую идентификацию для аутентификации AAD в хранилище?   -  person juunas    schedule 25.10.2019
comment
вот в чем вопрос, почему это «обязательное» поле, если есть возможность разрешить ему использовать ключи доступа, почему он должен использовать только управляемую идентификацию?   -  person Dhiraj    schedule 25.10.2019
comment
Поскольку MI более безопасен: вы можете назначить ему ограниченные привилегии - ключ хранилища дает полный контроль, и утечка секретов менее вероятна.   -  person Marc    schedule 25.10.2019


Ответы (1)


Общая проблема: при создании облачных приложений заключается в том, как управлять учетными данными в коде для аутентификации в облачных службах. Обеспечение безопасности учетных данных - важная задача. В идеале учетные данные никогда не появляются на рабочих станциях разработчиков и не регистрируются в системе управления версиями. Azure Key Vault предоставляет способ безопасного хранения учетных данных, секретов и других ключей, но ваш код должен пройти аутентификацию в Key Vault, чтобы получить их.

Функция управляемых удостоверений для ресурсов Azure в Azure Active Directory (Azure AD) решает эту проблему. Эта функция предоставляет службам Azure автоматически управляемую идентификацию в Azure AD. Вы можете использовать удостоверение для аутентификации в любой службе, поддерживающей аутентификацию Azure AD, включая Key Vault, без каких-либо учетных данных в вашем коде.

Управляемое удостоверение - это удостоверение, зарегистрированное в Azure Active Directory (Azure AD), учетными данными которого управляет Azure. Благодаря управляемым удостоверениям вам не нужно регистрировать субъектов-служб в Azure AD или поддерживать учетные данные, такие как сертификаты.

Управляемые удостоверения можно использовать в Azure HDInsight, чтобы разрешить вашим кластерам доступ к службам домена Azure AD, доступ к хранилищу ключей Azure или доступ к файлам в Azure Data Lake Storage 2-го поколения.

Назначенное пользователем управляемое удостоверение создается как автономный ресурс Azure. В процессе создания Azure создает удостоверение в клиенте Azure AD, которому доверяет используемая подписка. После создания удостоверения удостоверение можно назначить одному или нескольким экземплярам службы Azure. Жизненный цикл назначенного пользователем удостоверения управляется отдельно от жизненного цикла экземпляров службы Azure, которым он назначен.

Ссылка: Управляемые удостоверения в Azure HDInsight

Надеюсь это поможет.

person CHEEKATLAPRADEEP-MSFT    schedule 30.10.2019