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:

• Potoki kompilacji
• Klasyczne potoki wydania

Proces podstawowy

Kroki są podobne we wszystkich potokach:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Potoki 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ć FabrikamFiberLibelement , na przykład dodać - checkout: git://FabrikamFiber/FabrikamFiberLib krok przed nim -checkout: FabrikamFiber .

Klasyczne potoki kompilacji

W klasycznych potokach kompilacji nie można jawnie zadeklarować innych repozytoriów jako zasobów. Sposób wyewidencjonowania większej liczby repozytoriów usługi Azure Repos polega na dodaniu zadań git clone wiersza polecenia za pomocą poleceń, podobnie jak w przypadku następującego polecenia, aby wyewidencjonować FabrikamFiber repozytorium: git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --recurse-submodules https://dev.azure.com/silviuandrica/FabrikamFiber/_git/FabrikamFiber.

Ustawienie Ochrona dostępu do repozytoriów w potokach YAML

Ustawienie Ochrona dostępu do repozytoriów w potokach YAML 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.

Podczas włączania ustawienia Chroń dostęp do repozytoriów w potokach YAML należy zachować ostrożność. Jeśli to zrobisz, klasyczne potoki kompilacji nie będą mogły uzyskać dostępu do żadnego innego repozytorium usługi Azure DevOps, z wyjątkiem tego określonego w Ustawienia. W naszym przykładowym potoku zostanie wyświetlony błąd i komunikat dziennika TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Jeśli projekt zawiera zarówno potoki YAML, jak i klasyczne potoki kompilacji oraz klasyczne potoki kompilacji, zapoznaj się z innymi repozytoriami usługi Azure DevOps oprócz tych określonych w ich ustawieniach, chcesz utworzyć dwa projekty, jeden dla potoków YAML i jeden dla klasycznych potoków kompilacji. Następnie w projekcie potoków YAML możesz włączyć ustawienie.

Ustawienie Ochrona dostępu do repozytoriów w potokach YAML nie ma zastosowania do repozytoriów hostowanych w innych usługach, takich jak GitHub.

Ustawienie zakresu autoryzacji zadania kompilacji

Ustawienie Ogranicz zakres autoryzacji zadania do bieżącego projektu dla potoków innych niż wydania zastępuje ustawienie Zakresu autoryzacji zadania kompilacji. Jeśli włączysz poprzednią opcję, potok będzie uruchamiany z tożsamością opartą na projekcie, nawet jeśli zakres autoryzacji zadania kompilacji określa kolekcję projektów.

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ę.

Zobacz też

• Tożsamości kompilacji o określonym zakresie
• Zakres autoryzacji zadania
• Udzielanie tożsamości kompilacji potoku do projektu
• Udzielanie tożsamości kompilacji potoku Dostęp do odczytu do repozytorium
• Jak sprawdzić podmoduły