Bezpieczny dostęp do repozytoriów z pipeline'ów

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

Aby chronić kod, który uruchamia operacje, organizacje muszą dokładnie kontrolować dostęp do repozytoriów kodu źródłowego. W tym artykule opisano, jak potoki kompilacji i wydania usługi Azure Pipelines mogą bezpiecznie uzyskiwać dostęp do repozytoriów, aby zminimalizować ryzyko nieautoryzowanego dostępu.

Ten artykuł jest częścią serii, która ułatwia implementowanie środków zabezpieczeń dla usługi Azure Pipelines. Aby uzyskać więcej informacji, zobacz Bezpieczne Azure Pipelines.

Wymagania wstępne

Tożsamości projektowe dla potoków

Pipeline używa tożsamości do uzyskiwania dostępu do zasobów, takich jak repozytoria, połączenia usługi i grupy zmiennych podczas działania. Potoki mogą korzystać z dwóch typów tożsamości: na poziomie kolekcji lub na poziomie projektu.

Tożsamość na poziomie kolekcji jest łatwa do skonfigurowania i użycia, natomiast tożsamości na poziomie projektu przykładają większą wagę do bezpieczeństwa. Aby zwiększyć bezpieczeństwo, użyj tożsamości projektowych do uruchamiania pipelines. Tożsamość na poziomie projektu może uzyskiwać dostęp do zasobów tylko w ramach projektu, minimalizując wpływ nieautoryzowanego dostępu przez złośliwych podmiotów. Aby uzyskać więcej informacji, zobacz Zakres tożsamości kompilacji i Zakres autoryzacji zadania.

Aby skonfigurować potok do używania tożsamości na poziomie projektu, włącz Ogranicz zakres autoryzacji zadania do bieżącego projektu dla potoków innych niż wydania lub Ogranicz zakres autoryzacji zadania do bieżącego projektu dla potoków wydania w Ustawieniach Projektu pod Ustawienia>.

Procedura ulepszania zabezpieczeń dostępu do repozytorium

Administrator projektu lub administrator kolekcji projektów może wykonać następujące kroki, aby zwiększyć bezpieczeństwo uzyskiwania dostępu do repozytoriów Git z potoków.

1. Aby zidentyfikować wymagane repozytoria w innych projektach, sprawdź ciągi technologiczne. Jeśli włączysz ograniczenie zakresu autoryzacji zadania do aktualnego projektu dla potoków niezwiązanych z wydaniami, potoki mogą pobrać kod tylko z repozytoriów aktualnego projektu.

2. Przyznaj projektom w ramach pipeline'u dostęp do wszelkich potrzebnych im innych projektów. Aby uzyskać więcej informacji, zobacz Konfigurowanie uprawnień dla projektu w celu uzyskania dostępu do innego projektu w tej samej kolekcji projektów.

3. Udziel tożsamościom budowania potoków prawo do odczytu dla każdego repozytorium, które sprawdzają. Przyznaj również tożsamościom potoków prawo do odczytu dla wszystkich repozytoriów używanych jako moduły podrzędne przez wymagane repozytoria. Aby uzyskać więcej informacji, zobacz Konfigurowanie uprawnień dostępu do innego repozytorium w tej samej kolekcji projektów.

4. Włącz następujące ustawienia organizacji lub projektu dla projektu potokowego:

   • Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków niezwiązanych z wydaniami.
   • Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków wydania jeśli w Twoim projekcie są potoki wydania.
   • Ochrona dostępu do repozytoriów w potokach YAML usługi Azure Repos jeśli projekt zawiera potoki YAML.

   Włącz te ustawienia, ustawiając ich przełączniki na Włączone w Ustawieniach organizacji lub Ustawieniach projektu>Pipelines>Ustawienia>Ogólne.

   Jeśli ustawienia są włączone w ustawieniach organizacji, nie można ich zastąpić w ustawieniach projektu. Jeśli ustawienia nie są włączone w ustawieniach organizacji, można je włączyć na poziomie projektu.

Używanie repozytorium jako modułu podrzędnego

Jeśli repozytorium używa innego repozytorium w projekcie jako modułu podrzędnego, wyewidencjonowanie może zakończyć się niepowodzeniem podczas wyewidencjonowania modułu podrzędnego, nawet jeśli przyznasz potokowi dostęp odczyt do obu repozytoriów. Aby rozwiązać ten problem, najpierw wyewidencjonuj repozytoria modułów podrzędnych, zanim wyewidencjonujesz repozytoria, które ich używają. Aby uzyskać więcej informacji, zobacz Zapoznaj się z podmodułami.

Repozytoria GitHub

Poniższe uwagi dotyczące bezpieczeństwa odnoszą się do dostępu poprzez potok do repozytoriów GitHub. Aby uzyskać więcej informacji, zobacz Dostęp do repozytoriów GitHub.

