Fokozott biztonságkezelés
Ezzel a frissítéssel mostantól engedélyezheti vagy letilthatja az Advanced Security szolgáltatást a teljes projekt vagy szervezet számára. Az Advanced Security automatikusan engedélyezhető az újonnan létrehozott adattárakhoz vagy projektekhez is.
Az Azure Pipelinesban egy központosított vezérlőt adtunk hozzá az elágaztatott GitHub-adattárakból létrehozott lekéréses kérelmek biztonságának javítása érdekében.
Ezekről a funkciókról a kibocsátási megjegyzésekben olvashat bővebben.
Általános kérdések
Projekt- és szervezetszintű engedélyezés az Advanced Securityhez
A véglegesítés becsült száma az Advanced Security engedélyezése során
Azure Pipelines
Próbálkozzon újra egy fázissal, amikor a jóváhagyások és az időtúllépést ellenőrzik
Központosított vezérlés a PRS-ek elágaztatott GitHub-adattárakból történő kiépítéséhez
Azure Repos
Azure Artifacts
Általános kérdések
Projekt- és szervezetszintű engedélyezés az Advanced Securityhez
Mostantól engedélyezheti vagy letilthatja az Advanced Security szolgáltatást a teljes projekthez vagy szervezethez. A véglegesítők számának az engedélyezés előtti új hozzáadásával együtt a projekt vagy a szervezet szintjén az "Összes engedélyezése" lehetőség kiválasztásával megbecsülheti, hogy hány új aktív véglegesítőt számlázhat ki. Dönthet úgy is, hogy automatikusan engedélyezi az Advanced Securityt az újonnan létrehozott adattárakhoz vagy projektekhez a megfelelő projekt vagy szervezet alatt. Az ezen a beállításon keresztül engedélyezett adattárakban aktív lesz a titkos adattár beolvasása és a leküldéses védelem.
Projektszintű engedélyezés:
Szervezeti szintű engedélyezés:
A véglegesítés becsült száma az Advanced Security engedélyezése során
Az Advanced Security bevezetési élményének részeként most már láthatja, hogy hány aktív véglegesítő lett hozzáadva egy adott adattár, projekt vagy szervezet Speciális biztonság engedélyezése miatt. Ez a szám egy közelítés, és kis eltéréseket tapasztalhat a megadott becslés és a számlázáshoz az engedélyezés után jelentett adatok között. Ez a becslés az API-val is beszerezhető, és további dokumentációval ismerteti ezt a folyamatot.
Azure Pipelines
Próbálkozzon újra egy fázissal, amikor a jóváhagyások és az időtúllépést ellenőrzik
Ha a jóváhagyások és az ellenőrzések túllépik az időkorlátot, a program kihagyja a szakaszt, amelyhez tartoznak. A kihagyott fázistól függő szakaszok is ki lesznek hagyva.
Most újrapróbálhat egy szakaszt, amikor jóváhagyja és ellenőrzi az időtúllépést. Korábban ez csak akkor volt lehetséges, ha egy jóváhagyás túllépte az időkorlátot.
Rendszergazdai szerepkör az összes környezethez
A YAML-folyamatok környezetei olyan számítási erőforrást jelölnek, amelyre az alkalmazást telepíti, például egy AKS-fürtöt vagy virtuális gépek készletét. Biztonsági vezérlőket és nyomon követhetőséget biztosítanak az üzemelő példányokhoz.
A környezetek kezelése meglehetősen kihívást jelenthet. Ennek az az oka, hogy a környezet létrehozásakor az azt létrehozó személy automatikusan az egyedüli rendszergazda lesz. Ha például az összes környezet jóváhagyását és ellenőrzését központosított módon szeretné kezelni, minden környezeti rendszergazdát fel kellett kérnie, hogy adjon hozzá egy adott felhasználót vagy csoportot rendszergazdaként, majd a REST API használatával konfigurálja az ellenőrzéseket. Ez a megközelítés fárasztó, hibalehetőséget jelent, és nem méretezhető új környezetek hozzáadásakor.
Ezzel a sprinttel rendszergazdai szerepkört adtunk hozzá a környezetek-központ szintjén. Így a környezetek a szolgáltatáskapcsolatokkal vagy az ügynökkészletekkel egyeznek. Ha a Rendszergazda szerepkört egy felhasználóhoz vagy csoporthoz szeretné hozzárendelni, akkor már környezet-központ rendszergazdájának vagy szervezet-tulajdonosának kell lennie.
A rendszergazdai szerepkörrel rendelkező felhasználók bármilyen környezetet felügyelhetnek, kezelhetnek, tekinthetnek meg és használhatnak. Ez magában foglalja a környezetek megnyitását az összes folyamat számára.
Ha felhasználói rendszergazdai szerepkört ad meg a környezetek központi szintjén, az összes meglévő környezet és a jövőbeli környezetek rendszergazdájává válik.
Központosított vezérlés a PRS-ek elágaztatott GitHub-adattárakból történő kiépítéséhez
Ha nyilvános adattárakat hoz létre a GitHubról, figyelembe kell vennie az elágazásokra vonatkozó álláspontját. Az elágazások különösen veszélyesek, mivel a szervezeten kívülről származnak.
A GitHub nyilvános adattárait összeállító folyamatok biztonságának javításához tekintse át a GitHub-adattárak és adattárak védelmének összeállítására vonatkozó javaslatainkat. Sajnos számos folyamat kezelése és az ajánlott eljárásoknak való megfelelésük biztosítása jelentős erőfeszítést igényelhet.
A folyamatok biztonságának növelése érdekében szervezeti szintű vezérlőt adtunk hozzá annak meghatározásához, hogy a folyamatok hogyan hozhatnak létre PRS-eket az elágaztatott GitHub-adattárakból. Az új beállítás neve Limit building pull requests from forked GitHub repositories and works at organization and project level.
A szervezeti szintű beállítás korlátozza a projektek által megadható beállításokat, a projektszintű beállítás pedig korlátozza a beállítási folyamatokat.
Nézzük meg, hogyan működik a kapcsoló szervezeti szinten. Az új vezérlő alapértelmezés szerint ki van kapcsolva, így nincs általánosan kikényszerített beállítás.
Amikor bekapcsolja a kapcsolót, letilthatja az elágaztatott GitHub-adattárakból származó PRS-ek készítését. Ez azt jelenti, hogy egy ilyen lekéréses kérelem létrehozásakor nem fut folyamat.
Ha az elágazott adattárakból származó biztonságos buildelési lekéréses kérelmeket választja, minden folyamat, a szervezet egészében , nem tudja elérhetővé tenni a titkos kódokat az elágazott adattárakból származó PRs-buildek számára, nem teheti meg, hogy ezek a buildek ugyanolyan engedélyekkel rendelkezzenek, mint a normál buildek, és egy PR-megjegyzésnek kell aktiválnia őket. A projektek továbbra is dönthetnek úgy, hogy nem engedélyezik a folyamatok számára az ilyen PRS-ek kiépítését.
Ha a Testreszabás lehetőséget választja , megadhatja, hogyan korlátozhatja a folyamatbeállításokat. Gondoskodhat például arról, hogy minden folyamat megjegyzést igényeljen egy leágaztatott GitHub-adattárból történő lekérés létrehozásához, ha a lekérés nem csapattagok és nem közreműködők tulajdona. Azonban engedélyezheti számukra, hogy titkos kulcsokat tegyenek elérhetővé az ilyen buildekhez. A projektek dönthetnek úgy, hogy nem engedélyezik a folyamatok számára az ilyen PRS-ek készítését, vagy biztonságosan építik fel őket, vagy még szigorúbb beállításokkal rendelkeznek, amelyek a szervezet szintjén vannak megadva.
Azure Repos
Az új "ágszabályzat" megakadályozza, hogy a felhasználók jóváhagyják a saját módosításaikat
A felhasználó által jóváhagyott és szigorúbb jogszabályi/megfelelőségi követelményeknek megfelelő módosítások szabályozásának javítása érdekében lehetőséget biztosítunk arra, hogy a felhasználó ne hagyja jóvá a saját módosításait, hacsak nem engedélyezi kifejezetten.
A fiókszabályzatok kezelésével rendelkező felhasználók mostantól átválthatnak az újonnan hozzáadott "Legalább egy jóváhagyás megkövetelése minden iterációban" lehetőségre az "Új módosítások leküldésekor" területen. Ha ezt a lehetőséget választja, akkor legalább egy jóváhagyásra van szükség az utolsó forráság-módosításra. A felhasználó jóváhagyása nem számít bele a felhasználó által leküldett korábbi nem jóváhagyott iterációkba. Ennek eredményeképpen egy másik felhasználónak további jóváhagyásra van szüksége az utolsó iterációhoz.
Az alábbi képen az A felhasználó által létrehozott lekéréses kérelem látható, valamint további 4 véglegesítés (iteráció) a B, C, A és C felhasználók által erre a lekéréses kérelemre. A második iteráció (a B felhasználó véglegesítése) után a C felhasználó jóváhagyta ezt. Ekkor az A felhasználó első véglegesítésének jóváhagyását feltételezte (a lekéréses kérelem létrehozásakor), és az újonnan bevezetett szabályzat sikeres lesz. Az ötödik iteráció (a C felhasználó utolsó véglegesítése) után a jóváhagyást az A felhasználó végezte el. Ez a C felhasználó által végzett korábbi véglegesítés vélelmezett jóváhagyása, de nem utalt az A felhasználó által a negyedik iterációban végrehajtott második véglegesítés jóváhagyására. Ahhoz, hogy az újonnan bevezetett szabályzat sikeres legyen, a nem jóváhagyott négyes iterációt vagy a B, C felhasználó vagy bármely más olyan felhasználó jóváhagyásával kell jóváhagyni, aki nem módosította a lekéréses kérelmet.
Azure Artifacts
A Cargo Crates Azure Artifacts-támogatásának bemutatása (nyilvános előzetes verzió)
Örömmel jelentjük be, hogy az Azure Artifacts natív támogatást nyújt a Cargo-ládákhoz. Ez a támogatás magában foglalja a szolgáltatás paritását a meglévő protokollok tekintetében, amellett, hogy crates.io elérhető felsőbb rétegbeli forrásként. A Rust fejlesztői és csapatai mostantól zökkenőmentesen használhatják, tehetik közzé, kezelhetik és oszthatják meg Cargo-ládáikat, miközben az Azure robusztus infrastruktúráját használják, és a jól ismert Azure DevOps-környezetben maradnak.
Az előzetes verzióhoz nincs szükség regisztrációra; Első lépésként navigálhat az Azure DevOps-projekthez, kiválaszthatja az Összetevők lehetőséget, és az utasításokat követve csatlakoztathatja Rust-projektjéhez az Azure Artifacts-csatornát.
Következő lépések
Megjegyzés
Ezek a funkciók a következő két-három hétben jelennek meg.
Lépjen az Azure DevOpsba, és nézze meg.
Visszajelzés küldése
Szeretnénk hallani, mit gondol ezekről a funkciókról. A súgómenüvel jelentheti a problémát, vagy javaslatot adhat meg.
Tanácsokat és kérdéseket is kaphat a közösségtől a Stack Overflow-on.
Köszönettel:
Silviu Andrica