Vytvoření identity úlohy pro pracovní postup GitHub Actions

Dokončeno

Když teď rozumíte konceptu identity úloh, možná vás zajímá, jak ji vytvoříte, a propoříte ji s pracovním postupem nasazení GitHub Actions. V této lekci se dozvíte, jak toho dosáhnout.

Vytvoření aplikace Microsoft Entra

V předchozí lekci jste zjistili, že identity úloh vyžadují vytvoření registrace aplikace v Microsoft Entra ID.

Poznámka:

Vytváření a úpravy registrací aplikací vyžaduje, abyste měli oprávnění v MICROSOFT Entra ID. V některých organizacích může být potřeba, aby správce provedl tyto kroky za vás.

Při vytváření registrace aplikace musíte zadat zobrazovaný název. Zobrazovaný název je čitelný název, který popisuje registraci aplikace.

Tip

Pro registraci aplikace použijte jasný popisný zobrazovaný název. Je důležité, abyste svému týmu pomohli pochopit, k čemu je registrace aplikace určená, aby ji nikdo omylem neodstranil nebo změnil jeho oprávnění.

Tady je ukázkový příkaz Azure CLI pro vytvoření nové aplikace Microsoft Entra:

az ad app create --display-name $applicationRegistrationName

Tady je ukázkový příkaz Azure PowerShellu pro vytvoření nové aplikace Microsoft Entra:

New-AzADApplication -DisplayName $applicationRegistrationName

Výstup předchozího příkazu obsahuje důležité informace, mezi které patří:

• ID aplikace: Registrace aplikace má jedinečný identifikátor, často označovaný jako ID aplikace nebo někdy ID klienta. Tento identifikátor použijete, když se váš pracovní postup musí přihlásit k Azure.
• ID objektu: Registrace aplikace má ID objektu, což je jedinečný identifikátor, který přiřadí ID Microsoft Entra. Později v tomto modulu se dozvíte, jak použít ID objektu.

Při vytváření registrace aplikace obvykle nastavíte pouze zobrazovaný název. Azure automaticky přiřadí ostatní názvy a identifikátory.

Upozornění

Zobrazovaný název není jedinečný. Stejný zobrazovaný název může sdílet více registrací aplikací. Při udělování oprávnění k registraci aplikace buďte opatrní pomocí jejího zobrazovaného názvu k jeho identifikaci. Omylem můžete udělit oprávnění nesprávným registracím aplikací. Místo toho je vhodné použít jeden z jedinečných identifikátorů.

Federované přihlašovací údaje

Když identita potřebuje komunikovat s Azure, přihlásí se k ID Microsoft Entra. Registrace aplikace sama o sobě neumožňuje, aby se pracovní postup nebo aplikace přihlásily k Azure. Nejdřív je potřeba přiřadit některé přihlašovací údaje. Federované přihlašovací údaje jsou jedním typem přihlašovacích údajů aplikace. Na rozdíl od většiny přihlašovacích údajů nevyžadují federované přihlašovací údaje, abyste spravovali tajné kódy, jako jsou hesla nebo klíče.

Při vytváření federovaných přihlašovacích údajů pro pracovní postup nasazení efektivně sdělíte Microsoft Entra ID a GitHub, aby vzájemně důvěřovaly. Tento vztah důvěryhodnosti se nazývá federace.

Když se váš pracovní postup pokusí přihlásit, GitHub poskytne informace o spuštění pracovního postupu, aby se ID Microsoft Entra mohlo rozhodnout, jestli se má pokus o přihlášení povolit. Informace, které GitHub během každého pokusu o přihlášení poskytuje id Microsoft Entra, můžou obsahovat následující pole:

• Název uživatele nebo organizace GitHubu.
• Název úložiště GitHub.
• Větev vašeho úložiště, na které je pracovní postup aktuálně spuštěný.
• Prostředí, na které cílí vaše úloha pracovního postupu. Další informace o prostředích se dozvíte v budoucím modulu.
• Určuje, jestli vytvoření žádosti o přijetí změn aktivovalo pracovní postup.

Id Microsoft Entra můžete nakonfigurovat tak, aby umožňovalo nebo odepíral pokus o přihlášení z GitHubu v závislosti na hodnotách dříve uvedených vlastností. Můžete například vynutit následující zásady:

• Povolte jen pokusy o přihlášení, když se pracovní postup spustí z konkrétního úložiště GitHubu v rámci mé organizace.
• Povolte jenom pokusy o přihlášení, když se pracovní postup spustí z konkrétního úložiště GitHubu v rámci mé organizace a název větve je hlavní.