Połączenia usługi GitHub

Aby korzystać z repozytoriów GitHub, usługa Azure Pipelines wymaga połączenia z usługą GitHub. Aby wzmocnić zabezpieczenia połączeń z usługą:

• Zezwalaj na dostęp tylko do repozytoriów, które są wymagane do uruchamiania potoków.
• Nie zaznaczaj opcji Udziel uprawnień dostępu do wszystkich potoków dla połączenia z usługą. Jawnie autoryzuj połączenie z usługą dla każdego potoku, który go używa.

Uwierzytelnianie w repozytoriach GitHub

Aby wyzwalać kompilacje i pobierać kod podczas kompilacji, usługa Azure Pipelines musi mieć dostęp do repozytoriów GitHub. Ten dostęp może korzystać z osobistego tokenu dostępu do GitHub (PAT), OAuth lub uwierzytelniania aplikacji GitHub Azure Pipelines. Aby uzyskać więcej informacji, zobacz Dostęp do repozytoriów GitHub.

Aplikacja GitHub Azure Pipelines jest zalecanym typem uwierzytelniania dla potoków ciągłej integracji. Kompilacje i aktualizacje stanu usługi GitHub używają tożsamości usługi Azure Pipelines zamiast osobistej tożsamości usługi GitHub. Podczas instalowania aplikacji można ograniczyć repozytoria, do których aplikacja może uzyskiwać dostęp w celu zwiększenia bezpieczeństwa.

Uwierzytelnianie OAuth i uwierzytelnianie pat korzystają z osobistej tożsamości usługi GitHub i muszą być autoryzowane w celu uzyskania dostępu do potoku. Korzystanie z PAT jest zniechęcane ze względu na obawy dotyczące bezpieczeństwa. Jeśli musisz użyć uwierzytelniania PAT, wybierz precyzyjnie skonfigurowany PAT i ogranicz jego zakres do określonych użytkowników, repozytoriów i uprawnień. Aby uzyskać więcej informacji, zobacz Zarządzanie osobistymi tokenami dostępu.

Rozwidżone repozytoria GitHub

Rozgałęzione repozytoria zwiększają ryzyko wykonania złośliwego kodu lub ujawnienia poufnych informacji w kanałach przetwarzania. Rozwidlenia pochodzące spoza organizacji stanowią szczególne ryzyko.

Aby zminimalizować ryzyko związane z rozwidlonymi repozytoriami, domyślnie włączone są opcje Ogranicz budowanie pull requestów z rozwidlonych repozytoriów GitHub i Wyłącz budowanie pull requestów z rozwidlonych repozytoriów w Ustawieniach Projektu lub Ustawieniach Organizacji>Potokach>Ustawieniach>Wyzwalaczach.

Aby umożliwić budowanie z rozwidlonych repozytoriów GitHub, lecz ograniczyć ryzyko, zaznacz opcję Bezpieczne budowanie pull requestów z rozwidlonych repozytoriów. To ustawienie nie zezwala na udostępnianie tajnych danych ani używanie takich samych uprawnień co w standardowych procesach budowania, i wymaga komentarza do żądania wciągnięcia od członka zespołu w celu wyzwolenia potoku.

Alternatywnie możesz wybrać pozycję Dostosuj reguły tworzenia pull requestów z rozwidlonych repozytoriów, aby jeszcze bardziej dostosować te ustawienia.

Inne sposoby zwiększania bezpieczeństwa rozwidlenia obejmują:

• Jeśli używasz walidacji żądania pull do wyzwalania kompilacji, usuń zaznaczenie opcji Kompiluj żądania pull z rozwidlenia tego repozytorium w sekcji Wyzwalacz w definicji potoku, lub upewnij się, że tajne są dostępne dla kompilacji rozwidlenia i kompilacje rozwidlenia mają takie same uprawnienia, jak zwykłe kompilacje zostały odznaczone. Możesz również wybrać pozycję Wymagaj komentarza członka zespołu przed utworzeniem żądania ściągnięcia.

• Użyj agentów hostowanych przez Microsoft do kompilowania z odgałęzień. Zasoby są następnie natychmiast usuwane z agentów po kompilacjach. Jeśli używasz własnych agentów, regularnie czyścisz i aktualizujesz agentów lub używasz oddzielnych agentów dla różnych rozwidlenia lub gałęzi.

Repozytoria usługi Azure Repos

Przykład usługi Azure Repos

Poniższy przykład ilustruje proces poprawy zabezpieczeń dostępu do usługi Azure Repos w potoku.

Organizacja https://dev.azure.com/fabrikam-tailspin zawiera projekty SpaceGameWeb i FabrikamFiber .

• Projekt SpaceGameWeb zawiera repozytoria SpaceGameWeb i SpaceGameWebReact .

  

