Bezpieczny dostęp do usługi Azure Repos z potoków
Repozytoria są kluczowym zasobem sukcesu firmy, ponieważ zawierają kod, który obsługuje Twoją firmę. Nie należy łatwo udzielać dostępu do repozytoriów.
W tym artykule pokazano, jak poprawić bezpieczeństwo potoków uzyskujących dostęp do usługi Azure Repos, aby ograniczyć ryzyko wystąpienia kodu źródłowego w niewłaściwe ręce.
Przełączniki Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków innych niż wydania, Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków wydania i Chroń dostęp do repozytoriów w potokach YAML włącza się w konfiguracji potoków w celu bezpiecznego uzyskiwania dostępu do repozytoriów platformy Azure.
Omówimy zarówno potoki kompilacji, jak i klasyczne potoki wydania:
Proces podstawowy
Kroki są podobne we wszystkich potokach:
Określ listę repozytoriów usługi Azure Repos, do których potok potrzebuje dostępu, które są częścią tej samej organizacji, ale znajdują się w różnych projektach.
Listę repozytoriów można skompilować, sprawdzając potok. Możesz też włączyć zakres autoryzacji zadania Ogranicz do bieżącego projektu dla potoków (innych niż)wydania przełącznika i zanotować, które repozytoria potoku nie mogą wyewidencjonować. Repozytoria modułów podrzędnych mogą nie być wyświetlane w pierwszym nieudanym uruchomieniu.
Dla każdego projektu usługi Azure DevOps zawierającego repozytorium, do którego musi uzyskać dostęp potok, wykonaj kroki udzielania dostępu tożsamości kompilacji potoku do tego projektu.
Dla każdego repozytorium usługi Azure Repos wyewidencjonowywanie potoku wykonaj kroki udzielania tożsamości kompilacji potoku Dostęp do odczytu do tego repozytorium.
Dla każdego repozytorium, które jest używane jako moduł podrzędny przez repozytorium, w którym potok jest wyewidencjonowany i znajduje się w tym samym projekcie, wykonaj kroki udzielania tożsamości kompilacji potoku Dostęp do odczytu do tego repozytorium.
Włącz zakres limitu autoryzacji zadania do bieżącego projektu dla potoków innych niż wydania, Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków wydania i Chroń dostęp do repozytoriów w potokach YAML przełącza.
Potoki kompilacji
Aby zilustrować kroki, które należy wykonać, aby zwiększyć bezpieczeństwo potoków podczas uzyskiwania dostępu do usługi Azure Repos, użyjemy uruchomionego przykładu.
Załóżmy, że pracujesz nad potokiem SpaceGameWeb
hostowanym w projekcie fabrikam-tailspin/SpaceGameWeb
w SpaceGameWeb
repozytorium Azure Repos. Ponadto załóżmy, że potok SpaceGameWeb
wyewidencjonuje SpaceGameWebReact
repozytorium w tym samym projekcie, a FabrikamFiber
repozytoria i FabrikamChat
w projekcie fabrikam-tailspin/FabrikamFiber
.
Na koniec załóżmy, że FabrikamFiber
repozytorium używa FabrikamFiberLib
repozytorium jako modułu podrzędnego hostowanego w tym samym projekcie. Dowiedz się więcej na temat sposobu wyewidencjonowania modułów podrzędnych.
Struktury SpaceGameWeb
repozytorium projektu wyglądają podobnie jak na poniższym zrzucie ekranu.
Struktury FabrikamFiber
repozytorium projektu wyglądają podobnie jak na poniższym zrzucie ekranu.
Załóżmy, że projekt nie jest skonfigurowany do używania tożsamości kompilacji opartej na projekcie ani ochrony dostępu do repozytoriów w potokach YAML. Załóżmy również, że potok został już pomyślnie uruchomiony.
Używanie tożsamości kompilacji opartej na projekcie dla potoków kompilacji
Gdy potok jest wykonywany, używa tożsamości do uzyskiwania dostępu do różnych zasobów, takich jak repozytoria, połączenia usług, grupy zmiennych. Istnieją dwa typy tożsamości, których może używać potok: jeden na poziomie projektu i poziom kolekcji. Pierwszy zapewnia lepsze bezpieczeństwo, a drugi zapewnia łatwość użycia. Przeczytaj więcej na temat tożsamości kompilacji o określonym zakresie i zakresu autoryzacji zadań.
Zalecamy używanie tożsamości na poziomie projektu do uruchamiania potoków. Domyślnie tożsamości na poziomie projektu mogą uzyskiwać dostęp tylko do zasobów w projekcie, do których są członkami. Użycie tej tożsamości zwiększa bezpieczeństwo, ponieważ zmniejsza dostęp uzyskany przez złośliwą osobę podczas porwania potoku.
Aby umożliwić potokowi użycie tożsamości na poziomie projektu, włącz ustawienie Ogranicz zakres autoryzacji zadania do bieżącego projektu dla potoków innych niż wydania.
W naszym przykładzie uruchomionym po wyłączeniu tego przełącznika SpaceGameWeb
potok będzie mógł uzyskiwać dostęp do wszystkich repozytoriów we wszystkich projektach. Gdy przełącznik jest włączony, SpaceGameWeb
może uzyskiwać dostęp tylko do zasobów w projekcie fabrikam-tailspin/SpaceGameWeb
, więc tylko SpaceGameWeb
repozytoria i SpaceGameWebReact
.
Jeśli uruchomisz nasz przykładowy potok, po włączeniu przełącznika potok zakończy się niepowodzeniem, a dzienniki błędów poinformują Cię remote: TF401019: The Git repository with name or identifier FabrikamChat does not exist or you do not have permissions for the operation you are attempting.
i remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.
Aby rozwiązać problemy z wyewidencjonowaniami, wykonaj kroki opisane w procesie podstawowym.
Ponadto należy jawnie wyewidencjonować repozytoria modułów podrzędnych przed repozytoriami, które ich używają. W naszym przykładzie oznacza FabrikamFiberLib
to repozytorium.
Jeśli teraz uruchomisz nasz przykładowy potok, powiedzie się.
Dalsza konfiguracja
Aby zwiększyć bezpieczeństwo podczas uzyskiwania dostępu do usługi Azure Repos, rozważ włączenie ustawienia Ochrona dostępu do repozytoriów w potokach YAML.
Załóżmy SpaceGameWeb
, że potok jest potokiem YAML, a jego kod źródłowy YAML wygląda podobnie do poniższego kodu.
trigger:
- main
pool:
vmImage: ubuntu-latest
resources:
repositories:
- repository: SpaceGameWebReact
name: SpaceGameWeb/SpaceGameWebReact
type: git
- repository: FabrikamFiber
name: FabrikamFiber/FabrikamFiber
type: git
- repository: FabrikamChat
name: FabrikamFiber/FabrikamChat
type: git
steps:
- script: echo "Building SpaceGameWeb"
- checkout: SpaceGameWebReact
- checkout: FabrikamChat
condition: always()
- checkout: FabrikamFiber
submodules: true
condition: always()
- script: |
cd FabrikamFiber
git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
- script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md
- ...
Ochrona dostępu do repozytoriów w potokach YAML
Usługa Azure DevOps udostępnia precyzyjny mechanizm uprawnień dla repozytoriów usługi Azure Repos w postaci ustawienia Ochrona dostępu do repozytoriów w potokach YAML. To ustawienie sprawia, że potok YAML jawnie prosi o pozwolenie na dostęp do wszystkich repozytoriów usługi Azure Repos, niezależnie od tego, do którego projektu należą. Przeczytaj więcej na temat tego ustawienia. Wyewidencjonowywanie innych typów repozytoriów, na przykład hostowanych w usłudze GitHub, nie ma wpływu na to ustawienie.
W naszym przykładzie uruchomionym po włączeniu tego przełącznika SpaceGameWeb
potok poprosi o pozwolenie na dostęp do SpaceGameWebReact
repozytorium w fabrikam-tailspin/SpaceGameWeb
projekcie oraz FabrikamFiber
repozytoria i FabrikamChat
w projekcie fabrikam-tailspin/FabrikamFiber
.
Po uruchomieniu przykładowego potoku zobaczysz kompilację podobną do poniższego zrzutu ekranu.
Zostanie wyświetlony monit o udzielenie uprawnień do repozytoriów, które potok wyewidencjonuje lub zdefiniowano jako zasoby.
Po zakończeniu potok zostanie uruchomiony, ale zakończy się to niepowodzeniem, ponieważ nie będzie można wyewidencjonować FabrikamFiberLib
repozytorium jako modułu podrzędnego FabrikamFiber
. Aby rozwiązać ten problem, jawnie zapoznaj się z elementem FabrikamFiberLib
- checkout: git://FabrikamFiber/FabrikamFiberLib
, na przykład dodaj krok przed krokiem-checkout: FabrikamFiber
.
Jeśli teraz uruchomisz przykładowy potok, powiedzie się.
Nasz końcowy kod źródłowy potoku YAML wygląda podobnie do poniższego fragmentu kodu.
trigger:
- main
pool:
vmImage: ubuntu-latest
resources:
repositories:
- repository: SpaceGameWebReact
name: SpaceGameWeb/SpaceGameWebReact
type: git
- repository: FabrikamFiber
name: FabrikamFiber/FabrikamFiber
type: git
- repository: FabrikamChat
name: FabrikamFiber/FabrikamChat
type: git
steps:
- script: echo "Building SpaceGameWeb"
- checkout: SpaceGameWebReact
- checkout: FabrikamChat
condition: always()
- checkout: git://FabrikamFiber/FabrikamFiberLib
- checkout: FabrikamFiber
submodules: true
condition: always()
- script: |
cd FabrikamFiber
git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
- script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md
Rozwiązywanie problemów
Oto kilka problematycznych sytuacji i sposób ich obsługi.
Narzędzie git w wierszu polecenia służy do wyewidencjonowania repozytoriów w tej samej organizacji
Na przykład używasz polecenia - script: git clone https://$(System.AccessToken)@dev.azure.com/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/
. Polecenie zakończy się niepowodzeniem, gdy przełącznik Włącz ochronę dostępu do repozytoriów w potokach YAML jest włączony.
Aby rozwiązać ten problem, zapoznaj się OtherRepo
z repozytorium przy użyciu checkout
polecenia , na przykład - checkout: git://FabrikamFiber/OtherRepo
.
Repozytorium używa innego repozytorium jako modułu podrzędnego
Załóżmy, że jedno z repozytoriów, które wyewidencjonuje potok, używa innego repozytorium (w tym samym projekcie) co moduł podrzędny, tak jak w naszym przykładzie dla FabrikamFiber
repozytoriów i FabrikamFiberLib
. Dowiedz się więcej na temat sposobu wyewidencjonowania modułów podrzędnych.
Ponadto załóżmy, że udzielono SpaceGame
tożsamości kompilacji Dostęp do odczytu do tego repozytorium, ale wyewidencjonowanie FabrikamFiber
repozytorium nadal kończy się niepowodzeniem podczas wyewidencjonowania modułu podrzędnego FabrikamFiberLib
.
Aby rozwiązać ten problem, należy jawnie wyewidencjonować FabrikamFiberLib
element , na przykład dodać - checkout: git://FabrikamFiber/FabrikamFiberLib
krok przed nim -checkout: FabrikamFiber
.
Klasyczne potoki wydania
Proces zabezpieczania dostępu do repozytoriów dla potoków wydania jest podobny do tego dla potoków kompilacji.
Aby zilustrować kroki, które należy wykonać, użyjemy uruchomionego przykładu. W naszym przykładzie istnieje potok wydania o nazwie FabrikamFiberDocRelease
w projekcie fabrikam-tailspin/FabrikamFiberDocRelease
. Załóżmy, że potok wyewidencjonuje FabrikamFiber
repozytorium w fabrikam-tailspin/FabrikamFiber
projekcie, uruchamia polecenie w celu wygenerowania publicznej dokumentacji, a następnie publikuje je w witrynie internetowej. Ponadto załóżmy, że FabrikamFiber
repozytorium używa FabrikamFiberLib
repozytorium (w tym samym projekcie) jako modułu podrzędnego
Używanie tożsamości kompilacji opartej na projekcie dla klasycznych potoków wydania
Gdy potok jest wykonywany, używa tożsamości do uzyskiwania dostępu do różnych zasobów, takich jak repozytoria, połączenia usług, grupy zmiennych. Istnieją dwa typy tożsamości, których może używać potok: jeden na poziomie projektu i poziom kolekcji. Pierwszy zapewnia lepsze bezpieczeństwo, a drugi zapewnia łatwość użycia. Przeczytaj więcej na temat tożsamości kompilacji o określonym zakresie i zakresu autoryzacji zadań.
Zalecamy używanie tożsamości na poziomie projektu do uruchamiania potoków. Domyślnie tożsamości na poziomie projektu mogą uzyskiwać dostęp tylko do zasobów w projekcie, do których są członkami. Użycie tej tożsamości zwiększa bezpieczeństwo, ponieważ zmniejsza dostęp uzyskany przez złośliwą osobę podczas porwania potoku.
Aby potok używał tożsamości na poziomie projektu, włącz ustawienie Ogranicz zakres autoryzacji zadania do bieżącego projektu dla potoków wydania.
W naszym przykładzie uruchomionym po wyłączeniu FabrikamFiberDocRelease
tego przełącznika potok wydania może uzyskiwać dostęp do wszystkich repozytoriów we wszystkich projektach, w tym FabrikamFiber
do repozytorium. Gdy przełącznik jest włączony, FabrikamFiberDocRelease
może uzyskiwać dostęp tylko do zasobów w projekcie fabrikam-tailspin/FabrikamFiberDocRelease
, więc FabrikamFiber
repozytorium stanie się niedostępne.
Jeśli uruchomisz nasz przykładowy potok, po włączeniu przełącznika potok zakończy się niepowodzeniem, a dzienniki poinformują Cię o tym remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.
Aby rozwiązać te problemy, wykonaj kroki opisane w procesie podstawowym.
Jeśli teraz uruchomisz nasz przykładowy potok, powiedzie się.