Pochopení identit úloh

7 min

Pracovní postupy nasazení, aplikace a software vyžadují zvláštní způsob ověřování. V této lekci se dozvíte, proč jsou identity úloh pro pracovní postupy nasazení důležité, jak se hodí do modelu zabezpečení Azure a jak fungují.

Proč se pracovní postup potřebuje ověřit?

Když nasadíte soubor Bicep, efektivně požádáte Azure Resource Manager, aby vytvořil nebo upravil prostředky Azure. V ukázkovém scénáři jste vytvořili soubor Bicep pro nasazení webových stránek vaší hračkářské společnosti. Soubor Bicep deklaruje prostředky, které zahrnují plán služby Azure App Service, aplikaci a instanci Application Insights.

Když soubor nasadíte, Resource Manager zkontroluje, jestli prostředky existují. Pokud ne, Resource Manager je vytvoří. Pokud už nějaké prostředky existují, Resource Manager zajistí, aby jejich konfigurace odpovídala konfiguraci, kterou jste zadali v souboru Bicep.

Všechny tyto operace vyžadují oprávnění, protože přistupují k prostředkům Azure a upravují je. Konkrétní oprávnění potřebná pro nasazení závisí na tom, co soubor Bicep obsahuje. Pokud chcete nasadit ukázkový soubor pro webové stránky vaší hračkářské společnosti, musíte mít následující oprávnění v rámci skupiny prostředků, do které nasazujete:

Schopnost vytvářet nasazení. Nasazení jsou prostředky typu Microsoft.Resources/deployments.
Možnost vytvářet a upravovat plány a aplikace služby App Service.
Možnost vytvářet a upravovat instance Application Insights.

Doteď jste pravděpodobně nasadili soubory Bicep sami pomocí Azure CLI nebo Azure PowerShellu. Když tyto nástroje používáte, obvykle používáte vlastní uživatelský účet a ověřujete ho pomocí prohlížeče. Tomu se říká použití vlastní identity. Když odešlete nasazení, Azure ověří, že vaše identita má potřebná oprávnění k tomu, aby mohla provést to, co určuje vaše šablona Bicep.

Po přechodu na pracovní postup nasazení GitHub Actions musíte použít jiný typ identity, protože pracovní postup spouští nasazení bez přímého zapojení.

Typy identit

Microsoft Entra ID je služba, která spravuje identity pro Azure. Mezi hlavní typy identit patří:

identity uživatelů: Uživatel představuje člověka, který se obvykle interaktivně přihlašuje pomocí prohlížeče. Uživatelé často mají další kontroly zabezpečení, které je potřeba provést při přihlášení, jako je vícefaktorové ověřování (MFA) a podmíněný přístup na základě jejich umístění nebo sítě.
skupiny: Skupina představuje kolekci uživatelů. Skupiny se neověřují přímo, ale poskytují pohodlný způsob, jak přiřadit oprávnění skupině uživatelů dohromady.
identity úloh: Úloha je automatizovaný proces nebo systém, který obvykle není přímo spuštěn člověkem. Úloha se může přihlásit k ID Microsoft Entra, ale neexistuje žádný člověk, který by se mohl přihlásit a pracovat s procesem ověřování. Identity úloh nemají vícefaktorové ověřování ani podobné ochrany, protože tyto funkce vyžadují, aby osoba něco udělala, aby prokázala svou identitu.

Tento modul se zaměřuje na identity úloh.

Spravované identity

Spravovaná identita je přidružená k prostředku Azure. Azure spravuje přihlašovací údaje automaticky. Když prostředek potřebuje přístup k něčemu, Azure se automaticky přihlásí pomocí přihlašovacích údajů.

Spravované identity jsou k dispozici pro prostředky hostované v Azure, jako jsou virtuální počítače a aplikace App Service. Jedná se o skvělý způsob, jak se prostředky Azure mohou ověřit v situacích, jako jsou automatizace správy Azure, připojení k databázím a čtení tajných dat ze služby Azure Key Vault. Spravované identity můžete používat s Azure Arc i pro jiné scénáře.