Tady je obrázek toho, jak se pracovní postup nasazení může přihlásit pomocí identity úlohy a federovaných přihlašovacích údajů:

Kroky, které jsou součástí procesu přihlášení, jsou:

1. Když váš pracovní postup potřebuje komunikovat s Azure, GitHub bezpečně kontaktuje ID Microsoft Entra a požádá o přístupový token. GitHub poskytuje informace o organizaci GitHubu (my-github-user), úložišti (my-repo) a větvi, na které je pracovní postup spuštěný (main). Zahrnuje také ID vašeho tenanta v rámci Microsoft Entra ID, ID aplikace registrace aplikace identity pracovního postupu a ID předplatného Azure, do kterého chcete pracovní postup nasadit.

2. Microsoft Entra ID ověří ID aplikace a zkontroluje, jestli v aplikaci pro organizaci, úložiště a větev GitHubu existuje federované přihlašovací údaje.

3. Jakmile Microsoft Entra ID zjistí, že požadavek je platný, vydá přístupový token. Váš pracovní postup používá přístupový token při komunikaci s Azure Resource Managerem.

Vytvoření federovaných přihlašovacích údajů

Při použití Azure CLI definujete federované přihlašovací údaje vytvořením souboru NEBO proměnné JSON. Podívejte se například na následující soubor JSON:

{
  "name": "MyFederatedCredential",
  "issuer": "https://token.actions.githubusercontent.com",
  "subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
  "audiences": [
    "api://AzureADTokenExchange"
  ]
}

Vlastnost v tomto souboru určuje, že federované přihlašovací údaje by měly být platné pouze v případě, subject že pracovní postup běží v následujících situacích:

Pole	Hodnota
Název organizace GitHubu	my-github-user
Název úložiště GitHub	my-repo
Název větve	main

Když ve formátu JSON vytvoříte zásadu a uložíte ji do souboru s názvem policy.json, můžete k vytvoření federovaných přihlašovacích údajů použít Azure CLI:

az ad app federated-credential create \
  --id $applicationRegistrationObjectId \
  --parameters @policy.json

Při použití Azure PowerShellu definujete federované přihlašovací údaje vytvořením řetězce podobného následujícímu:

$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"

Předchozí řetězec určuje, že federované přihlašovací údaje by měly být platné pouze v případě, že pracovní postup běží v následujících situacích:

Pole	Hodnota
Název organizace GitHubu	my-github-user
Název úložiště GitHub	my-repo
Název větve	main

Po vytvoření řetězce zásad můžete pomocí Azure PowerShellu vytvořit federované přihlašovací údaje:

New-AzADAppFederatedCredential `
  -Name 'MyFederatedCredential' `
  -ApplicationObjectId $applicationRegistrationObjectId `
  -Issuer 'https://token.actions.githubusercontent.com' `
  -Audience 'api://AzureADTokenExchange' `
  -Subject $policy

Správa životního cyklu vaší identity úloh

Je důležité vzít v úvahu celý životní cyklus každé vytvořené identity úloh. Když sestavíte identitu úlohy pro pracovní postup nasazení, co se stane, když se pracovní postup nakonec odstraní nebo se už nepoužívá?

Identity úloh a federované přihlašovací údaje se neodeberou automaticky, takže je potřeba je auditovat a odebrat. I když identity úloh pracovního postupu nasazení nemají tajné přihlašovací údaje, které by se daly znovu použít, je stále nejlepší je odebrat, když už nejsou potřeba. Díky tomu není možné, že by někdo mohl vytvořit jiné úložiště GitHub se stejným názvem a neočekávaně získat přístup k vašemu prostředí Azure.

Osvědčeným postupem je zdokumentovat identity úloh na místě, ke kterému máte vy a váš tým snadný přístup. Pro každou identitu úlohy uveďte následující informace:

• Identifikace klíčových informací, jako je název a ID aplikace
• Jeho účel
• Kdo ho vytvořili, kdo je zodpovědný za jeho správu a kdo by mohl mít odpovědi, pokud dojde k problému
• Oprávnění, která potřebuje, a jasné odůvodnění, proč je potřebuje
• Její očekávaná životnost

Identity úloh byste měli pravidelně auditovat, abyste měli jistotu, že se stále používají a že jsou přiřazená oprávnění stále správná.