Tożsamości zarządzane w usłudze Azure HDInsight
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 autonomiczny zasób platformy Azure, który można następnie przypisać do co najmniej jednego wystąpienia usługi platformy Azure. Z kolei tożsamość zarządzana przypisana przez system jest tworzona w usłudze Microsoft Entra ID, a następnie włączana bezpośrednio w określonym wystąpieniu usługi platformy Azure automatycznie. Żywotność tej tożsamości zarządzanej przypisanej przez system jest następnie powiązana z życiem wystąpienia usługi, na którym jest włączona.
Implementacja tożsamości zarządzanej usługi 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 usłudze 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 rozpoczynają się niepowodzeniem lub skaluje w górę, a inne operacje kończą się niepowodzeniem z powodu błędów uwierzytelniania.
- W klastrach ESP podczas zmieniania certyfikatu LDAPS usług Microsoft Entra Domain Services certyfikat LDAPS nie jest automatycznie aktualizowany, a w związku z tym synchronizacja LDAP i skalowanie wzloty kończą się niepowodzeniem.
- 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 klastrów ADLS Gen2 i ESP, oba te klastry powinny mieć przypisane role "Właściciel danych obiektu blob usługi Storage" i "Współautor usług domenowych HDInsight", aby uniknąć uruchamiania w tych problemach.
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ą.