Beheerde identiteiten voor Azure gebruiken met Service Fabric
Een veelvoorkomende uitdaging bij het bouwen van cloudtoepassingen is het veilig beheren van de referenties in uw code voor verificatie bij verschillende services zonder ze lokaal op te slaan op een ontwikkelaarswerkstation of in broncodebeheer. Beheerde identiteiten voor Azure lossen dit probleem op voor al uw resources in Microsoft Entra ID door ze automatisch beheerde identiteiten in Microsoft Entra-id te bieden. U kunt de identiteit van een service gebruiken om te verifiëren bij elke service die ondersteuning biedt voor Microsoft Entra-verificatie, inclusief Key Vault, zonder referenties die zijn opgeslagen in uw code.
Beheerde identiteiten voor Azure-resources zijn gratis met Microsoft Entra ID voor Azure-abonnementen. Er zijn geen extra kosten.
Notitie
Beheerde identiteiten voor Azure is de nieuwe naam voor de service die voorheen Managed Service Identity (MSI) wordt genoemd.
Concepten
Beheerde identiteiten voor Azure zijn gebaseerd op verschillende belangrijke concepten:
Client-id : een unieke id die is gegenereerd door Microsoft Entra-id die is gekoppeld aan een toepassing en service-principal tijdens de eerste inrichting (zie ook de toepassings-id (client).)
Principal-id: de object-id van het service-principal-object van uw beheerde identiteit. Deze wordt gebruikt om op basis van rollen toegang te verlenen tot een Azure-resource.
Service-principal : een Microsoft Entra-object, dat de projectie van een Microsoft Entra-toepassing in een bepaalde tenant vertegenwoordigt (zie ook de service-principal.)
Er zijn twee typen beheerde identiteit:
- Een door het systeem toegewezen beheerde identiteit wordt rechtstreeks ingeschakeld op een Azure-service-exemplaar. De levenscyclus van een door het systeem toegewezen identiteit is uniek voor het Azure-service-exemplaar waarop deze is ingeschakeld.
- Een door de gebruiker toegewezen beheerde identiteit wordt gemaakt als een zelfstandige Azure-resource. De identiteit kan worden toegewezen aan een of meer Azure-service-exemplaren en wordt afzonderlijk beheerd van de levenscyclus van deze exemplaren.
Zie Hoe werken beheerde identiteiten voor Azure-resources voor meer informatie over het verschil tussen beheerde identiteitstypen.
Ondersteunde scenario's voor Service Fabric-toepassingen
Beheerde identiteiten voor Service Fabric worden alleen ondersteund in Azure geïmplementeerde Service Fabric-clusters en alleen voor toepassingen die zijn geïmplementeerd als Azure-resources. Een toepassing die niet is geïmplementeerd als een Azure-resource, kan geen identiteit worden toegewezen. Conceptueel gezien bestaat ondersteuning voor beheerde identiteiten in een Azure Service Fabric-cluster uit twee fasen:
Wijs een of meer beheerde identiteiten toe aan de toepassingsresource; aan een toepassing kan één door het systeem toegewezen identiteit en/of maximaal 32 door de gebruiker toegewezen identiteiten worden toegewezen.
Wijs in de definitie van de toepassing een van de identiteiten toe die aan de toepassing zijn toegewezen aan elke afzonderlijke service die de toepassing omvat.
De door het systeem toegewezen identiteit van een toepassing is uniek voor die toepassing; een door de gebruiker toegewezen identiteit is een zelfstandige resource, die kan worden toegewezen aan meerdere toepassingen. Binnen een toepassing kan één identiteit (of door het systeem toegewezen of door de gebruiker toegewezen) worden toegewezen aan meerdere services van de toepassing, maar elke afzonderlijke service kan slechts één identiteit worden toegewezen. Ten slotte moet aan een service expliciet een identiteit worden toegewezen om toegang te hebben tot deze functie. De toewijzing van de identiteiten van een toepassing aan de samenstellende services maakt isolatie van toepassingen mogelijk. Een service mag alleen de identiteit gebruiken die eraan is toegewezen.
De volgende scenario's worden ondersteund voor deze functie:
Een nieuwe toepassing implementeren met een of meer services en een of meer toegewezen identiteiten
Een of meer beheerde identiteiten toewijzen aan een bestaande (door Azure geïmplementeerde) toepassing om toegang te krijgen tot Azure-resources
De volgende scenario's worden niet ondersteund of niet aanbevolen. Deze acties worden mogelijk niet geblokkeerd, maar kunnen leiden tot storingen in uw toepassingen:
De identiteiten verwijderen of wijzigen die zijn toegewezen aan een toepassing. Als u wijzigingen wilt aanbrengen, dient u afzonderlijke implementaties in om eerst een nieuwe identiteitstoewijzing toe te voegen en vervolgens een eerder toegewezen identiteit te verwijderen. Het verwijderen van een identiteit uit een bestaande toepassing kan ongewenste gevolgen hebben, waaronder het verlaten van uw toepassing in een niet-upgradebare status. Het is veilig om de toepassing helemaal te verwijderen als het verwijderen van een identiteit nodig is. Als u de toepassing verwijdert, worden alle door het systeem toegewezen identiteit verwijderd die aan de toepassing is gekoppeld en worden alle koppelingen verwijderd met door de gebruiker toegewezen identiteiten die aan de toepassing zijn toegewezen.
Service Fabric biedt geen ondersteuning voor beheerde identiteiten in de afgeschafte AzureServiceTokenProvider. Gebruik in plaats daarvan beheerde identiteiten in Service Fabric met behulp van de Azure Identity SDK
Volgende stappen
- Een nieuw Azure Service Fabric-cluster implementeren met ondersteuning voor beheerde identiteiten
- Ondersteuning voor beheerde identiteiten inschakelen in een bestaand Azure Service Fabric-cluster
- Een Azure Service Fabric-toepassing implementeren met een door het systeem toegewezen beheerde identiteit
- Een Azure Service Fabric-toepassing implementeren met een door de gebruiker toegewezen beheerde identiteit
- De beheerde identiteit van een Service Fabric-toepassing gebruiken vanuit servicecode
- Een Azure Service Fabric-toepassing toegang verlenen tot andere Azure-resources
- Toepassingsgeheimen declareren en gebruiken als KeyVaultReferences