• Projekt FabrikamFiber zawiera repozytoria FabrikamFiber, FabrikamChat i FabrikamFiberLib. Repozytorium FabrikamFiber używa repozytorium FabrikamFiberLib jako modułu podrzędnego.

  

Potok SpaceGameWeb w projekcie SpaceGameWeb sprawdza repozytorium SpaceGameWebReact w projekcie SpaceGameWeb oraz repozytoria FabrikamFiber i FabrikamChat w projekcie FabrikamFiber.

Jeśli projekt nie jest skonfigurowany do używania tożsamości kompilacji opartej na projekcie lub ochrony dostępu do repozytoriów w potokach YAML, potok SpaceGameWeb może uzyskać dostęp do wszystkich repozytoriów we wszystkich projektach w organizacji i działa pomyślnie.

Użyj tożsamości projektowej

Aby zwiększyć bezpieczeństwo, użyj tożsamości na poziomie projektu, aby uruchomić pipeline. Włącz opcję Ogranicz zakres autoryzacji zadania do bieżącego projektu dla potoków innych niż wydania przełącznika w ustawieniach projektu lub ustawieniach organizacji.

Jeśli to ustawienie jest włączone, pipeline może uzyskiwać dostęp tylko do zasobów w projekcie SpaceGameWeb, zawierającym jedynie repozytoria SpaceGameWeb i SpaceGameWebReact. Pipeline ulega niepowodzeniu, ponieważ nie może pobrać repozytoriów w projekcie FabrikamFiber.

Zobaczysz błędy 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, przyznaj projektowi potoku dostęp do projektu FabrikamFiber i przyznaj tożsamości potoku dostęp do odczytu do repozytoriów FabrikamFiber, FabrikamChat i FabrikamFiberLib.

Jawne wyewidencjonowywanie modułu podrzędnego

Repozytorium FabrikamFiber używa repozytorium FabrikamFiberLib jako modułu podrzędnego. Nawet jeśli przyznasz potokowi dostęp do obu repozytoriów, wyewidencjonowanie repozytorium FabrikamFiber nadal kończy się niepowodzeniem podczas wyewidencjonowania modułu podrzędnego FabrikamFiberLib .

Aby rozwiązać ten problem, przed wyewidencjonowaniem repozytorium FabrikamFiberLib należy wyewidencjonować repozytorium FabrikamFiber . checkout: git://FabrikamFiber/FabrikamFiberLib Dodaj krok przed krokiemcheckout: FabrikamFiber. Przykładowy potok zakończy się teraz pomyślnie.

Ochrona dostępu do pipeline'u YAML

Jeśli przykładowy potok SpaceGameWeb jest potokiem YAML, a włączono ochronę dostępu do repozytoriów w potokach YAML , potok wymaga uprawnień dostępu do repozytoriów SpaceGameWebReact, FabrikamFiber i FabrikamChat po raz pierwszy.

Poniższy kod przedstawia pełny potok YAML.

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

Więcej środków zabezpieczeń repozytorium

• Aby zmniejszyć ryzyko związane z udostępnianiem zasobów przez potoki YAML i klasyczne, wyłącz tworzenie potoków klasycznych, włączając opcje Wyłącz tworzenie klasycznych potoków kompilacji i Wyłącz tworzenie klasycznych potoków wydania w ustawieniach projektu lub ustawieniach organizacji. Tworzenie klasycznych potoków kompilacji i wdrożeń jest domyślnie wyłączone dla nowych organizacji.

• Użyj szablonów potoków, aby zdefiniować strukturę potoku i zapobiec infiltracji złośliwego kodu. Szablony mogą również automatycznie wykonywać zadania, takie jak skanowanie poświadczeń lub wymuszanie kontroli chronionych zasobów.

• Wymagaj ręcznego zatwierdzania za każdym razem, gdy pipeline żąda repozytorium. Aby uzyskać więcej informacji, zobacz Zatwierdzenia i kontrole.

• Użyj sprawdzania gałęzi chronionej , aby zapobiec automatycznemu uruchamianiu potoków w nieautoryzowanych gałęziach.

• Ustaw repozytorium, które ma być używane tylko w określonych potokach YAML. Aby uzyskać więcej informacji, zobacz sekcję Dodawanie uprawnień potoku do zasobu repozytorium.

• Ogranicz zakres tokenu dostępu usługi Azure Pipelines, przekazując token tylko dla repozytoriów wymienionych w sekcji potoku resources. Aby uzyskać więcej informacji, zobacz Ochrona repozytorium.

Treści powiązane

• Uzyskiwanie dostępu do repozytoriów, artefaktów i innych zasobów
• Ochrona zasobu repozytorium
• Opcje potoku dla repozytoriów Git
• Zabezpieczenia zasobów