Azure Pipelines – Aktualizace sprintu 227

Funkce

• Federace identit úloh ve službě Azure Pipelines (Public Preview)

• Agenty kanálu je možné zaregistrovat pomocí MICROSOFT Entra ID místo PAT.

• Rozhraní REST API pro prostředí

• Zabránění nechtěným spuštěním kanálu

• Bezpečné sestavování úložišť GitHubu ve výchozím nastavení

• Zakázané přepsání stavu zásad pokrytí kódu na selhání při selhání sestavení

Federace identit úloh ve službě Azure Pipelines (Public Preview)

Chcete zastavit ukládání tajných kódů a certifikátů v připojeních služeb Azure? Chcete se přestat starat o obměnu těchto tajných kódů, kdykoli vyprší jejich platnost? Nyní oznamujeme verzi Public Preview federace identit úloh pro připojení služeb Azure.Federace identit úloh využívá standardní technologii Open ID Připojení (OIDC) ke zjednodušení ověřování mezi Azure Pipelines a Azure. Místo tajných kódů se k usnadnění tohoto ověřování používá subjekt federace.

V rámci této funkce se připojení služby Azure (ARM) aktualizovalo pomocí jiného schématu pro podporu federace identit úloh. To umožňuje úlohy kanálu, které používají připojení služby Azure k ověření pomocí předmětu federace (sc://<org>/<project>/<service connection name>). Hlavní výhody tohoto schématu pro stávající schémata ověřování jsou následující:

• Zjednodušená správa: Už nemusíte generovat, kopírovat a ukládat tajné kódy z instančních objektů v Azure AD do Azure DevOps. Tajné kódy používané v jiných schématech ověřování připojení služeb Azure (např. instanční objekt) vyprší po určitém období (aktuálně dva roky). Když vyprší jejich platnost, kanály selžou. Musíte znovu vygenerovat nový tajný klíč a aktualizovat připojení služby. Přechod na federaci identit úloh eliminuje nutnost spravovat tyto tajné kódy a zlepšuje celkové prostředí pro vytváření a správu připojení služeb.
• Vylepšené zabezpečení: S federací identit úloh neexistuje žádný trvalý tajný klíč, který by zahrnoval komunikaci mezi Azure Pipelines a Azure. V důsledku toho úlohy spuštěné v úlohách kanálu nemůžou uniknout nebo exfiltrovat tajné kódy, které mají přístup k vašim produkčním prostředím. To se často týká našich zákazníků.

Tyto funkce můžete využít dvěma způsoby:

• Nové schéma federace identit úloh použijte pokaždé, když vytvoříte nové připojení služby Azure. V budoucnu to bude doporučený mechanismus.
• Převeďte stávající připojení služeb Azure (která jsou založená na tajných kódech) na nové schéma. Tento převod můžete provést po jednom připojení. Nejlepší je, že nemusíte upravovat žádné kanály, které používají tato připojení služeb. Po dokončení převodu automaticky použijí nové schéma.

Pokud chcete vytvořit nové připojení služby Azure pomocí federace identit úloh, jednoduše v prostředí pro vytváření připojení ke službě Azure vyberte federaci identit úloh (automatické) nebo (ruční):

Pokud chcete převést dříve vytvořené připojení služby Azure, vyberte po výběru připojení akci Převést:

Všechny úlohy Azure, které jsou součástí Azure Pipelines, teď podporují toto nové schéma. Pokud ale k nasazení do Azure používáte úlohu z Marketplace nebo z domácího vlastního úkolu, možná ještě nepodporuje federaci identit úloh. V těchto případech vás požádáme, abyste aktualizovali úlohu tak, aby podporovala federaci identit úloh, aby se zlepšilo zabezpečení. Úplný seznam podporovaných úkolů najdete tady.

Pro tuto verzi Preview podporujeme federaci identit úloh pouze pro připojení služeb Azure. Toto schéma nefunguje s žádným jiným typem připojení služeb. Další podrobnosti najdete v naší dokumentaci.

Tento blogový příspěvek obsahuje další podrobnosti.

Agenty kanálu je možné zaregistrovat pomocí MICROSOFT Entra ID místo PAT.

Agent kanálu teď podporuje více argumentů pro použití instančního objektu nebo uživatele k registraci agenta. Identitě byste měli udělit přístup k fondu agentů v jeho nastavení zabezpečení. Tím se odebere nutnost používat token PAT (Personal Access Token) k jednorázovému nastavení agentů.

Registrace agenta pomocí instančního objektu

Pokud chcete k registraci agenta Pipelines v Azure DevOps Services použít instanční objekt, zadejte následující argumenty:

--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee

Použití instančního objektu v rozšíření virtuálního počítače agenta

Virtuální počítače Azure je možné zahrnout do skupin nasazení pomocí rozšíření virtuálního počítače. Rozšíření virtuálního počítače bylo aktualizováno tak, aby místo pat používalo instanční objekt k registraci agenta:

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

Interaktivní registrace agenta pomocí toku kódu zařízení

K snadnému dokončení nastavení můžete použít webový prohlížeč. Když spustíte konfigurační skript agenta, jako typ ověřování zadejte AAD . Skript vás provede dalšími kroky, včetně toho, kam na webu přejít a jaký kód se má zadat. Po zadání kódu na webu se vraťte do konzoly a dokončete nastavení agenta.

Rozhraní REST API pro prostředí

Prostředí je kolekce prostředků, na které můžete cílit s nasazeními z kanálu. Prostředí poskytují historii nasazení, sledovatelnost pracovních položek a potvrzení a mechanismy řízení přístupu.

Víme, že chcete prostředí vytvářet prostřednictvím kódu programu, takže jsme publikovali dokumentaci pro jejich rozhraní REST API.

Zabránění nechtěným spuštěním kanálu

V současné době platí, že pokud kanál YAML neurčí trigger oddíl, spustí se pro všechny změny, které se nasdílely do svého úložiště. To může vést k nejasnostem, proč kanál běžel a vést k mnoha nechtěným spuštěním.

Přidali jsme nastavení kanálů na úrovni organizace a projektu s názvem Zakázat implicitní trigger CI YAML, který umožňuje toto chování změnit. Pokud oddíl triggeru chybí, můžete se rozhodnout neaktivovat kanály.

Bezpečné sestavování úložišť GitHub ve výchozím nastavení

V posledním sprintu jsme představili centralizovaný ovládací prvek pro vytváření žádostí o přijetí změn z rozvětvovaných úložišť GitHubu.

V tomto sprintu Securely build pull requests from forked repositories povolujeme možnost na úrovni organizace pro nové organizace. Stávající organizace nejsou ovlivněné.

Zakázané přepsání stavu zásad pokrytí kódu na selhání při selhání sestavení

Dříve se stav zásad pokrytí kódu přepsal na Selhání, pokud se vaše sestavení v žádosti o přijetí změn nezdařilo. To byl blokovač pro některé z vás, kteří měli sestavení jako volitelnou kontrolu a zásady pokrytí kódu jako povinná kontrola žádostí o přijetí změn, což vede k zablokování žádostí o přijetí změn.

V tomto sprintu se zásada pokrytí kódu nepřepíše na selhání, pokud sestavení selže. Tato funkce bude povolená pro všechny zákazníky.

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 na ně.

Přechod na Azure DevOps

Jak poskytnout zpětnou vazbu

Rádi bychom slyšeli, 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 své otázky zodpovězené komunitou ve službě Stack Overflow.