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 se naučili, ž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.

(No changes needed if the context is gratuity)

Použijte jasný a popisný název pro registraci vaší aplikace. 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, který se často označuje 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í Microsoft Entra ID. 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.

Opatrnost

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í a použijte zobrazovaný název pro její 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 do Microsoft Entra ID. 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í fakticky říkáte Microsoft Entra ID a GitHubu, že si mají vzájemně důvěřovat. Tento vztah důvěry se nazývá federace.

Poté, když se váš pracovní postup pokusí přihlásit, GitHub poskytne informace o spuštění tohoto pracovního postupu, aby se Microsoft Entra ID mohlo rozhodnout, zda pokus o přihlášení povolit. Informace, které GitHub poskytuje Microsoft Entra ID během každého pokusu o přihlášení, 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é se zaměřuje úloha vašeho 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:

• povolit pokusy o přihlášení pouze při spuštění pracovního postupu z konkrétního úložiště GitHub v rámci mé organizace.
• povolit pouze přihlašovací pokusy, pokud pracovní postup běží z určitého úložiště GitHub v rámci mé organizace a název větve je "main".

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 Microsoft Entra ID 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 Microsoft Entra ID, ID registrace aplikace pro identitu pracovního procesu a ID předplatného Azure, kam chce pracovní proces být nasazen.

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řte federované přihlašovací údaje

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"
  ]
}

V tomto souboru vlastnost subject 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í zásady ve formátu JSON a jeho uložení do souboru s názvem policy.jsonmůžete pomocí Azure CLI vytvořit federované přihlašovací údaje:

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 vždy 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řil, kdo je zodpovědný za 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á.