Een workloadidentiteit maken voor een GitHub Actions-werkstroom

Voltooid

Nu u het concept van een workloadidentiteit begrijpt, vraagt u zich misschien af hoe u er een maakt en koppelt aan een implementatiewerkstroom van GitHub Actions. In deze les ziet u de stappen om dat te bereiken.

Een Microsoft Entra-toepassing maken

In de vorige les hebt u geleerd dat voor workloadidentiteiten een toepassingsregistratie in Microsoft Entra-id moet worden gemaakt.

Notitie

Voor het maken en wijzigen van toepassingsregistraties moet u machtigingen hebben in Microsoft Entra ID. In sommige organisaties hebt u mogelijk een beheerder nodig om deze stappen voor u uit te voeren.

Wanneer u een toepassingsregistratie maakt, moet u een weergavenaam opgeven. De weergavenaam is een door mensen leesbare naam die de toepassingsregistratie beschrijft.

Tip

Gebruik een duidelijke, beschrijvende weergavenaam voor uw toepassingsregistratie. Het is belangrijk om uw team te helpen begrijpen waar de toepassingsregistratie voor is, zodat niemand deze per ongeluk verwijdert of de machtigingen ervan wijzigt.

Hier volgt een voorbeeld van een Azure CLI-opdracht voor het maken van een nieuwe Microsoft Entra-toepassing:

az ad app create --display-name $applicationRegistrationName

Hier volgt een voorbeeld van een Azure PowerShell-opdracht voor het maken van een nieuwe Microsoft Entra-toepassing:

New-AzADApplication -DisplayName $applicationRegistrationName

De uitvoer van de voorgaande opdracht bevat belangrijke stukjes informatie, waaronder:

• Toepassings-id: De toepassingsregistratie heeft een unieke id, vaak een toepassings-id of soms een client-id genoemd. U gebruikt deze id wanneer uw werkstroom zich moet aanmelden bij Azure.
• Object-id: De registratie van de toepassing heeft een object-id. Dit is een unieke id die door Microsoft Entra-id wordt toegewezen. Verderop in deze module ziet u een voorbeeld van het gebruik van een object-id.

Wanneer u een toepassingsregistratie maakt, stelt u doorgaans alleen de weergavenaam in. Azure wijst automatisch de andere namen en id's toe.

Let op

Een weergavenaam is niet uniek. Meerdere toepassingsregistraties kunnen dezelfde weergavenaam delen. Wees voorzichtig wanneer u machtigingen verleent aan een toepassingsregistratie met behulp van de weergavenaam om deze te identificeren. Mogelijk geeft u per ongeluk machtigingen aan de verkeerde toepassingsregistraties. Het is een goede gewoonte om in plaats daarvan een van de unieke id's te gebruiken.

Federatieve referenties

Wanneer een identiteit moet communiceren met Azure, meldt deze zich aan bij Microsoft Entra-id. Een toepassingsregistratie staat op zichzelf niet toe dat een werkstroom of toepassing zich aanmeldt bij Azure. U moet eerst enkele referenties toewijzen. Federatieve referenties zijn één type toepassingsreferentie. In tegenstelling tot de meeste referenties hoeft u federatieve referenties niet te beheren, zoals wachtwoorden of sleutels.

Wanneer u een federatieve referentie voor een implementatiewerkstroom maakt, vertelt u Microsoft Entra ID en GitHub elkaar effectief te vertrouwen. Deze vertrouwensrelatie wordt een federatie genoemd.

Wanneer uw werkstroom zich vervolgens probeert aan te melden, biedt GitHub informatie over de werkstroomuitvoering, zodat Microsoft Entra ID kan bepalen of de aanmeldingspoging moet worden toegestaan. De informatie die GitHub tijdens elke aanmeldingspoging aan Microsoft Entra-id biedt, kan de volgende velden bevatten:

• De naam van de GitHub-gebruiker of -organisatie.
• De naam van de GitHub-opslagplaats.
• De vertakking van uw opslagplaats waarop de werkstroom momenteel wordt uitgevoerd.
• De omgeving waarop uw werkstroomtaak is gericht. In een toekomstige module leert u meer over omgevingen.
• Of het maken van een pull-aanvraag de werkstroom heeft geactiveerd.

U kunt Microsoft Entra-id configureren om een aanmeldingspoging vanuit GitHub toe te staan of te weigeren, afhankelijk van de waarden van de eerder vermelde eigenschappen. U kunt bijvoorbeeld het volgende beleid afdwingen:

