JavaScript-alkalmazások hitelesítése Azure-szolgáltatásokba az Azure SDK for JavaScript használatával

Ha egy alkalmazásnak hozzá kell férnie egy Azure-erőforráshoz (például Storage, Key Vault vagy Cognitive Services), 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 javasolt módszereket ismerteti, hogyan hitelesíthet egy alkalmazást az Azure-ban a JavaScripthez készült Azure SDK használatakor.

Az ajánlott eljárás az, hogy az alkalmazások jogkivonatalapú hitelesítést használjanak ahelyett, hogy kapcsolati sztring vagy kulcsokat használnak az Azure-erőforrásokhoz való hitelesítéskor. Az Azure SDK jogkivonatalapú hitelesítést biztosít, és lehetővé teszi 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.

Az alkalmazás által az Azure-erőforrásokon való hitelesítéshez használt jogkivonatalapú hitelesítés konkrét típusa attól függ, hogy az alkalmazás hol fut, és az alábbi ábrán látható.

Környezet Hitelesítés
Helyi 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.
Azure 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.
A helyszínen 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.

Egy alkalmazás ajánlott jogkivonatalapú hitelesítési stratégiáit bemutató diagram attól függően, hogy hol fut.

A jogkivonatalapú hitelesítés előnyei

Az Azure-hoz készült alkalmazások létrehozásakor a jogkivonatalapú hitelesítés erősen ajánlott titkos kódok (kapcsolati sztring vagy kulcsok) felett. A tokenalapú hitelesítés a DefaultAzureCredential szolgáltatással érhető el.

Jogkivonat-alapú hitelesítés Titkos kódok (kapcsolati sztring és kulcsok)
A minimális jogosultság elve, hogy meghatározza az alkalmazás által az Azure-erőforráson szükséges konkrét engedélyeket. Egy kapcsolati sztring vagy kulcs teljes jogokat biztosít az Azure-erőforrás számára.
Nincs tárolandó alkalmazáskulcs. Titkos kulcsokat kell tárolnia és elforgatnia az alkalmazásbeállításban vagy a környezeti változóban.
Az Azure Identity SDK a színfalak mögött kezeli a jogkivonatokat. Ez megkönnyíti a jogkivonatalapú hitelesítés használatát kapcsolati sztring. A titkos kulcsok nincsenek kezelve.

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.

Használja a következő SDK-t:

DefaultAzureCredential

Az Azure SDK DefaultAzureCredential metódussal az alkalmazások a futtatott környezettől függően különböző hitelesítési módszereket használhatnak. Ez lehetővé teszi az alkalmazások helyi, tesztelési és éles környezetben történő üzembe helyezését 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 használatát DefaultAzureCredential előnyben részesíti a feltételes logika vagy a funkciójelzők manuális kódolása, hogy különböző hitelesítési módszereket használjon különböző környezetekben.

A DefaultAzureCredential osztály használatáról a cikk későbbi részében, a DefaultAzureCredential használata az alkalmazásban című szakaszban olvashat.

Hitelesítés kiszolgálói környezetekben

Kiszolgálói környezetben való üzemeltetéskor minden alkalmazáshoz környezetenként egyedi alkalmazásidentitást kell hozzárendelni. 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és a helyi fejlesztés során

Ha egy alkalmazás egy fejlesztői munkaállomáson fut a helyi fejlesztés során, a helyi környezetnek továbbra is hitelesítenie kell magát az alkalmazás által használt Azure-szolgáltatásokban.

DefaultAzureCredential használata egy alkalmazásban

A DefaultAzureCredential JavaScript-alkalmazásokban való használatához adja hozzá a @azure/identitáscsomagot az alkalmazáshoz.

npm install @azure/identity

Ezután az alábbi kód példája bemutatja, hogyan lehet példányosítani egy DefaultAzureCredential objektumot, és hogyan használhatja azt egy Azure SDK-ügyfélosztálysal, ebben az esetben egy BlobServiceClienttel, amely a Blob Storage elérésére szolgál.

// connect-with-default-azure-credential.js
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config'

const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  new DefaultAzureCredential()
);

DefaultAzureCredential automatikusan észleli az alkalmazáshoz konfigurált hitelesítési mechanizmust, és beszerezi az alkalmazás Azure-beli hitelesítéséhez szükséges jogkivonatokat. Ha egy alkalmazás több SDK-ügyfelet használ, ugyanazt a hitelesítő objektumot használhatja minden egyes SDK-ügyfélobjektumhoz.

Hitelesítési módszerek kiválasztásának sorrendje a DefaultAzureCredential használatakor

Belsőleg megvalósítja a hitelesítőadat-szolgáltatók kiválasztásának láncát az DefaultAzureCredential 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.

Ha több hitelesítő adatot is konfigurált, fontos a hitelesítő adatok láncon keresztüli megkeresésének sorrendje.

Az alábbi ábrán és táblázatban látható az a sorrend, amelyben DefaultAzureCredential a JavaScripthez tartozó hitelesítő adatokat keresi.

A DefaultAzureCredential által az alkalmazáshoz konfigurált hitelesítési forrás ellenőrzésének sorrendjét bemutató diagram.

Két elérési út létezik:

  • Üzembe helyezett szolgáltatás (Azure vagy helyszíni): a sorrend a környezeti változókkal, majd a felügyelt identitással, majd a hitelesítő adatok többi helyével kezdődik (Visual Studio Code, Azure CLI, Azure PowerShell).
  • A fejlesztő helyi környezete: A helyi fejlesztői munkaállomás lánca a Visual Studio Code Bejelentkezett Azure-felhasználójával kezdődik, amely az IDE alsó sávján látható, majd továbblép az Azure CLI-re, majd az Azure PowerShellre. Fontos tisztában lenni azzal, hogy a helyi környezeti változókat a teljes környezethez vagy egy projekt virtuális környezetéhez (például a DOTENV-hez) konfigurálta-e, ezek a változók felülbírálják a Visual Studio Code –> Azure CLI –> PowerShell-láncot, mert ezek az első hitelesítő adatok a láncban.
Hitelesítő adatok típusa Leírás
Környezet A 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ás felügyelt identitással kompatibilis szolgáltatást használ 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, a DefaultAzureCredential 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.