Při práci s pracovními postupy nasazení obvykle nepoužíváte spravované identity. Spravované identity vyžadují, abyste vlastní a spravlili prostředky Azure, které spouští vaše nasazení. Při práci s GitHub Actions se obvykle spoléháte na sdílenou infrastrukturu, kterou poskytuje Microsoft nebo GitHub. Pokud ale používáte identitu úloh s GitHub Actions, můžete získat hlavní výhodu spravovaných identit: nemusíte spravovat žádné přihlašovací údaje.

Spropitné

Pokud máte v jiných částech řešení na výběr mezi používáním spravované identity nebo běžného servisního principalu, je nejlepší použít spravovanou identitu. Se spravovanými identitami se snadněji pracuje a obvykle jsou bezpečnější.

Proč nemůžete jenom používat svůj uživatelský účet?

Možná vás zajímá, proč potřebujete vytvořit celý nový typ objektu, jen abyste ověřili pracovní postup nasazení, když máte uživatelské účty, které fungují dokonale dobře.

Uživatelské účty nejsou navržené pro bezobslužné použití. Proces ověřování uživatelského účtu často kontroluje, jestli je člověk entitou, která se pokouší přihlásit. Organizace stále častěji používají další kontroly zabezpečení během ověřování. Mezi tyto kontroly patří vícefaktorové ověřování, kontroly CAPTCHA a kontrola zařízení a sítě, které uživatel používá, aby mohl ověřit oprávněnost žádosti o přihlášení.

Pracovní postupy jsou navržené tak, aby spouštěly vaše nasazení, i když je nikdo aktivně nespouští. Většina výhod pracovních postupů nasazení ve skutečnosti vychází ze skutečnosti, že jsou automatizované a nevyžadují lidskou interakci.

Pokud uživatelské jméno a heslo uložíte do pracovního postupu a pokusíte se je použít k přihlášení, pravděpodobně nebudou fungovat. I když se zdá, že fungují, můžou v budoucnu snadno přestat fungovat, pokud Microsoft Entra ID nebo správce vaší organizace přidá do procesu ověřování uživatelů další bezpečnostní kontroly.

Varování

Je také špatný nápad uložit uživatelské jméno a heslo kdekoli, protože někdo jiný k nim může získat přístup a pak ho použít k zosobnění.

Z těchto důvodů vám integrované úlohy GitHub Actions, které pracují s Azure, nedovolují zadat přihlašovací údaje uživatelského účtu. Vyžadují, abyste použili identitu úlohy.

Jak fungují identity úloh?

Identity úloh jsou součástí služby Microsoft Entra ID, což je globální služba identit. Mnoho společností používá Microsoft Entra ID a každá společnost se nazývá tenant.

Microsoft Entra ID má koncept aplikace, který představuje systém, část softwaru, proces nebo jiného nelidského agenta. Pracovní postup nasazení si můžete představit také jako aplikaci.

Když vytvoříte aplikaci a informujete o ní Microsoft Entra ID, vytvoříte objekt nazvaný registrace aplikace. Registrace aplikace představuje aplikaci v Microsoft Entra ID.

Registrace aplikace může mít přidružené federované přihlašovací údaje. Federované přihlašovací údaje nevyžadují, abyste ukládal žádné tajné kódy. Místo toho povolí podporovanou službu, jako je GitHub, aby používala aplikaci Microsoft Entra.

Když se pracovní postup GitHub Actions potřebuje ověřit, kontaktuje ID Microsoft Entra prostřednictvím GitHubu. GitHub předává Microsoft Entra ID název organizace GitHub a úložiště, případně i některé další informace. Pokud jste nakonfigurovali federované přihlašovací údaje, které odpovídají podrobnostem úložiště, Microsoft Entra ověří váš pracovní postup nasazení. Pracovní postup může používat oprávnění, která jste přiřadili aplikaci.

Spropitné

Když se podíváte na registraci aplikace na webu Azure Portal, uvidíte spoustu dalších funkcí a konfigurace, které se nemusí zdát relevantní. Je to proto, že aplikace můžou provádět mnoho věcí v ID Microsoft Entra, které jsou nad rámec ověřování a nasazení pracovních postupů.

V tenantovi Microsoft Entra můžete také vytvořit objekt hlavní služby . Objekt služebního principu je jako kopie aplikace určená k použití v rámci vašeho vlastního tenanta Microsoft Entra. Principály služeb a aplikace jsou úzce propojené. V tomto modulu později použijete principál služby, když udělíte svému pracovnímu postupu oprávnění k přístupu do Azure.

Poznámka