Vylepšená správa zabezpečení
Díky této aktualizaci teď máte možnost povolit nebo zakázat rozšířené zabezpečení pro celý projekt nebo organizaci. Rozšířené zabezpečení můžete také automaticky povolit pro všechna nově vytvořená úložiště nebo projekty.
V Azure Pipelines jsme přidali centralizovaný ovládací prvek pro zlepšení zabezpečení žádostí o přijetí změn vytvořených z forků úložišť GitHubu.
Další informace o těchto funkcích najdete v poznámkách k verzi.
Obecné
Povolení rozšířeného zabezpečení na úrovni projektu a organizace
Odhadovaný počet potvrzení během povolení rozšířeného zabezpečení
Azure Pipelines
Azure Repos
Azure Artifacts
Obecné
Povolení rozšířeného zabezpečení na úrovni projektu a organizace
Rozšířené zabezpečení teď můžete povolit nebo zakázat pro celý projekt nebo organizaci. Ve spojení s novým přidáním počtu potvrzení před povolením vám výběr možnosti Povolit vše na úrovni projektu nebo organizace poskytne odhad, kolik nových aktivních potvrzení se vám může účtovat. Můžete se také rozhodnout automaticky povolit rozšířené zabezpečení pro všechna nově vytvořená úložiště nebo projekty v rámci příslušného projektu nebo organizace. Všechna úložiště povolená prostřednictvím tohoto nastavení budou mít aktivní kontrolu úložiště tajných kódů a ochranu nabízených oznámení.
Povolení na úrovni projektu:
Povolení na úrovni organizace:
Odhadovaný počet potvrzení během povolení rozšířeného zabezpečení
V rámci onboardingu rozšířeného zabezpečení teď můžete zobrazit odhad počtu aktivních potvrzení, které mohlo být přidáno v důsledku povolení rozšířeného zabezpečení pro konkrétní úložiště, projekt nebo organizaci. Tento počet představuje přibližnou aproximaci a může dojít k drobným nesrovnalostem mezi zadaným odhadem a tím, co se vykazuje pro fakturaci po povolení. Tento odhad lze získat také prostřednictvím rozhraní API s další dokumentací vysvětlující tento proces již brzy.
Azure Pipelines
Opakování fáze, kdy vyprší časový limit schválení a kontrol
Když vyprší časový limit schválení a kontrol, fáze, do které patří, se přeskočí. Fáze, které jsou závislé na přeskočené fázi, se také přeskočí.
Teď můžete fázi opakovat, když vyprší časový limit schválení a kontrol. Dříve to bylo možné pouze v případě, že vypršel časový limit schválení.
Role správce pro všechna prostředí
Prostředí v kanálech YAML představují výpočetní prostředek, do kterého nasadíte aplikaci, například cluster AKS nebo sadu virtuálních počítačů. Poskytují bezpečnostní prvky a sledovatelnost vašich nasazení.
Správa prostředí může být poměrně náročná. Je to proto, že při vytvoření prostředí se osoba, která ho vytváří, automaticky stane jediným správcem. Pokud například chcete spravovat schvalování a kontroly všech prostředí centralizovaným způsobem, museli jste požádat každého správce prostředí, aby přidal konkrétního uživatele nebo skupinu jako správce, a pak pomocí rozhraní REST API nakonfigurovat kontroly. Tento přístup je zdlouhavý, náchylný k chybám a při přidání nových prostředí se neškupuje.
V tomto sprintu jsme přidali roli správce na úrovni centra prostředí. Tím se prostředí shoduje s připojeními služeb nebo fondy agentů. Pokud chcete uživateli nebo skupině přiřadit roli správce, musíte už být správcem centra prostředí nebo vlastníkem organizace.
Uživatel s touto rolí správce může spravovat oprávnění, spravovat, zobrazovat a používat libovolné prostředí. To zahrnuje otevření prostředí pro všechny kanály.
Když uživateli udělíte roli správce na úrovni centra prostředí, stanou se správci pro všechna existující prostředí a všechna budoucí prostředí.
Centralizované řízení pro vytváření žádostí o přijetí změn z forkovaných úložišť GitHubu
Pokud vytváříte veřejná úložiště z GitHubu, musíte zvážit svůj postoj k sestavením forku. Forky jsou obzvláště nebezpečné, protože pocházejí mimo vaši organizaci.
Zabezpečení kanálů, které vytvářejí veřejná úložiště GitHubu, můžete zlepšit tím, že si projdete naše doporučení k vytváření úložišť GitHub a ochrany úložiště. Správa mnoha kanálů a zajištění jejich dodržování osvědčených postupů může bohužel vyžadovat značné úsilí.
Abychom zvýšili zabezpečení vašich kanálů, přidali jsme ovládací prvek na úrovni organizace, který definuje, jak kanály sestavují žádosti o přijetí změn z forku úložišť GitHubu. Nové nastavení má název Limit building pull requests from fork repositories GitHub a funguje na úrovni organizace a projektu.
Nastavení na úrovni organizace omezuje nastavení, která můžou mít projekty, a nastavení na úrovni projektu omezuje nastavení, které můžou mít kanály nastavení.
Pojďme se podívat, jak přepínač funguje na úrovni organizace. Nový ovládací prvek je ve výchozím nastavení vypnutý, takže se obecně nevynucuje žádné nastavení.
Když zapnete přepínač, můžete zakázat vytváření žádostí o přijetí změn z forkovaných úložišť GitHubu. To znamená, že po vytvoření takové žádosti o přijetí změn se nespustí žádný kanál.
Když zvolíte možnost Bezpečně sestavovat žádosti o přijetí změn z roz forku úložišť , nemůžou všechny kanály v celé organizaci zpřístupnit tajné kódy pro sestavení žádostí o přijetí změn z forku úložišť, nemůžou mít tato sestavení stejná oprávnění jako normální sestavení a musí se aktivovat komentářem k žádosti o přijetí změn. Projekty se přesto můžou rozhodnout , že kanálům nepovolí vytváření takových žádostí o přijetí změn.
Když zvolíte možnost Přizpůsobit , můžete definovat, jak omezit nastavení kanálu. Můžete například zajistit, aby všechny kanály vyžadovaly komentář k vytvoření žádosti o přijetí změn z roztvoženého úložiště GitHub, pokud žádost o přijetí změn patří nečlenům týmu a přispěvatelům. Můžete se ale rozhodnout, že jim povolíte zpřístupnění tajných kódů pro taková sestavení. Projekty se můžou rozhodnout, že nepovolí kanálům vytvářet takové žádosti o přijetí změn nebo je budou sestavovat bezpečně, nebo budou mít ještě více omezující nastavení, než je určeno na úrovni organizace.
Azure Repos
Nové zásady větve, které uživatelům brání ve schválení vlastních změn
Abychom zlepšili kontrolu nad tím, jaké změny uživatel schvaluje a které splňují přísnější zákonné požadavky nebo požadavky na dodržování předpisů, poskytujeme možnost zabránit uživateli, aby schvaloval své vlastní změny, pokud to není výslovně povoleno.
Uživatel, který má možnost spravovat zásady větve, teď může přepnout nově přidanou možnost Vyžadovat při každé iteraci aspoň jedno schválení v části Při vložení nových změn. Pokud je tato možnost vybraná, vyžaduje se alespoň jedno schválení pro poslední změnu zdrojové větve. Schválení uživatele se nezapočítává do žádné předchozí neschválené iterace nabízené tímto uživatelem. V důsledku toho musí další schválení poslední iterace provést jiný uživatel.
Následující obrázek ukazuje žádost o přijetí změn vytvořenou uživatelem A a další 4 potvrzení (iterace) provedené u této žádosti o přijetí změn uživateli B, C, A znovu a C. Po dokončení druhé iterace (potvrzení provedené uživatelem B) to uživatel C schválil. Tehdy to znamenalo schválení prvního potvrzení uživatele A (při vytvoření žádosti o přijetí změn) a nově zavedené zásady budou úspěšné. Po páté iteraci (poslední potvrzení uživatele C) bylo schválení provedeno uživatelem A. To implikovalo schválení dřívějšího potvrzení provedeného uživatelem C, ale neznamenalo schválení druhého potvrzení provedeného uživatelem A ve čtvrté iteraci. Aby nově zavedené zásady byly úspěšné, musí být neschválená čtyřka iterace schválena buď schválením uživatele B, C, nebo jiným uživatelem, který neprovede žádnou změnu v žádosti o přijetí změn.
Azure Artifacts
Představujeme podporu Azure Artifacts pro Cargo Crates (Public Preview)
S radostí oznamujeme, že Azure Artifacts teď nabízí nativní podporu pro přepravky Cargo. Tato podpora zahrnuje paritu funkcí s ohledem na naše stávající protokoly a navíc crates.io být k dispozici jako nadřazený zdroj. Vývojáři a týmy Rust teď můžou bez problémů využívat, publikovat, spravovat a sdílet své přepravky Cargo, a to vše s využitím robustní infrastruktury Azure a zůstat ve známém prostředí Azure DevOps.
Pro verzi Preview není potřeba žádná registrace. Můžete začít tak, že přejdete k projektu Azure DevOps, vyberete Artifacts (Artefakty) a podle pokynů připojíte projekt Rust k informačnímu kanálu Azure Artifacts.
Další kroky
Poznámka
Tyto funkce se budou zavádět během následujících dvou až tří týdnů.
Přejděte na Azure DevOps a podívejte se.
Jak poskytnout zpětnou vazbu
Rádi bychom se dozvěděli, co si o těchto funkcích myslíte. Pomocí nabídky nápovědy můžete nahlásit problém nebo poskytnout návrh.
Můžete také získat rady a odpovědi na vaše otázky od komunity na Webu Stack Overflow.
Díky,
Silviu Andrica