.NET-alkalmazások hitelesítése Azure-szolgáltatásokba a .NET Azure SDK használatával
Ha egy alkalmazásnak hozzá kell férnie egy Azure-erőforráshoz, például a tárolóhoz, a kulcstartóhoz vagy a kognitív szolgáltatásokhoz, az alkalmazást hitelesíteni kell az Azure-ban. Ez minden alkalmazásra igaz, legyen szó az Azure-ban üzembe helyezett, a helyszínen üzembe helyezett vagy a helyi fejlesztői munkaállomáson végzett fejlesztés alatt álló alkalmazásokról. Ez a cikk azokat a módszereket ismerteti, hogyan hitelesíthet egy alkalmazást az Azure-ban az Azure SDK for .NET használatakor.
Ajánlott alkalmazáshitelesítési módszer
Az Azure-erőforrásokhoz való hitelesítéskor ajánlott, hogy az alkalmazások jogkivonatalapú hitelesítést használjanak ahelyett, hogy kapcsolati sztring. A .NET-hez készült Azure SDK olyan osztályokat biztosít, amelyek támogatják a jogkivonatalapú hitelesítést, és lehetővé teszik az alkalmazások számára, hogy zökkenőmentesen hitelesítsék magukat az Azure-erőforrásokon, függetlenül attól, hogy az alkalmazás helyi fejlesztés alatt áll, üzembe van helyezve az Azure-ban vagy egy helyszíni kiszolgálón.
A jogkivonat-alapú hitelesítés adott típusa, amelyet az alkalmazásnak az Azure-erőforrásokon való hitelesítéshez kell használnia, attól függ, hogy hol fut az alkalmazás, és az alábbi ábrán látható.
- Ha egy fejlesztő helyi fejlesztés során futtat egy alkalmazást – Az alkalmazás hitelesítést végezhet az Azure-ban egy alkalmazásszolgáltatásnév használatával a helyi fejlesztéshez, vagy a fejlesztő Azure-beli hitelesítő adatainak használatával. Ezekről a lehetőségekről részletesebben a helyi fejlesztés során történő hitelesítés szakaszában olvashat.
- Ha egy alkalmazást az Azure-ban üzemeltetnek – Az alkalmazásnak felügyelt identitással kell hitelesítenie az Azure-erőforrásokat. Ezt a lehetőséget az alábbiakban a kiszolgálói környezetekben történő hitelesítés szakaszában ismertetjük részletesebben.
- Amikor egy alkalmazást üzemeltetnek és üzembe helyeznek a helyszínen , az alkalmazásnak hitelesítenie kell magát az Azure-erőforrásokban egy alkalmazásszolgáltatás-tag használatával. Ezt a lehetőséget az alábbiakban a kiszolgálói környezetekben történő hitelesítés szakaszában ismertetjük részletesebben.
DefaultAzureCredential
Az DefaultAzureCredential
Azure SDK által biztosított osztály lehetővé teszi, hogy az alkalmazások a futtatott környezettől függően különböző hitelesítési módszereket használjanak. Ez lehetővé teszi az alkalmazások előléptetését a helyi fejlesztéstől a környezetek tesztelése az éles környezetekig kódmódosítások nélkül. Konfigurálja a megfelelő hitelesítési módszert az egyes környezetekhez, és DefaultAzureCredential
automatikusan észleli és használja ezt a hitelesítési módszert. A feltételes logika vagy a funkciójelzők manuális kódolása DefaultAzureCredential
helyett előnyben kell részesíteni a különböző hitelesítési módszerek használatát különböző környezetekben.
Az osztály használatával DefaultAzureCredential
kapcsolatos részletekről a cikk későbbi részében, a Használat DefaultAzureCredential
egy alkalmazásban című szakaszban olvashat.
A jogkivonatalapú hitelesítés előnyei
Az Azure-hoz készült alkalmazások létrehozásakor erősen ajánlott a jogkivonatalapú hitelesítés kapcsolati sztring használata esetén. A jogkivonatalapú hitelesítés a következő előnyöket nyújtja a kapcsolati sztring hitelesítésével szemben.
- Az alábbiakban ismertetett jogkivonatalapú hitelesítési módszerek lehetővé teszik az alkalmazás által az Azure-erőforráson szükséges konkrét engedélyek létrehozását. Ez a minimális jogosultság elvét követi. Ezzel szemben egy kapcsolati sztring teljes jogokat biztosít az Azure-erőforrás számára.
- Míg bárki vagy bármely kapcsolati sztring rendelkező alkalmazás csatlakozhat egy Azure-erőforráshoz, a jogkivonatalapú hitelesítési módszerek csak az erőforrás eléréséhez használni kívánt alkalmazás(ok)hoz férhetnek hozzá az erőforráshoz.
- Felügyelt identitás esetén nincs tárolandó alkalmazáskulcs. Ez biztonságosabbá teszi az alkalmazást, mert nincs kapcsolati sztring vagy alkalmazás titkos kódja, mint ami feltörhető.
- Az Azure SDK Azure.Identity csomagja a színfalak mögött kezeli a jogkivonatokat. Ez megkönnyíti a jogkivonatalapú hitelesítés használatát kapcsolati sztring.
A kapcsolati sztring használatát a koncepcióalkalmazások vagy fejlesztési prototípusok kezdeti ellenőrzésére kell korlátozni, amelyek nem férnek hozzá éles vagy bizalmas adatokhoz. Ellenkező esetben az Azure SDK-ban elérhető jogkivonatalapú hitelesítési osztályokat mindig előnyben kell részesíteni az Azure-erőforrásokhoz való hitelesítéskor.
Hitelesítés kiszolgálói környezetekben
Kiszolgálói környezetben való üzemeltetéskor minden alkalmazáshoz egyedi alkalmazásidentitást kell hozzárendelni az alkalmazás által futtatott környezetenként. Az Azure-ban az alkalmazásidentitást egy szolgáltatásnév képviseli, amely egy speciális biztonsági egyszerű típus, amelynek célja az alkalmazások azonosítása és hitelesítése az Azure-ban. Az alkalmazáshoz használandó szolgáltatásnév típusa attól függ, hogy az alkalmazás hol fut.
Hitelesítési módszer | Leírás |
---|---|
Az Azure-ban üzemeltetett alkalmazások | Az Azure-ban üzemeltetett alkalmazásoknak felügyelt identitásszolgáltatásnevet kell használniuk. A felügyelt identitások az Azure-ban üzemeltetett alkalmazások identitását képviselik, és csak az Azure által üzemeltetett alkalmazásokkal használhatók. A Azure-alkalmazás Szolgáltatásban üzemeltetett .NET-webalkalmazáshoz például felügyelt identitás lesz hozzárendelve. Az alkalmazáshoz rendelt felügyelt identitás ezután az alkalmazás más Azure-szolgáltatásokban való hitelesítésére szolgál. |
Az Azure-on kívül üzemeltetett alkalmazások (például helyszíni alkalmazások) |
Az Azure-on kívül üzemeltetett alkalmazásoknak (például helyszíni alkalmazásoknak), amelyeknek csatlakozniuk kell az Azure-szolgáltatásokhoz, egy alkalmazásszolgáltatásnevet kell használniuk. Az application service principal az alkalmazás identitását jelöli az Azure-ban, és az alkalmazásregisztrációs folyamaton keresztül jön létre. Vegyük például az Azure Blob Storage-t használó helyszíni .NET-webalkalmazást. Az alkalmazásregisztrációs folyamattal létrehozna egy alkalmazásszolgáltatásnevet az alkalmazáshoz. A AZURE_CLIENT_ID , AZURE_TENANT_ID és AZURE_CLIENT_SECRET mind környezeti változókként lesz tárolva, amelyeket az alkalmazás futásidőben olvas be, és lehetővé teszi az alkalmazás számára az Azure-ban való hitelesítést az Application service principal használatával. |
Hitelesítés a helyi fejlesztés során
Ha egy alkalmazás egy fejlesztői munkaállomáson fut a helyi fejlesztés során, akkor is hitelesítenie kell az alkalmazás által használt Azure-szolgáltatásokban. Az alkalmazások Azure-ba történő hitelesítésének két fő stratégiája a helyi fejlesztés során:
Hitelesítési módszer | Leírás |
---|---|
A helyi fejlesztés során használandó dedikált alkalmazásszolgáltatás-egyszerű objektumok létrehozása | Ebben a módszerben a dedikált alkalmazásszolgáltatás-egyszerű objektumok az alkalmazásregisztrációs folyamat használatával vannak beállítva a helyi fejlesztés során való használatra. A szolgáltatásnév identitása ezután környezeti változókként lesz tárolva, amelyeket az alkalmazás a helyi fejlesztésben való futtatáskor érhet el. Ez a módszer lehetővé teszi az alkalmazás által igényelt erőforrás-engedélyek hozzárendelését a fejlesztők által a helyi fejlesztés során használt egyszerű szolgáltatásobjektumokhoz. Ez biztosítja, hogy az alkalmazás csak azokhoz az erőforrásokhoz férhessen hozzá, amelyekre szüksége van, és replikálja azokat az engedélyeket, amelyeket az alkalmazás éles környezetben fog biztosítani. Ennek a megközelítésnek a hátránya, hogy külön szolgáltatásnév-objektumokat kell létrehozni minden olyan fejlesztő számára, aki egy alkalmazáson dolgozik. |
Az alkalmazás hitelesítése az Azure-ba a fejlesztő hitelesítő adataival a helyi fejlesztés során | Ebben a módszerben a fejlesztőknek be kell jelentkezniük az Azure-ba a Visual Studióból, a VS Code Azure Tools-bővítményéből, az Azure CLI-ből vagy az Azure PowerShellből a helyi munkaállomásukon. Az alkalmazás ezután hozzáférhet a fejlesztői hitelesítő adatokhoz a hitelesítőadat-tárolóból, és ezekkel a hitelesítő adatokkal elérheti az Azure-erőforrásokat az alkalmazásból. Ez a módszer a könnyebb beállítás előnye, mivel egy fejlesztőnek csak a Visual Studióból, a VS Code-ból vagy az Azure CLI-ből kell bejelentkeznie az Azure-fiókjába. Ennek a módszernek a hátránya, hogy a fejlesztő fiókja valószínűleg több engedéllyel rendelkezik, mint amennyit az alkalmazás igényel. Ezért ez a megközelítés nem replikálja pontosan azokat az engedélyeket, amellyel az alkalmazás éles környezetben fog futni. |
DefaultAzureCredential használata egy alkalmazásban
DefaultAzureCredential
több hitelesítési módszert támogat, és meghatározza a futtatókörnyezetben használt hitelesítési módszert. Ily módon az alkalmazás különböző hitelesítési módszereket használhat különböző környezetekben, környezetspecifikus kód implementálása nélkül.
A hitelesítő adatokat kereső sorrend és helyek DefaultAzureCredential
a DefaultAzureCredential helyen találhatók.
A megvalósításhoz DefaultAzureCredential
először adja hozzá a Azure.Identity
csomagokat, és igény szerint adja hozzá az Microsoft.Extensions.Azure
alkalmazáshoz. Ezt a parancssor vagy a NuGet Csomagkezelő használatával teheti meg.
Nyisson meg egy tetszőleges terminálkörnyezetet az alkalmazásprojekt könyvtárában, és írja be az alábbi parancsot.
dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure
Az Azure-szolgáltatásokat általában az SDK megfelelő ügyfélosztályai használják. Ezeket az osztályokat és a saját egyéni szolgáltatásokat regisztrálni kell a Program.cs
fájlban, hogy az alkalmazás függőséginjektálásával elérhetőek legyenek. Program.cs
Belül kövesse az alábbi lépéseket a szolgáltatás és a .DefaultAzureCredential
- Adja meg a névtereket és
Microsoft.Extensions.Azure
aAzure.Identity
névtereket egy felhasználói utasítással. - Regisztrálja az Azure-szolgáltatást a megfelelő segítő módszerek használatával.
- Adja át az objektum egy példányát
DefaultAzureCredential
aUseCredential
metódusnak.
Erre példa a következő kódszakaszban látható.
using Microsoft.Extensions.Azure;
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
x.UseCredential(new DefaultAzureCredential());
});
Azt is megteheti, hogy a szolgáltatásokban közvetlenül, további Azure-regisztrációs módszerek nélkül is használhatja DefaultAzureCredential
az alábbiakban látható módon.
using Azure.Identity;
// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x =>
new BlobServiceClient(
new Uri("https://<account-name>.blob.core.windows.net"),
new DefaultAzureCredential()));
Ha a fenti kód a helyi fejlesztés során fut a helyi munkaállomáson, az alkalmazás-szolgáltatásnév környezeti változóiban, illetve a Visual Studióban, a VS Code-ban, az Azure CLI-ben vagy az Azure PowerShellben fog keresni a fejlesztői hitelesítő adatok készletében, amelyek bármelyikével hitelesítheti az alkalmazást az Azure-erőforrásokban a helyi fejlesztés során.
Az Azure-ban való üzembe helyezéskor ugyanez a kód más Azure-erőforrásokon is hitelesítheti az alkalmazást. DefaultAzureCredential
lekérheti a környezeti beállításokat és a felügyelt identitáskonfigurációkat a többi szolgáltatás automatikus hitelesítéséhez.
A DefaultAzureCredential hitelesítési módszerek sorozatának feltárása
Belsőleg DefaultAzureCredential
hitelesítőadat-szolgáltatók láncát valósítja meg az alkalmazások Azure-erőforrásokhoz való hitelesítéséhez. Minden hitelesítőadat-szolgáltató képes észlelni, hogy az adott típusú hitelesítő adatok konfigurálva vannak-e az alkalmazáshoz. DefaultAzureCredential
sorrendben ellenőrzi az egyes szolgáltatókat, és az első, hitelesítő adatokat konfigurált szolgáltatótól származó hitelesítő adatokat használja.
A hitelesítő adatokat kereső sorrend és helyek DefaultAzureCredential
a DefaultAzureCredential helyen találhatók.
Hitelesítő adatok típusa | Leírás |
---|---|
Alkalmazás-szolgáltatásnév | DefaultAzureCredential Beolvassa a környezeti változók egy készletét annak megállapításához, hogy az alkalmazáshoz be van-e állítva egy alkalmazás-szolgáltatásnév (alkalmazásfelhasználó). Ha igen, DefaultAzureCredential ezeket az értékeket használva hitelesítheti az alkalmazást az Azure-ban.Ezt a módszert leggyakrabban kiszolgálókörnyezetekben használják, de helyi fejlesztéskor is használható. |
Felügyelt identitás | Ha az alkalmazás olyan Azure-gazdagépen van üzembe helyezve, amelyen engedélyezve van a felügyelt identitás, DefaultAzureCredential az alkalmazás hitelesítése az Azure-ban ezzel a felügyelt identitással történik. A felügyelt identitást használó hitelesítést a dokumentum Kiszolgálói környezetek hitelesítése szakasza ismerteti.Ez a módszer csak akkor érhető el, ha egy alkalmazást az Azure-ban üzemeltet egy olyan szolgáltatás használatával, mint a Azure-alkalmazás Szolgáltatás, az Azure Functions vagy az Azure Virtual Machines. |
Visual Studio | Ha a fejlesztő a Visual Studióba való bejelentkezéssel hitelesítette az Azure-t, DefaultAzureCredential azzal a fiókkal hitelesíti az alkalmazást az Azure-ban. |
Visual Studio Code | Ha a fejlesztő a Visual Studio Code Azure-fiók beépülő modullal hitelesítette az Azure-t, DefaultAzureCredential az alkalmazást ugyanazzal a fiókkal hitelesíti az Azure-ban. |
Azure CLI | Ha egy fejlesztő az Azure CLI-ben található paranccsal hitelesítette az az login Azure-t, DefaultAzureCredential ugyanazzal a fiókkal hitelesíti az alkalmazást az Azure-ban. |
Azure PowerShell | Ha egy fejlesztő az Azure PowerShell parancsmagjának használatával hitelesítette az Connect-AzAccount Azure-t, DefaultAzureCredential az alkalmazás hitelesítése az Azure-ban ugyanazzal a fiókkal történik. |
Interaktív | Ha engedélyezve van, DefaultAzureCredential a rendszer interaktívan hitelesíti a fejlesztőt az aktuális rendszer alapértelmezett böngészőjén keresztül. Alapértelmezés szerint ez a beállítás le van tiltva. |
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: