Principy služebních identit
Služební principály poskytují způsob ověřování pipeline, aplikací a softwaru. V této lekci se dozvíte, proč jsou služební identity důležité pro kanály nasazení, jak zapadají do zabezpečovacího modelu Azure a jak fungují.
Proč se pipeline potřebuje ověřit?
Při nasazení šablony Bicep efektivně požádáte Azure Resource Manager o vytvoření nebo úpravu prostředků Azure. V tomto ukázkovém scénáři jste vytvořili šablonu Bicep pro nasazení webových stránek vaší hračkářské společnosti. Šablona Bicep deklaruje prostředky, které zahrnují plán služby Azure App Service, aplikaci a instanci Application Insights.
Když šablonu nasadíte, Resource Manager zkontroluje, jestli prostředky existují. Pokud ne, Resource Manager je vytvoří. Pokud už existují, Resource Manager zajistí, aby jejich konfigurace odpovídala konfiguraci, kterou zadáte v šabloně.
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í budou záviset na tom, co šablona obsahuje. Pokud chcete nasadit ukázkovou šablonu Bicep pro webovou stránku vaší hračkářské společnosti, musíte mít následující oprávnění ve skupině prostředků, do které nasazujete:
- Schopnost vytvářet nasazení. Nasazení jsou považována za 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 šablony 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. To se nazývá použitím vlastní identity. Když odešlete nasazení, Azure ověří, že vaše identita má potřebná oprávnění k provedení toho, co určuje vaše Bicep šablona.
Po přechodu na pipeline musíte použít jiný typ identity, protože samotná pipeline spouští nasazení bez vaší přímé účasti.
Typy zabezpečovacích principálů
Microsoft Entra ID je služba, která spravuje identity pro Azure. Identifikátor Microsoft Entra má více typů identit, které se také označují jako bezpečnostní principy:
- 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é se provádějí při přihlašování, jako je vícefaktorové ověřování (MFA) a podmíněný přístup na základě jejich umístění nebo sítě.
- 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.
- služební principál představuje automatizovaný proces nebo systém, který obvykle nevyžaduje, aby jej přímo spouštěl člověk.
- spravovaná identita je speciální typ služebního principálu, který je určený pro situace, kdy se člověk nezapojuje do procesu ověřování.
Služební účty
Služba je typ účtu. Může se přihlásit k Microsoft Entra ID, ale není zde žádná osoba, která by se přihlásila a interagovala s autentizačním procesem. Instanční objekty nemají vícefaktorové ověřování ani podobné ochrany, protože ty vyžadují, aby osoba něco udělala, aby prokázala svou identitu.
V Microsoft Entra ID je služební objekt identifikován ID aplikace a pověření. ID aplikace je globálně jedinečné ID (GUID). Pro potrubí je přihlašovací údaj obvykle silné heslo nazývané klíč. Alternativně můžete jako přihlašovací údaje použít certifikát.
Spravované identity
Na rozdíl od ostatních typů služebních zástupců spravovaná identita nevyžaduje, abyste znali nebo spravovali její přihlašovací údaje. 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. Představují skvělý způsob, jak mohou prostředky Azure ověřit sami sebe v situacích, jako je 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 také používat se službou Azure Arc pro jiné scénáře.
Při práci s datovými toky obvykle nemůžete používat spravované identity. Důvodem je to, že spravované identity vyžadují, abyste vlastní a spravlili prostředky Azure, které spouští vaše nasazení. Při práci se službou Azure Pipelines se obvykle spoléháte na sdílenou infrastrukturu poskytovanou Microsoftem.
Poznámka
Existují situace, kdy datové toky můžou používat spravované identity. V Azure Pipelines můžete vytvořit agenta v místním prostředí ke spuštění skriptů a kódu kanálu pomocí vlastního virtuálního počítače založeného na Azure. Vzhledem k tomu, že vlastníte virtuální počítač, můžete mu přiřadit spravovanou identitu a použít ji z pipeline.
Většinu času vaše pipelines běží pomocí hostovaného agenta, což je server spravovaný společností Microsoft. Hostovaní agenti momentálně nejsou kompatibilní se spravovanými identitami.
Rada
Pokud máte v jiných částech řešení na výběr mezi používáním spravované identity nebo normálního služebního principálu, je nejlepší použít spravovanou identitu. Práce s nima je jednodušší a obvykle je 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 pro ověření kanálu, pokud 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í.
Kanály jsou navržené tak, aby spouštěly vaše nasazení, i když je nikdo aktivně nespouští. Ve skutečnosti většina výhod kanálů pochází ze skutečnosti, že jsou zcela automatizované a nevyžadují lidskou interakci. Pokud uživatelské jméno a heslo uložíte do procesu a pokusíte se je použít k přihlášení, pravděpodobně nebudou fungovat. I když se zdá, že fungují, mohou v budoucnu snadno selhat, pokud Microsoft Entra ID nebo správce vaší organizace přidá do procesu ověřování uživatelů další kontroly zabezpečení.
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 předdefinované úlohy potrubí, které komunikují s Azure, nedovolují zadat přihlašovací údaje uživatelského účtu. Vyžadují, abyste použili služební účet.
Jak fungují služební principálové?
Při práci s objekty služby nebo s nástroji, jako je Azure portal nebo Microsoft Graph API, se může zobrazit několik různých termínů. I když není nezbytné porozumět těmto pojmům jen kvůli používání služebních principů v pipeline, je užitečné znát tyto koncepty.
Principály služeb jsou funkcí Microsoft Entra ID. Microsoft Entra ID 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. Kanál nasazení si můžete představit jako aplikaci.
V Microsoft Entra ID můžou aplikace provádět mnoho věcí, které jsou nad rámec ověřování a procesů nasazení. Když vytvoříte aplikaci a informujete o ní Microsoft Entra ID, vytvoříte objekt s názvem registrace aplikace. Registrace aplikace představuje aplikaci v Microsoft Entra ID.
Služební identity a aplikace jsou úzce propojené. Při každém přidání registrace aplikace do tenanta Microsoft Entra se v daném tenantovi Microsoft Entra vytvoří objekt instanční objekt. Když se podíváte na aplikační objekt v Azure portálu, uvidíte spoustu dalších funkcí a konfigurací, které se nemusí zdát relevantní. Většina z toho je proto, že hlavní služby jsou propojené s aplikacemi.
Při vytváření služebního principálu většina nástrojů, které používáte, zároveň vytvoří registraci aplikace. Možná si tedy nevšimnete, že existují dva různé objekty.
Jeden typ služebního principálu není spojený s registrací aplikace: spravovaná identita. Jak už bylo zmíněno dříve, Azure spravuje konfiguraci a přihlašovací údaje pro spravovanou identitu.
Poznámka
Entitní služba se někdy označuje jako podniková aplikace. Některé nástroje používají jeden název a jiné nástroje používají ten druhý. Můžete také vidět instanční objekty označované jako spravované aplikace v místním adresáři, ale nejsou to totéž jako spravované identity.
Abychom to shrnuli, při vytváření pověřené identity služby nejprve vytvoříte registraci aplikace a potom vytvoříte pověřenou identitu služby pro tuto registraci aplikace k použití. Většina nástrojů, se kterými pracujete, to udělá za vás, takže o něm ani nevíte. Při práci s kanály nasazení možná nebudete používat všechny funkce aplikací Microsoft Entra. Přesto, protože principály služby souvisejí s aplikacemi, platí stejná struktura objektů Microsoft Entra.