Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Tożsamość zarządzana to tożsamość zarejestrowana w usłudze Microsoft Entra, której poświadczenia są zarządzane przez platformę Azure. W przypadku tożsamości zarządzanych nie musisz rejestrować jednostek usługi w identyfikatorze Entra firmy Microsoft. Możesz też zachować poświadczenia, takie jak certyfikaty.
Tożsamości zarządzane są używane w usłudze Azure HDInsight do uzyskiwania dostępu do usług Microsoft Entra Domain Services lub uzyskiwania dostępu do plików w usłudze Azure Data Lake Storage Gen2 w razie potrzeby.
Istnieją dwa typy tożsamości zarządzanych: przypisane przez użytkownika i przypisane przez system. Usługa Azure HDInsight obsługuje tylko tożsamości zarządzane przypisane przez użytkownika. Usługa HDInsight nie obsługuje tożsamości zarządzanych przypisanych przez system. Tożsamość zarządzana przypisana przez użytkownika jest tworzona jako samodzielny zasób Azure, który można następnie przypisać do jednej lub więcej instancji usługi Azure. Z kolei tożsamość zarządzana przypisana przez system jest tworzona w Microsoft Entra ID, a następnie automatycznie włączana bezpośrednio w określonym wystąpieniu usługi Azure. Żywotność tej tożsamości zarządzanej przypisanej przez system jest następnie powiązana z czasem działania instancji usługi, na której jest włączona.
Implementacja zarządzanej tożsamości w usłudze HDInsight
W usłudze Azure HDInsight tożsamości zarządzane mogą być używane tylko przez usługę HDInsight dla składników wewnętrznych. Obecnie nie ma obsługiwanej metody generowania tokenów dostępu przy użyciu tożsamości zarządzanych zainstalowanych w węzłach klastra usługi HDInsight na potrzeby uzyskiwania dostępu do usług zewnętrznych. W przypadku niektórych usług platformy Azure, takich jak maszyny wirtualne obliczeniowe, tożsamości zarządzane są implementowane za pomocą punktu końcowego, którego można użyć do uzyskiwania tokenów dostępu. Ten punkt końcowy nie jest obecnie dostępny w węzłach usługi HDInsight.
Jeśli musisz uruchomić aplikacje, aby uniknąć umieszczania wpisów tajnych/haseł w zadaniach analizy (np. zadań SCALA), możesz dystrybuować własne certyfikaty do węzłów klastra przy użyciu akcji skryptu, a następnie użyć tego certyfikatu do uzyskania tokenu dostępu (na przykład w celu uzyskania dostępu do usługi Azure KeyVault).
Tworzenie tożsamości zarządzanej
Tożsamości zarządzane można utworzyć przy użyciu dowolnej z następujących metod:
Pozostałe kroki konfigurowania tożsamości zarządzanej zależą od scenariusza, w którym zostanie on użyty.
Scenariusze tożsamości zarządzanej w usłudze Azure HDInsight
Tożsamości zarządzane są używane w Azure HDInsight w wielu scenariuszach. Zapoznaj się z powiązanymi dokumentami, aby uzyskać szczegółowe instrukcje dotyczące konfiguracji:
- Azure Data Lake Storage Gen2
- Pakiet Enterprise Security
- Szyfrowanie dysku klucza zarządzanego przez klienta
Usługa HDInsight automatycznie odnowi certyfikaty dla tożsamości zarządzanych używanych w tych scenariuszach. Istnieje jednak ograniczenie, gdy w przypadku długotrwałych klastrów jest używanych wiele różnych tożsamości zarządzanych, odnawianie certyfikatu może nie działać zgodnie z oczekiwaniami dla wszystkich tożsamości zarządzanych. Ze względu na to ograniczenie zalecamy użycie tej samej tożsamości zarządzanej we wszystkich powyższych scenariuszach.
Jeśli utworzono już długotrwały klaster z wieloma różnymi tożsamościami zarządzanymi i występuje jeden z następujących problemów:
- W klastrach ESP, usługi klastra zaczynają zawodzić, a operacje skalowania w górę oraz inne operacje kończą się niepowodzeniem z powodu błędów uwierzytelniania.
- W klastrach ESP, podczas zmieniania certyfikatu LDAPS dla usług Microsoft Entra Domain Services, certyfikat LDAPS nie jest automatycznie aktualizowany, a w związku z tym synchronizacja LDAP i skalowanie w górę zaczynają zawodzić.
- Dostęp MSI do usługi ADLS Gen2 kończy się niepowodzeniem.
- Klucze szyfrowania nie mogą być obracane w scenariuszu cmK.
następnie należy przypisać wymagane role i uprawnienia dla powyższych scenariuszy do wszystkich tożsamości zarządzanych używanych w klastrze. Jeśli na przykład użyto różnych tożsamości zarządzanych dla ADLS Gen2 i klastrów ESP, obie te tożsamości powinny mieć przypisane role "Właściciel danych obiektu blob usługi Storage" i "Współautor usług domenowych HDInsight", aby uniknąć tych problemów.
Często zadawane pytania
Co się stanie w przypadku usunięcia tożsamości zarządzanej po utworzeniu klastra?
Klaster napotka problemy, gdy potrzebna jest tożsamość zarządzana. Obecnie nie ma możliwości aktualizowania ani zmieniania tożsamości zarządzanej po utworzeniu klastra. Dlatego naszym zaleceniem jest upewnienie się, że tożsamość zarządzana nie została usunięta w czasie wykonywania klastra. Możesz też ponownie utworzyć klaster i przypisać nową tożsamość zarządzaną.