Azure Pipelines — aktualizacja przebiegu 227

  • Artykuł

Funkcje

Federacja tożsamości obciążeń w usłudze Azure Pipelines (publiczna wersja zapoznawcza)

Czy chcesz zatrzymać przechowywanie wpisów tajnych i certyfikatów w połączeniach usług platformy Azure? Chcesz przestać martwić się o rotację tych wpisów tajnych za każdym razem, gdy wygasają? Ogłaszamy publiczną wersję zapoznawcza federacji tożsamości obciążenia dla połączeń usług platformy Azure.Federacja tożsamości obciążeń używa standardowej technologii Open ID Połączenie (OIDC), aby uprościć uwierzytelnianie między usługą Azure Pipelines i platformą Azure. Zamiast wpisów tajnych podmiot federacji jest używany do ułatwienia tego uwierzytelniania.

W ramach tej funkcji połączenie usługi Platformy Azure (ARM) zostało zaktualizowane przy użyciu innego schematu w celu obsługi federacji tożsamości obciążenia. Dzięki temu zadania potoku korzystające z połączenia usługi platformy Azure mogą uwierzytelniać się przy użyciu podmiotu federacji (sc://<org>/<project>/<service connection name>). Główne korzyści wynikające z używania tego schematu w istniejących schematach uwierzytelniania są następujące:

  • Uproszczone zarządzanie: nie należy już generować, kopiować i przechowywać wpisów tajnych z jednostek usługi w usłudze Azure AD do usługi Azure DevOps. Wpisy tajne używane w innych schematach uwierzytelniania połączeń usługi platformy Azure (np. jednostka usługi) wygasają po upływie określonego okresu (obecnie dwa lata). Po wygaśnięciu potoki kończą się niepowodzeniem. Musisz ponownie wygenerować nowy wpis tajny i zaktualizować połączenie usługi. Przełączanie do federacji tożsamości obciążenia eliminuje konieczność zarządzania tymi wpisami tajnymi i poprawia ogólne środowisko tworzenia połączeń usług i zarządzania nimi.
  • Ulepszone zabezpieczenia: W przypadku federacji tożsamości obciążenia nie ma trwałego wpisu tajnego związanego z komunikacją między usługą Azure Pipelines i platformą Azure. W związku z tym zadania uruchomione w zadaniach potoku nie mogą wyciekać ani eksfiltrować wpisów tajnych, które mają dostęp do środowisk produkcyjnych. Często dotyczyło to naszych klientów.

Możesz skorzystać z tych funkcji na dwa sposoby:

  • Użyj nowego schematu federacji tożsamości obciążenia za każdym razem, gdy tworzysz nowe połączenie z usługą platformy Azure. W przyszłości będzie to zalecany mechanizm.
  • Przekonwertuj istniejące połączenia usługi platformy Azure (oparte na wpisach tajnych) na nowy schemat. Tę konwersję można wykonać pojedynczo. Co najlepsze, nie trzeba modyfikować żadnych potoków korzystających z tych połączeń usług. Po zakończeniu konwersji zostaną automatycznie zastosowane nowe schematy.

Aby utworzyć nowe połączenie usługi platformy Azure przy użyciu federacji tożsamości obciążenia, po prostu wybierz pozycję Federacja tożsamości obciążenia (automatyczna) lub (ręcznie) w środowisku tworzenia połączenia z usługą platformy Azure:

Screenshot of resource.

Screenshot of identify federation.

Aby przekonwertować wcześniej utworzone połączenie usługi platformy Azure, wybierz akcję "Konwertuj" po wybraniu połączenia:

Screenshot of convert.

Wszystkie zadania platformy Azure dołączone do usługi Azure Pipelines obsługują teraz ten nowy schemat. Jeśli jednak używasz zadania z witryny Marketplace lub niestandardowego zadania dla dorosłych do wdrożenia na platformie Azure, może to nie obsługiwać jeszcze federacji tożsamości obciążenia. W takich przypadkach prosimy o zaktualizowanie zadania w celu obsługi federacji tożsamości obciążenia w celu zwiększenia bezpieczeństwa. Pełną listę obsługiwanych zadań można znaleźć tutaj.

W tej wersji zapoznawczej obsługujemy federację tożsamości obciążenia tylko dla połączeń usługi platformy Azure. Ten schemat nie działa z żadnymi innymi typami połączeń usług. Aby uzyskać więcej informacji, zobacz nasze dokumenty.

Ten wpis w blogu zawiera więcej szczegółów.

Agentów potoku można zarejestrować przy użyciu identyfikatora Entra firmy Microsoft zamiast pat

Agent potoku obsługuje teraz więcej argumentów, aby użyć jednostki usługi lub użytkownika do zarejestrowania agenta. W ustawieniach zabezpieczeń należy udzielić tożsamości używanej dostępu do puli agentów. Eliminuje to konieczność używania osobistego tokenu dostępu (PAT) na potrzeby jednorazowej konfiguracji agentów.

Rejestrowanie agenta przy użyciu jednostki usługi

Aby użyć jednostki usługi do zarejestrowania agenta potoków w usłudze Azure DevOps Services, podaj następujące argumenty:

--auth 'SP' --clientid 12345678-1234-1234-abcd-1234567890ab --clientsecret --tenantid 12345678-1234-1234-abcd-1234567890ab

Używanie jednostki usługi w rozszerzeniu maszyny wirtualnej agenta

Maszyny wirtualne platformy Azure można uwzględnić w grupach wdrożeń przy użyciu rozszerzenia maszyny wirtualnej. Rozszerzenie maszyny wirtualnej zostało zaktualizowane, aby użyć jednostki usługi zamiast identyfikatora PAT do zarejestrowania agenta:

"settings": {
  "userServicePrincipal": true     
}
"protectedSettings": {
  "clientId": "[parameters('clientId')]"      
  "clientSecret": "[parameters('clientSecret')]"      
  "tenantId": "[parameters('tenantId')]"      
}

Interaktywne rejestrowanie agenta przy użyciu przepływu kodu urządzenia

Aby łatwo ukończyć instalację, możesz użyć przeglądarki internetowej. Po uruchomieniu skryptu konfiguracji agenta wprowadź " AAD" jako typ uwierzytelniania. Skrypt przeprowadzi Cię przez kolejne kroki, w tym miejsce, w którym należy przejść w Internecie i jaki kod należy wprowadzić. Po wprowadzeniu kodu w Internecie wróć do konsoli, aby zakończyć konfigurowanie agenta.

Screenshot of authentication flow.

Interfejsy API REST dla środowisk

Środowisko to kolekcja zasobów, których można kierować przy użyciu wdrożeń z potoku. Środowiska zapewniają historię wdrażania, możliwość śledzenia elementów roboczych i zatwierdzeń oraz mechanizmy kontroli dostępu.

Wiemy, że chcesz programowo tworzyć środowiska, dlatego opublikowaliśmy dokumentację dla ich interfejsu API REST.

Zapobieganie niezamierzonym przebiegom potoku

Obecnie, jeśli potok YAML nie określi sekcji, zostanie uruchomiony pod kątem trigger wszelkich zmian wypchniętych do repozytorium. Może to spowodować zamieszanie, dlaczego potok został uruchomiony i prowadzi do wielu niezamierzonych przebiegów.

Dodaliśmy ustawienie potoków organizacji i na poziomie projektu o nazwie Wyłącz dorozumiany wyzwalacz ci YAML, który umożliwia zmianę tego zachowania. Jeśli brakuje ich sekcji wyzwalacza, możesz nie wyzwalać potoków.

Screenshot of YAML CI trigger.

Domyślnie twórz repozytoria GitHub

Podczas ostatniego przebiegu wprowadziliśmy scentralizowaną kontrolę tworzenia żądania ściągnięcia z rozwidlonych repozytoriów GitHub.

Dzięki temu przebiegowi Securely build pull requests from forked repositories włączamy opcję na poziomie organizacji dla nowych organizacji. Nie ma to wpływu na istniejące organizacje.

Wyłączone przesłonięcia stanu zasad pokrycia kodu na Niepowodzenie, gdy kompilacja kończy się niepowodzeniem

Wcześniej stan zasad pokrycia kodu został zastąpiony wartością "Niepowodzenie", jeśli kompilacja żądania ściągnięcia zakończyła się niepowodzeniem. Była to blokada dla niektórych osób, które miały kompilację jako opcjonalną kontrolę i zasady pokrycia kodu jako wymagane sprawdzenie dla żądania ściągnięcia, co spowodowało zablokowanie żądania ściągnięcia.

Screenshot of PRs blocked.

W przypadku tego przebiegu zasady pokrycia kodu nie zostaną zastąpione wartością "Niepowodzenie", jeśli kompilacja zakończy się niepowodzeniem. Ta funkcja zostanie włączona dla wszystkich klientów.

Screenshot of results after change.

Następne kroki

Uwaga

Te funkcje będą wdrażane w ciągu najbliższych dwóch do trzech tygodni.

Przejdź do usługi Azure DevOps i przyjrzyj się.

Przejdź do usługi Azure DevOps

Jak przekazać opinię

Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.

Make a suggestion

Możesz również uzyskać porady i odpowiedzi na pytania społeczności w witrynie Stack Overflow.