Bezpieczny dostęp do usługi Azure Repos z potoków

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Twoje repozytoria mają kluczowe znaczenie dla sukcesu firmy, ponieważ zapewniają one kod umożliwiający wykonywanie operacji. Dostęp do repozytoriów powinien być starannie kontrolowany. Ten artykuł zawiera instrukcje dotyczące ulepszania zabezpieczeń potoku kompilacji i klasycznego potoku wydania podczas uzyskiwania dostępu do usługi Azure Repos w celu ograniczenia ryzyka nieautoryzowanego dostępu.

Aby zapewnić bezpieczny dostęp do repozytoriów platformy Azure, włącz następujące przełączanie:

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

Proces podstawowy

Następujące kroki w celu zabezpieczenia potoków są podobne we wszystkich potokach:

1. Zidentyfikuj repozytoria usługi Azure Repos, do których potok wymaga dostępu w ramach tej samej organizacji, ale w różnych projektach.
   W tym celu należy sprawdzić potok lub włączyć zakres autoryzacji zadania limitu do bieżącego projektu dla potoków (innych niż)release i zanotować, które repozytoria potoku nie mogą wyewidencjonować. Repozytoria modułów podrzędnych mogą nie być wyświetlane w pierwszym nieudanym uruchomieniu.
2. Udziel tożsamości kompilacji potoku dostęp do tego projektu dla każdego projektu zawierającego repozytorium, do którego musi uzyskać dostęp potok.
3. Udziel tożsamości kompilacji potoku Dostęp do odczytu do tego repozytorium dla każdego repozytorium wyewidencjonowania potoku.
4. Udziel 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, które wyewidencjonuje potok i znajduje się w tym samym projekcie.
5. Włącz ograniczenie zakresu 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.

Potoki kompilacji

Aby zilustrować kroki, które należy wykonać w celu zwiększenia bezpieczeństwa potoków podczas uzyskiwania dostępu do usługi Azure Repos, użyjemy poniższego przykładu.

• Załóżmy, że pracujesz nad potokiem SpaceGameWeb hostowanym w projekcie fabrikam-tailspin/SpaceGameWeb w SpaceGameWeb repozytorium Azure Repos.
• Potok SpaceGameWeb sprawdza SpaceGameWebReact repozytorium w tym samym projekcie oraz FabrikamFiber repozytoria i FabrikamChat w projekcie fabrikam-tailspin/FabrikamFiber .
• Repozytorium FabrikamFiber używa FabrikamFiberLib repozytorium jako modułu podrzędnego hostowanego w tym samym projekcie.
• 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

Podczas wykonywania potoku tożsamość jest używana do uzyskiwania dostępu do zasobów, takich jak repozytoria, połączenia usług i grupy zmiennych. Potoki mogą korzystać z dwóch typów tożsamości: na poziomie projektu i na poziomie kolekcji. Pierwszy priorytetuje bezpieczeństwo, podczas gdy ten ostatni podkreśla łatwość użytkowania. Aby uzyskać więcej informacji, zobacz tożsamości kompilacji w zakresie i zakres autoryzacji zadania.

W celu zapewnienia zwiększonych zabezpieczeń użyj tożsamości na poziomie projektu podczas uruchamiania potoków. Te tożsamości mogą uzyskiwać dostęp tylko do zasobów w ramach skojarzonego projektu, minimalizując ryzyko nieautoryzowanego dostępu przez złośliwych podmiotów.

Aby skonfigurować potok do używania tożsamości na poziomie projektu, włącz ustawienie Ogranicz zakres autoryzacji zadania dla 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 sekcji Proces podstawowy tego artykułu.

Ponadto jawnie zapoznaj się z repozytoriami modułów podrzędnych przed repozytoriami, które z nich korzystają. W naszym przykładzie oznacza FabrikamFiberLib to repozytorium.

Jeśli 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 opcji 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żą. Aby uzyskać więcej informacji, zobacz access repos (Repozytoria dostępu). To ustawienie nie ma wpływu na wyewidencjonowanie innych typów repozytoriów, takich jak hostowane w usłudze GitHub.

W naszym przykładzie uruchomionym po włączeniu SpaceGameWeb tego ustawienia potok prosi o uprawnienie dostępu do SpaceGameWebReact repozytorium w fabrikam-tailspin/SpaceGameWeb projekcie, a FabrikamFiber repozytoria i FabrikamChat w projekcie fabrikam-tailspin/FabrikamFiber .

Po uruchomieniu przykładowego potoku kompilacja będzie podobna do poniższego przykładu.

Udzielanie uprawnień do repozytoriów lub zasobów potoku.

Potok działa, ale kończy się niepowodzeniem, ponieważ nie można wyewidencjonować FabrikamFiberLib repozytorium jako modułu podrzędnego .FabrikamFiber Aby rozwiązać ten problem, należy jawnie wyewidencjonować FabrikamFiberLibelement , dodając - checkout: git://FabrikamFiber/FabrikamFiberLib krok przed krokiem -checkout: FabrikamFiber .

Przykładowy potok zakończy się pomyślnie.

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

Skorzystaj z poniższych rozwiązań dla wszelkich pojawiających się problemów.

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 kończy się niepowodzeniem po włączeniu ustawienia Ochrona dostępu do repozytoriów w potokach YAML.

Aby rozwiązać ten problem, zapoznaj się OtherRepo z repozytorium przy użyciu checkout polecenia , takiego jak - 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, wyewidencjonuj FabrikamFiberLibjawnie element , dodając - 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. Zapoznaj się z dodatkowymi repozytoriami usługi Azure Repos, dodając zadania wiersza polecenia za git clone 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żą. Aby uzyskać więcej informacji, zobacz Access tokens (Tokeny dostępu), Protect access to repozytoriies in YAML pipelines (Ochrona dostępu do repozytoriów w potokach YAML).

Podczas włączania ustawienia Chroń dostęp do repozytoriów w potokach YAML należy zachować ostrożność. Jeśli tak, klasyczne potoki kompilacji nie będą mogły uzyskać dostępu do żadnego innego repozytorium usługi Azure DevOps, z wyjątkiem tego, który został określony w ustawieniach. 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 używa zarówno potoków YAML, jak i klasycznych potoków kompilacji, a klasyczne potoki kompilacji zapoznaj się z więcej repozytoriów usługi Azure DevOps poza tymi określonymi w ich ustawieniach, utwórz dwa projekty, jeden dla potoków YAML i jeden dla klasycznych potoków kompilacji. Następnie w projekcie potoków YAML włącz odpowiednie 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 zostanie uruchomiony 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. Ten ostatni 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 informują 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 sekcji Proces podstawowy tego artykułu.

Nasz przykładowy potok zakończy się pomyślnie.

Powiązane artykuły

• 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