Beheerde identiteiten in Azure HDInsight
Een beheerde identiteit is een identiteit die is geregistreerd in Microsoft Entra waarvan de referenties worden beheerd door Azure. Met beheerde identiteiten hoeft u geen service-principals te registreren in Microsoft Entra-id. U kunt ook referenties zoals certificaten onderhouden.
Beheerde identiteiten worden in Azure HDInsight gebruikt voor toegang tot Microsoft Entra Domain Services of toegang tot bestanden in Azure Data Lake Storage Gen2 wanneer dat nodig is.
Er zijn twee typen beheerde identiteiten: door de gebruiker toegewezen en door het systeem toegewezen. Azure HDInsight ondersteunt alleen door de gebruiker toegewezen beheerde identiteiten. HDInsight biedt geen ondersteuning voor door het systeem toegewezen beheerde identiteiten. Een door de gebruiker toegewezen beheerde identiteit wordt gemaakt als een zelfstandige Azure-resource, die u vervolgens kunt toewijzen aan een of meer Azure-service-exemplaren. Een door het systeem toegewezen beheerde identiteit wordt daarentegen gemaakt in Microsoft Entra-id en vervolgens automatisch ingeschakeld op een bepaald Azure-service-exemplaar. De levensduur van die door het systeem toegewezen beheerde identiteit is vervolgens gekoppeld aan de levensduur van het service-exemplaar waarop deze is ingeschakeld.
Implementatie van beheerde identiteit in HDInsight
In Azure HDInsight kunnen beheerde identiteiten alleen worden gebruikt door de HDInsight-service voor interne onderdelen. Er is momenteel geen ondersteunde methode voor het genereren van toegangstokens met behulp van de beheerde identiteiten die zijn geïnstalleerd op HDInsight-clusterknooppunten voor toegang tot externe services. Voor sommige Azure-services, zoals reken-VM's, worden beheerde identiteiten geïmplementeerd met een eindpunt dat u kunt gebruiken om toegangstokens te verkrijgen. Dit eindpunt is momenteel niet beschikbaar in HDInsight-knooppunten.
Als u uw toepassingen moet opstarten om te voorkomen dat geheimen/wachtwoorden in de analysetaken worden geplaatst (bijvoorbeeld SCALA-taken), kunt u uw eigen certificaten distribueren naar de clusterknooppunten met behulp van scriptacties en dat certificaat vervolgens gebruiken om een toegangstoken te verkrijgen (bijvoorbeeld voor toegang tot Azure KeyVault).
Een beheerde identiteit maken
Beheerde identiteiten kunnen worden gemaakt met een van de volgende methoden:
De resterende stappen voor het configureren van de beheerde identiteit zijn afhankelijk van het scenario waarin deze wordt gebruikt.
Scenario's voor beheerde identiteiten in Azure HDInsight
Beheerde identiteiten worden in Azure HDInsight gebruikt in meerdere scenario's. Zie de gerelateerde documenten voor gedetailleerde installatie- en configuratie-instructies:
- Azure Data Lake Storage Gen2
- Enterprise Security Package
- Schijfversleuteling met behulp van door klant beheerde sleutel
HDInsight vernieuwt automatisch de certificaten voor de beheerde identiteiten die u voor deze scenario's gebruikt. Er is echter een beperking wanneer meerdere verschillende beheerde identiteiten worden gebruikt voor langlopende clusters, werkt de certificaatvernieuwing mogelijk niet zoals verwacht voor alle beheerde identiteiten. Vanwege deze beperking raden we u aan dezelfde beheerde identiteit te gebruiken voor alle bovenstaande scenario's.
Als u al een langlopend cluster met meerdere verschillende beheerde identiteiten hebt gemaakt en een van deze problemen ondervindt:
- In ESP-clusters beginnen clusterservices te mislukken of op te schalen en andere bewerkingen mislukken met verificatiefouten.
- Wanneer u in ESP-clusters het LDAPS-certificaat van Microsoft Entra Domain Services wijzigt, wordt het LDAPS-certificaat niet automatisch bijgewerkt, waardoor LDAP-synchronisatie en schaalaanpassingen mislukken.
- MSI-toegang tot ADLS Gen2 mislukt.
- Versleutelingssleutels kunnen niet worden gedraaid in het CMK-scenario.
vervolgens moet u de vereiste rollen en machtigingen voor de bovenstaande scenario's toewijzen aan al deze beheerde identiteiten die in het cluster worden gebruikt. Als u bijvoorbeeld verschillende beheerde identiteiten hebt gebruikt voor ADLS Gen2- en ESP-clusters, moeten beide de rollen Eigenaar van opslagblobgegevens en HDInsight Domain Services-inzender hebben toegewezen om te voorkomen dat ze in deze problemen worden uitgevoerd.
Veelgestelde vragen
Wat gebeurt er als ik de beheerde identiteit verwijder nadat het cluster is gemaakt?
Uw cluster ondervindt problemen wanneer de beheerde identiteit nodig is. Er is momenteel geen manier om een beheerde identiteit bij te werken of te wijzigen nadat het cluster is gemaakt. Daarom is het raadzaam ervoor te zorgen dat de beheerde identiteit niet wordt verwijderd tijdens de clusterruntime. U kunt het cluster ook opnieuw maken en een nieuwe beheerde identiteit toewijzen.