Utwórz tożsamość roboczą dla przepływu pracy GitHub Actions
Teraz, gdy rozumiesz koncepcję tożsamości obciążenia, możesz się zastanawiać, jak ją utworzyć i połączyć z przepływem pracy wdrażania funkcji GitHub Actions. W tej lekcji przedstawiono kroki, które należy wykonać.
Utwórz aplikację Microsoft Entra
W poprzedniej lekcji przedstawiono, że tożsamości obciążeń wymagają utworzenia rejestracji aplikacji w identyfikatorze Entra firmy Microsoft.
Uwaga
Tworzenie i modyfikowanie rejestracji aplikacji wymaga posiadania uprawnień w identyfikatorze Entra firmy Microsoft. W niektórych organizacjach może być konieczne wykonanie tych kroków przez administratora.
Podczas tworzenia rejestracji aplikacji należy określić nazwę wyświetlaną. Nazwa wyświetlana to nazwa czytelna dla człowieka, która opisuje rejestrację aplikacji.
Napiwek
Użyj klarownej, opisowej nazwy wyświetlanej dla rejestracji aplikacji. Ważne jest, aby pomóc zespołowi zrozumieć, do czego służy rejestracja aplikacji, aby nikt przypadkowo go nie usunął lub zmienił uprawnienia.
Oto przykładowe polecenie Azure CLI służące do tworzenia nowej aplikacji Microsoft Entra:
az ad app create --display-name $applicationRegistrationName
Oto przykładowe polecenie programu Azure PowerShell umożliwiające utworzenie nowej aplikacji Firmy Microsoft Entra:
New-AzADApplication -DisplayName $applicationRegistrationName
Dane wyjściowe powyższego polecenia zawierają ważne informacje, w tym:
- identyfikator aplikacji: rejestracja aplikacji ma unikatowy identyfikator, często nazywany identyfikatorem aplikacji lub czasami identyfikatorem klienta . Identyfikator ten jest używany, gdy przepływ pracy wymaga zalogowania się do platformy Azure.
- Identyfikator obiektu: Rejestracja aplikacji ma identyfikator obiektu, który jest unikatowym identyfikatorem przypisywanym przez Microsoft Entra ID. W dalszej części tego modułu zobaczysz przykład użycia identyfikatora obiektu.
Podczas tworzenia rejestracji aplikacji zazwyczaj ustawia się tylko nazwę wyświetlaną. Platforma Azure automatycznie przypisuje inne nazwy i identyfikatory.
Ostrożność
Nazwa wyświetlana nie jest unikatowa. Wiele rejestracji aplikacji może dzielić tę samą nazwę wyświetlaną. Należy zachować ostrożność podczas udzielania uprawnień do rejestracji aplikacji przy użyciu jej nazwy wyświetlanej w celu jej identyfikacji. Być może przypadkowo nadasz uprawnienia do nieprawidłowych rejestracji aplikacji. Dobrym rozwiązaniem jest użycie jednego z unikatowych identyfikatorów.
Poświadczenia federacyjne
Gdy tożsamość musi komunikować się z platformą Azure, loguje się do identyfikatora Entra firmy Microsoft. Sama rejestracja aplikacji nie zezwala na logowanie się do platformy Azure przez przepływ pracy ani aplikację. Najpierw musisz przydzielić poświadczenia. poświadczenia federacyjne są jednym typem poświadczeń aplikacji. W przeciwieństwie do większości poświadczeń, poświadczenia federacyjne nie wymagają zarządzania danymi poufnymi, takimi jak hasła lub klucze.
Podczas tworzenia poświadczeń federacyjnych dla przepływu pracy wdrażania skutecznie informujesz microsoft Entra ID i GitHub o zaufaniu sobie nawzajem. Ta relacja zaufania jest nazywana federacją .
Następnie, gdy workflow próbuje się zalogować, GitHub udostępnia informacje o uruchomieniu tego workflow, aby Microsoft Entra ID mógł zdecydować, czy zezwolić na próbę logowania. Informacje, które usługa GitHub udostępnia identyfikatorowi Entra firmy Microsoft podczas każdej próby logowania, mogą zawierać następujące pola:
- Nazwa użytkownika lub organizacji usługi GitHub.
- Nazwa repozytorium GitHub.
- Gałąź repozytorium, na której jest obecnie uruchomiony przepływ pracy.
- Docelowe środowisko dla zadania w przepływie pracy. Więcej informacji na temat środowisk znajdziesz w przyszłym module.
- Czy utworzenie "pull request" zainicjowało przepływ pracy.
Możesz skonfigurować identyfikator Entra firmy Microsoft, aby zezwolić na próbę logowania z usługi GitHub lub go odrzucić, w zależności od wartości wymienionych wcześniej właściwości. Można na przykład wymusić następujące zasady:
- zezwalaj na próby logowania tylko wtedy, gdy przepływ pracy jest uruchamiany z określonego repozytorium GitHub w mojej organizacji.
- zezwalaj na próby zalogowania tylko wtedy, gdy workflow jest uruchamiany z określonego repozytorium GitHub w mojej organizacji, a nazwa gałęzi jest główna.
Oto ilustracja przedstawiająca sposób logowania workflow wdrażania przy użyciu tożsamości roboczej i poświadczeń federacyjnych.
Kroki związane z procesem logowania to:
Gdy przepływ pracy musi komunikować się z platformą Azure, GitHub bezpiecznie kontaktuje się z Microsoft Entra ID, aby zażądać tokenu dostępu . Usługa GitHub zawiera informacje o organizacji GitHub (
my-github-user), repozytorium (my-repo) i gałęzi, w której działa przepływ pracy (main). Zawiera również identyfikator dzierżawy w ramach Microsoft Entra ID, identyfikator aplikacji związany z rejestracją tożsamości przepływu pracy oraz identyfikator subskrypcji platformy Azure, do której przepływ pracy ma zostać wdrożony.Microsoft Entra ID weryfikuje identyfikator aplikacji i sprawdza, czy w aplikacji istnieje poświadczenie federacyjne dla organizacji GitHub, repozytorium i gałęzi.
Gdy identyfikator entra firmy Microsoft ustali, że żądanie jest prawidłowe, wystawia token dostępu. Przepływ pracy używa tokenu dostępu podczas komunikacji z usługą Azure Resource Manager.
Utwórz poświadczenie federacyjne
W przypadku korzystania z interfejsu wiersza polecenia platformy Azure należy zdefiniować poświadczenia federacyjne, tworząc plik lub zmienną JSON. Na przykład zapoznaj się z następującym plikiem JSON:
{
"name": "MyFederatedCredential",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
"audiences": [
"api://AzureADTokenExchange"
]
}
W tym pliku właściwość subject określa, że poświadczenie federacyjne powinno być prawidłowe tylko wtedy, gdy przepływ pracy jest uruchamiany w następujących sytuacjach:
| Pole | Wartość |
|---|---|
| Nazwa organizacji usługi GitHub | my-github-user |
| Nazwa repozytorium GitHub | my-repo |
| Nazwa gałęzi | main |
Po utworzeniu zasad w formacie JSON i zapisaniu ich w pliku o nazwie policy.jsonmożesz utworzyć poświadczenie federacyjne przy użyciu interfejsu wiersza polecenia platformy Azure:
az ad app federated-credential create \
--id $applicationRegistrationObjectId \
--parameters @policy.json
W przypadku korzystania z programu Azure PowerShell należy zdefiniować poświadczenia federacyjne, tworząc ciąg podobny do następującego:
$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"
Powyższy ciąg określa, że poświadczenie federacyjne powinno być prawidłowe tylko wtedy, gdy przepływ pracy działa w następujących sytuacjach:
| Pole | Wartość |
|---|---|
| Nazwa organizacji usługi GitHub | my-github-user |
| Nazwa repozytorium GitHub | my-repo |
| Nazwa gałęzi | main |
Po utworzeniu ciągu zasad możesz użyć programu Azure PowerShell do utworzenia poświadczeń federacyjnych:
New-AzADAppFederatedCredential `
-Name 'MyFederatedCredential' `
-ApplicationObjectId $applicationRegistrationObjectId `
-Issuer 'https://token.actions.githubusercontent.com' `
-Audience 'api://AzureADTokenExchange' `
-Subject $policy
Zarządzaj cyklem życia tożsamości użytkownika w obciążeniu roboczym
Ważne jest, aby wziąć pod uwagę cały cykl życia każdej tworzonej tożsamości obciążenia. ** Co się stanie, jeśli utworzysz tożsamość obciążenia dla przepływu pracy wdrażania, a ten przepływ zostanie ostatecznie usunięty lub przestanie być używany?
Tożsamości obciążeń i poświadczenia federacyjne nie są usuwane automatycznie, dlatego należy przeprowadzić audyt i usunąć starsze. Nawet jeśli tożsamości pracy w procesie wdrażania nie mają poświadczeń tajnych, które można ponownie wykorzystać, najlepiej jest je usunąć, gdy nie są już potrzebne. W ten sposób nie ma szans, aby ktoś mógł utworzyć inne repozytorium GitHub o tej samej nazwie i nieoczekiwanie uzyskać dostęp do środowiska platformy Azure.
Dobrym rozwiązaniem jest dokumentowanie tożsamości obciążeń w miejscu, do którego ty i Twój zespół mogą łatwo uzyskiwać dostęp. Dołącz następujące informacje dla każdej tożsamości obciążenia:
- Kluczowe informacje identyfikujące, takie jak jego nazwa i identyfikator aplikacji
- Jego cel
- Kto go utworzył, kto jest odpowiedzialny za zarządzanie nim i kto może mieć odpowiedzi, jeśli występuje problem
- Uprawnienia, których potrzebuje, oraz wyraźne uzasadnienie, dlaczego ich potrzebuje
- Oczekiwany okres istnienia
Należy regularnie przeprowadzać inspekcję tożsamości obciążeń, aby upewnić się, że są one nadal używane i czy przypisane przez nich uprawnienia są nadal poprawne.