• Alleen aanmeldingspogingen toestaan wanneer een werkstroom wordt uitgevoerd vanuit een specifieke GitHub-opslagplaats binnen mijn organisatie.
• Alleen aanmeldingspogingen toestaan wanneer een werkstroom wordt uitgevoerd vanuit een specifieke GitHub-opslagplaats binnen mijn organisatie en de naam van de vertakking de hoofdnaam is.

Hier volgt een afbeelding van hoe een implementatiewerkstroom zich kan aanmelden met behulp van een workloadidentiteit en federatieve referenties:

De stappen in het aanmeldingsproces zijn:

1. Wanneer uw werkstroom moet communiceren met Azure, neemt GitHub veilig contact op met Microsoft Entra-id om een toegangstoken aan te vragen. GitHub biedt informatie over de GitHub-organisatie (), de opslagplaats (my-github-usermy-repo) en de vertakking waarop de werkstroom wordt uitgevoerd (main). Het bevat ook uw tenant-id in Microsoft Entra ID, de toepassings-id van de toepassingsregistratie van de werkstroomidentiteit en de Azure-abonnements-id waarop uw werkstroom wil implementeren.

2. Microsoft Entra ID valideert de toepassings-id en controleert of er een federatieve referentie bestaat in de toepassing voor de GitHub-organisatie, opslagplaats en vertakking.

3. Nadat de Microsoft Entra-id heeft vastgesteld dat de aanvraag geldig is, geeft deze een toegangstoken uit. Uw werkstroom gebruikt het toegangstoken wanneer deze communiceert met Azure Resource Manager.

Een federatieve referentie maken

Wanneer u de Azure CLI gebruikt, definieert u een federatieve referentie door een JSON-bestand of variabele te maken. Bekijk bijvoorbeeld het volgende JSON-bestand:

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

In dat bestand geeft de subject eigenschap aan dat de federatieve referentie alleen geldig moet zijn wanneer een werkstroom wordt uitgevoerd voor de volgende situaties:

Veld	Waarde
Naam van GitHub-organisatie	my-github-user
Naam van GitHub-opslagplaats	my-repo
Naam van vertakking	main

Nadat u een beleid in JSON hebt gemaakt en dit hebt opgeslagen in een bestand met de naam policy.json, kunt u de Azure CLI gebruiken om de federatieve referentie te maken:

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

Wanneer u Azure PowerShell gebruikt, definieert u een federatieve referentie door een tekenreeks te maken die vergelijkbaar is met de volgende:

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

De voorgaande tekenreeks geeft aan dat de federatieve referentie alleen geldig moet zijn wanneer een werkstroom wordt uitgevoerd voor de volgende situaties:

Veld	Waarde
Naam van GitHub-organisatie	my-github-user
Naam van GitHub-opslagplaats	my-repo
Naam van vertakking	main

Nadat u een beleidstekenreeks hebt gemaakt, kunt u Azure PowerShell gebruiken om de federatieve referentie te maken:

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

De levenscyclus van uw workloadidentiteit beheren

Het is belangrijk om rekening te houden met de hele levenscyclus van elke workloadidentiteit die u maakt. Wat gebeurt er wanneer u een workloadidentiteit bouwt voor een implementatiewerkstroom als de werkstroom uiteindelijk wordt verwijderd of niet meer wordt gebruikt?

Workloadidentiteiten en federatieve referenties worden niet automatisch verwijderd, dus u moet oude identiteiten controleren en verwijderen. Hoewel de workloadidentiteiten van uw implementatiewerkstroom geen geheime referenties hebben die opnieuw kunnen worden gebruikt, kunt u ze het beste verwijderen wanneer ze niet meer nodig zijn. Op die manier is er geen kans dat iemand een andere GitHub-opslagplaats met dezelfde naam kan maken en onverwacht toegang krijgt tot uw Azure-omgeving.

Het is een goede gewoonte om uw workloadidentiteiten vast te leggen op een plek waartoe u en uw team eenvoudig toegang hebben. Neem de volgende informatie op voor elke workloadidentiteit:

• Belangrijke identificatiegegevens, zoals de naam en de toepassings-id
• Het doel ervan
• Wie het gemaakt, wie is verantwoordelijk voor het beheren ervan en wie er mogelijk antwoorden heeft als er een probleem is
• De machtigingen die het nodig heeft en een duidelijke reden waarom ze nodig zijn
• De verwachte levensduur

U moet uw workloadidentiteiten regelmatig controleren om ervoor te zorgen dat ze nog steeds worden gebruikt en dat de machtigingen waaraan ze zijn toegewezen, nog steeds juist zijn.