Ulepszone zarządzanie zabezpieczeniami
Dzięki tej aktualizacji masz teraz możliwość włączenia lub wyłączenia zabezpieczeń zaawansowanych dla całego projektu lub organizacji. Możesz również automatycznie włączyć zabezpieczenia zaawansowane dla wszystkich nowo utworzonych repozytoriów lub projektów.
W usłudze Azure Pipelines dodaliśmy scentralizowaną kontrolę w celu zwiększenia bezpieczeństwa żądań ściągnięcia utworzonych z rozwidlonych repozytoriów GitHub.
Zapoznaj się z informacjami o wersji, aby dowiedzieć się więcej o tych funkcjach.
Ogólne
Włączanie na poziomie projektu i organizacji dla zabezpieczeń zaawansowanych
Szacowana liczba zatwierdzaczy podczas włączania zabezpieczeń zaawansowanych
Azure Pipelines
Ponów próbę etapu, gdy zatwierdzenia i wyewidencjonowywanie upłynął limit czasu
Scentralizowana kontrola tworzenia żądania ściągnięcia z rozwidlonych repozytoriów GitHub
Azure Repos
Azure Artifacts
Ogólne
Włączanie na poziomie projektu i organizacji dla zabezpieczeń zaawansowanych
Teraz możesz włączyć lub wyłączyć zabezpieczenia zaawansowane dla całego projektu lub organizacji. W połączeniu z nowym dodatkiem liczby osób zatwierdzających przed włączeniem, wybranie opcji "Włącz wszystko" na poziomie projektu lub organizacji zapewni oszacowanie liczby nowych aktywnych osób zatwierdzających, dla których mogą być naliczane opłaty. Możesz również zdecydować się na automatyczne włączanie zabezpieczeń zaawansowanych dla wszystkich nowo utworzonych repozytoriów lub projektów w ramach odpowiedniego projektu lub organizacji. Wszystkie repozytoria włączone za pomocą tego ustawienia będą miały aktywne skanowanie wpisów tajnych i ochronę wypychaną.
Włączanie na poziomie projektu:
Włączanie na poziomie organizacji:
Szacowana liczba zatwierdzaczy podczas włączania zabezpieczeń zaawansowanych
W ramach środowiska dołączania do usługi Advanced Security można teraz zobaczyć oszacowanie liczby aktywnych osób zatwierdzających, które mogły zostać dodane w wyniku włączenia usługi Advanced Security dla określonego repozytorium, projektu lub organizacji. Ta liczba jest przybliżeniem i może wystąpić niewielkie rozbieżności między podanym oszacowaniem a raportami dotyczącymi rozliczeń po włączeniu. To oszacowanie można również uzyskać za pośrednictwem interfejsu API z dodatkową dokumentacją wyjaśniającą ten proces wkrótce.
Azure Pipelines
Ponów próbę etapu, gdy zatwierdzenia i wyewidencjonowywanie upłynął limit czasu
Po przekroczeniu limitu czasu zatwierdzania i sprawdzania, etap, do którego należy, jest pomijany. Pominięto również etapy, które mają zależność od pominiętego etapu.
Teraz możesz ponowić próbę etapu po zatwierdzeniu i sprawdzeniu limitu czasu. Wcześniej było to możliwe tylko wtedy, gdy upłynął limit czasu zatwierdzenia.
Rola administratora dla wszystkich środowisk
Środowiska w potokach YAML reprezentują zasób obliczeniowy, do którego wdrażasz aplikację, na przykład klaster usługi AKS lub zestaw maszyn wirtualnych. Zapewniają one mechanizmy kontroli zabezpieczeń i możliwość śledzenia wdrożeń.
Zarządzanie środowiskami może być dość trudne. Dzieje się tak dlatego, że po utworzeniu środowiska osoba tworząca ją automatycznie staje się jedynym administratorem. Jeśli na przykład chcesz zarządzać zatwierdzeniami i sprawdzaniem wszystkich środowisk w sposób scentralizowany, musisz poprosić każdego administratora środowiska o dodanie określonego użytkownika lub grupy jako administratora, a następnie skonfigurowanie kontroli przy użyciu interfejsu API REST. To podejście jest żmudne, podatne na błędy i nie jest skalowane po dodaniu nowych środowisk.
W tym przebiegu dodaliśmy rolę administratora na poziomie środowiska-centrum. Dzięki temu środowiska są parzyste z połączeniami usług lub pulami agentów. Aby przypisać rolę Administrator do użytkownika lub grupy, musisz być już administratorem centrum środowisk lub właścicielem organizacji.
Użytkownik z tą rolą administratora może administrować uprawnieniami, zarządzać, wyświetlać i używać dowolnego środowiska. Obejmuje to otwieranie środowisk dla wszystkich potoków.
Po przyznaniu roli administratora użytkownika na poziomie centrum środowisk stają się administratorami dla wszystkich istniejących środowisk i dla wszystkich przyszłych środowisk.
Scentralizowana kontrola tworzenia żądania ściągnięcia z rozwidlonych repozytoriów GitHub
Jeśli tworzysz repozytoria publiczne z usługi GitHub, musisz wziąć pod uwagę swoje stanowisko w przypadku kompilacji rozwidlenia. Rozwidlenia są szczególnie niebezpieczne, ponieważ pochodzą spoza organizacji.
Możesz zwiększyć bezpieczeństwo potoków tworzących repozytoria publiczne usługi GitHub, przeglądając nasze zalecenia dotyczące tworzenia repozytoriów GitHub i ochrony repozytoriów. Niestety zarządzanie wieloma potokami i zapewnienie ich zgodności z najlepszymi rozwiązaniami może wymagać znacznego nakładu pracy.
Aby zwiększyć bezpieczeństwo potoków, dodaliśmy kontrolę na poziomie organizacji w celu zdefiniowania sposobu tworzenia żądania ściągnięcia potoków z rozwidlonych repozytoriów GitHub. Nowe ustawienie ma nazwę Ogranicz tworzenie żądań ściągnięcia z rozwidlonych repozytoriów GitHub i działa na poziomie organizacji i projektu.
Ustawienie na poziomie organizacji ogranicza ustawienia, które mogą mieć projekty, a ustawienie na poziomie projektu ogranicza potoki ustawień.
Przyjrzyjmy się, jak działa przełącznik na poziomie organizacji. Nowa kontrolka jest domyślnie wyłączona, więc żadne ustawienia nie są wymuszane powszechnie.
Po włączeniu przełącznika możesz wyłączyć kompilowanie żądania ściągnięcia z rozwidlonych repozytoriów GitHub. Oznacza to, że po utworzeniu takiego żądania ściągnięcia żaden potok nie zostanie uruchomiony.
Po wybraniu opcji Bezpieczne kompilowanie żądań ściągnięcia z rozwidlonych repozytoriów wszystkie potoki, w całej organizacji, nie mogą udostępniać wpisów tajnych kompilacjom z rozwidlonych repozytoriów, nie mogą sprawić , że te kompilacje będą miały takie same uprawnienia jak zwykłe kompilacje i muszą zostać wyzwolone przez komentarz do żądania ściągnięcia. Projekty nadal mogą nie zezwalać potokom na tworzenie takich reguł ściągnięcia.
Po wybraniu opcji Dostosuj można zdefiniować sposób ograniczania ustawień potoku. Możesz na przykład upewnić się, że wszystkie potoki wymagają komentarza w celu utworzenia żądania ściągnięcia z rozwidlenia repozytorium GitHub, gdy żądanie ściągnięcia należy do członków innych niż członkowie zespołu i nieutwórcy. Można jednak zezwolić na udostępnianie wpisów tajnych takim kompilacjom. Projekty mogą nie zezwalać potokom na tworzenie takich reguł ściągnięcia lub tworzenie ich w bezpieczny sposób lub mieć jeszcze bardziej restrykcyjne ustawienia określone na poziomie organizacji.
Azure Repos
Nowe zasady gałęzi uniemożliwiają użytkownikom zatwierdzanie własnych zmian
Aby poprawić kontrolę nad tym, jakie zmiany użytkownik zatwierdza i spełnia bardziej rygorystyczne wymagania prawne/wymagania dotyczące zgodności, udostępniamy opcję zapobiegania zatwierdzaniu przez użytkownika własnych zmian, chyba że jawnie dozwolone.
Użytkownik z możliwością zarządzania zasadami gałęzi może teraz przełączyć nowo dodaną opcję "Wymagaj co najmniej jednego zatwierdzenia dla każdej iteracji" w obszarze "Po wypchnięciu nowych zmian". Po wybraniu tej opcji wymagane jest co najmniej jedno zatwierdzenie dla ostatniej zmiany gałęzi źródłowej. Zatwierdzenie użytkownika nie jest liczone względem poprzedniej niezatwierdzonej iteracji wypchniętej przez tego użytkownika. W związku z tym wymagane jest dodatkowe zatwierdzenie ostatniej iteracji przez innego użytkownika.
Na poniższej ilustracji przedstawiono żądanie ściągnięcia utworzone przez użytkownika A i dodatkowe 4 zatwierdzenia (iteracji) wykonane do tego żądania ściągnięcia przez użytkowników B, C, A i C. Po zakończeniu drugiej iteracji (zatwierdzenie wykonane przez użytkownika B) użytkownik C zatwierdził to. W tym czasie sugerowało to zatwierdzenie pierwszego zatwierdzenia użytkownika A (po utworzeniu żądania ściągnięcia), a nowo wprowadzone zasady zostaną wykonane pomyślnie. Po piątej iteracji (ostatnie zatwierdzenie użytkownika C) zatwierdzenie zostało wykonane przez użytkownika A. To sugerowane zatwierdzenie dla wcześniejszego zatwierdzenia wykonanego przez użytkownika C, ale nie oznaczało zatwierdzenia drugiego zatwierdzenia wykonanego przez użytkownika A w czwartej iteracji. Aby nowo wprowadzone zasady zakończyły się powodzeniem, niezatwierdzona iteracja cztery muszą zostać zatwierdzone przez zatwierdzenie od użytkownika B, C lub innego użytkownika, który nie wprowadził żadnych zmian w żądaniu ściągnięcia.
Azure Artifacts
Wprowadzenie do obsługi usługi Azure Artifacts dla skrzyni ładunków (publiczna wersja zapoznawcza)
Z przyjemnością ogłaszamy, że usługa Azure Artifacts oferuje teraz natywną obsługę stawek cargo. Ta obsługa obejmuje równoważność funkcji w odniesieniu do naszych istniejących protokołów, a także crates.io dostępne jako nadrzędne źródło. Deweloperzy i zespoły rust mogą teraz bezproblemowo wykorzystywać, publikować i udostępniać skrzynie ładunkowe oraz zarządzać nimi, jednocześnie korzystając z niezawodnej infrastruktury platformy Azure i pozostając w znanym środowisku usługi Azure DevOps.
W wersji zapoznawczej nie jest wymagana rejestracja; Możesz rozpocząć, przechodząc do projektu usługi Azure DevOps, wybierając pozycję Artifacts i postępując zgodnie z instrukcjami, aby połączyć projekt Rust z kanałem informacyjnym usługi Azure Artifacts.
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 spójrz.
Jak przekazać opinię
Chcielibyśmy usłyszeć, co myślisz o tych funkcjach. Użyj menu Pomocy, aby zgłosić problem lub podać sugestię.
Możesz również uzyskać porady i pytania, na które odpowiada społeczność w witrynie Stack Overflow.
Dzięki,
Silviu Andrica