Számítási feladatok identitásának összevonása az Azure Pipelines nyilvános előzetes verziójához
Örömmel jelentjük be, hogy az Azure Pipelines számításifeladat-identitás-összevonása nyilvános előzetes verzióban érhető el! Az Azure (ARM) szolgáltatáskapcsolatai egy további sémával frissültek a számítási feladatok identitás-összevonásának támogatása érdekében.
A kibocsátási megjegyzésekből megtudhatja, hogyan regisztrálhat a nyilvános előzetes verzióra.
Azure Boards
Azure Pipelines
Számítási feladatok identitásának összevonása az Azure Pipelinesban (nyilvános előzetes verzió)
A folyamatügynökök pat helyett Microsoft Entra-azonosítóval regisztrálhatók
GitHub-adattárak létrehozása alapértelmezés szerint biztonságosan
Azure Repos
Azure Boards
A terület- és iterációs útvonalak korlátai
A korlátok fontos szerepet játszanak egy nagy, globális szolgáltatás egészségének és hatékonyságának fenntartásában. Ebben a futamban projektenként 10 000 kemény korlátot vezetünk be mind a terület, mind az iterációs útvonalak esetében. A Szolgáltatás különböző korlátaival kapcsolatos további információkért látogasson el a Work tracking, a process and project limits (Munkakövetés, folyamat és projektkorlátok ) oldalra.
Azure Pipelines
Számítási feladatok identitásának összevonása az Azure Pipelinesban (nyilvános előzetes verzió)
Leállítja a titkos kulcsok és tanúsítványok azure-szolgáltatáskapcsolatokban való tárolását? Nem kell aggódnia amiatt, hogy a titkos kulcsok elévülnek, amikor lejárnak? Most bejelentjük a Workload Identity Federation nyilvános előzetes verzióját az Azure-szolgáltatáskapcsolatokhoz.A számítási feladatok identitásának összevonása egy iparági szabványnak megfelelő, Open ID Csatlakozás (OIDC) technológiával egyszerűsíti az Azure Pipelines és az Azure közötti hitelesítést. Instead of secrets, a federation subject is used to facilitate this authentication.
Ennek a funkciónak a részeként az Azure (ARM) szolgáltatáskapcsolata egy másik sémával frissült, amely támogatja a számítási feladatok identitásának összevonását. Ez lehetővé teszi, hogy az Azure-szolgáltatáskapcsolatot használó folyamatfeladatok összevonási tárgy (sc://<org>/<project>/<service connection name>) használatával hitelesítsék magukat. A séma meglévő hitelesítési sémákkal való használatának fő előnyei a következők:
- Egyszerűsített felügyelet: Többé nem hozhat létre, másolhat és tárolhat titkos kulcsokat az Azure AD szolgáltatásnevekből az Azure DevOpsba. Az Azure-szolgáltatáskapcsolatok más hitelesítési sémáiban (például szolgáltatásnév) használt titkos kódok egy bizonyos időszak (jelenleg két év) után lejárnak. Ha lejárnak, a folyamatok sikertelenek lesznek. Új titkos kulcsot kell létrehoznia, és frissítenie kell a szolgáltatáskapcsolatot. A számítási feladatok identitás-összevonására való váltás szükségtelenné teszi ezeket a titkos kulcsokat, és javítja a szolgáltatáskapcsolatok létrehozásának és kezelésének általános élményét.
- Továbbfejlesztett biztonság: A számítási feladatok identitásának összevonásával nincs állandó titkos kód az Azure Pipelines és az Azure közötti kommunikációban. Ennek eredményeképpen a folyamatfeladatokban futó tevékenységek nem szivároghatnak ki és nem tudnak kiszivárogtatni olyan titkos kulcsokat, amelyek hozzáférnek az éles környezetekhez. Ez gyakran aggodalomra ad okot ügyfeleink számára.
Ezeket a funkciókat kétféleképpen használhatja ki:
- Új Azure-szolgáltatáskapcsolat létrehozásakor használja az új számítási feladat identitás-összevonási sémát . Az előrehaladtával ez lesz az ajánlott mechanizmus.
- Konvertálja a meglévő Azure-szolgáltatáskapcsolatokat (amelyek titkos kódokon alapulnak) az új sémára. Ezt az átalakítást egyszerre egy kapcsolattal hajthatja végre. A legjobb az egészben, hogy nem kell módosítania azokat a folyamatokat, amelyek ezeket a szolgáltatáskapcsolatokat használják. Az átalakítás befejezése után a rendszer automatikusan alkalmazza az új sémát.
Ha új Azure-szolgáltatáskapcsolatot szeretne létrehozni a számítási feladatok identitásának összevonásával, egyszerűen válassza ki a számítási feladatok identitás-összevonását (automatikus) vagy (manuális) az Azure-szolgáltatáskapcsolat-létrehozási felületen:
Egy korábban létrehozott Azure-szolgáltatáskapcsolat konvertálásához válassza a "Konvertálás" műveletet a kapcsolat kiválasztása után:
Az Azure Pipelines részét képező összes Azure-feladat mostantól támogatja ezt az új sémát. Ha azonban a Marketplace-ről származó feladatot vagy egy saját készítésű egyéni feladatot használ az Azure-ban való üzembe helyezéshez, akkor előfordulhat, hogy még nem támogatja a számítási feladatok identitásának összevonását. Ezekben az esetekben kérjük, hogy frissítse a feladatot, hogy támogassa a számítási feladatok identitásának összevonását a biztonság javítása érdekében. A támogatott tevékenységek teljes listája itt található.
Ebben az előzetes verzióban csak az Azure-szolgáltatáskapcsolatokhoz támogatjuk a számítási feladatok identitásának összevonását. Ez a séma nem működik más típusú szolgáltatáskapcsolatokkal. További részletekért tekintse meg a dokumentációnkat.
Ez a blogbejegyzés további részleteket tartalmaz.
A folyamatügynökök pat helyett Microsoft Entra-azonosítóval regisztrálhatók
A Folyamatügynök mostantól több argumentumot is támogat egy szolgáltatásnév vagy egy felhasználó használatával egy ügynök regisztrálásához. A biztonsági beállításokban hozzáférést kell adnia az ügynökkészlethez használt identitásnak. Így nem szükséges személyes hozzáférési jogkivonatot (PAT) használni az ügynökök egyszeri beállításához.
Ügynök regisztrálása szolgáltatásnév használatával
Ha szolgáltatásnévvel szeretne regisztrálni egy Pipelines-ügynököt az Azure DevOps Services szolgáltatásban, adja meg a következő argumentumokat:
--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee
Szolgáltatásnév használata az Ügynök virtuálisgép-bővítményben
Az Azure-beli virtuális gépek egy virtuálisgép-bővítmény használatával az üzembehelyezési csoportokba is belefoglalhatók. A virtuálisgép-bővítmény úgy lett frissítve, hogy az ügynök regisztrálásához pat helyett szolgáltatásnevet használjon:
"settings": {
"userServicePrincipal": true
}
"protectedSettings": {
"clientId": "[parameters('clientId')]"
"clientSecret": "[parameters('clientSecret')]"
"tenantId": "[parameters('tenantId')]"
}
Ügynök interaktív regisztrálása eszközkód-folyamat használatával
A beállítás egyszerű befejezéséhez webböngészőt használhat. Az ügynökkonfigurációs szkript futtatásakor adja meg az "AAD" értéket a hitelesítés típusához. A szkript végigvezeti a következő lépéseken, beleértve a weben való navigálás helyét és a beírandó kódot. Miután megadta a kódot a weben, térjen vissza a konzolra az ügynök beállításának befejezéséhez.
REST API-k környezetekhez
A környezet olyan erőforrások gyűjteménye, amelyeket egy folyamat központi telepítéseivel célozhat meg. A környezetek biztosítják az üzembe helyezési előzményeket, a munkaelemek és véglegesítések nyomon követhetőségét, valamint a hozzáférés-vezérlési mechanizmusokat.
Tudjuk, hogy programozott módon szeretne környezeteket létrehozni, ezért közzétettük a REST API dokumentációját.
Nem tervezett folyamatfuttatások megakadályozása
Ma, ha a YAML-folyamat nem ad meg szakaszt trigger , az a tárházba leküldött módosításokért fut. Ez zavart okozhat abban, hogy egy folyamat miért futott, és miért vezetett sok nem tervezett futtatáshoz.
Hozzáadtunk egy szervezeti és projektszintű folyamatbeállítást a Implicit YAML CI-eseményindító letiltása nevű beállításhoz, amely lehetővé teszi ennek a viselkedésnek a módosítását. Dönthet úgy, hogy nem aktiválja a folyamatokat, ha hiányzik az eseményindító szakasza.
GitHub-adattárak létrehozása alapértelmezés szerint biztonságosan
Az utolsó sprintben bevezettünk egy központosított vezérlőt a PRS-ek elágaztatott GitHub-adattárakból való létrehozásához.
Ezzel a futammal szervezeti szinten engedélyezzük a Securely build pull requests from forked repositories lehetőséget az új szervezetek számára. A meglévő szervezetekre nincs hatással.
A kódlefedettségi szabályzat állapotának letiltott felülbírálása sikertelen lesz a buildelés sikertelensége esetén
Korábban a kódlefedettségi szabályzat állapota felül lett bírálva a "Sikertelen" állapotra, ha a lekéréses kérelemben való buildelés sikertelen volt. Ez egy letiltó volt néhányuk számára, akik a buildet opcionális ellenőrzésként, a kódlefedettségi szabályzatot pedig kötelezően ellenőrizték a PRs-ek esetében, ami a PRS-ek letiltását eredményezte.
Ezzel a sprinttel a kódlefedettségi szabályzat nem lesz felülírva "Sikertelen" értékkel, ha a build meghiúsul. Ez a funkció minden ügyfél számára engedélyezve lesz.
Azure Repos
Blobless és fa nélküli szűrőtámogatás
Az Azure DevOps mostantól két további szűrést is támogat klónozás/beolvasás közben. Ezek a következők: --filter=blob:none És --filter=tree:0 Az első lehetőség (blob nélküli klón) a rendszeres fejlesztéshez ajánlott, míg a második lehetőség (fa nélküli klón) jobban illik azokhoz az esetekhez, amikor elveti a klónt, például buildet futtat.
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.
Tanácsokat és kérdéseket is kaphat a közösség által a Stack Overflow-on.
Köszönettel:
Silviu Andrica