Azure Pipelines - Pembaruan Sprint 227

Features

• Federasi identitas beban kerja di Azure Pipelines (pratinjau publik)

• Agen pipeline dapat didaftarkan menggunakan ID Microsoft Entra sebagai pengganti PAT

• REST API untuk Lingkungan

• Mencegah Eksekusi Pipeline yang Tidak Diinginkan

• Membangun Repositori GitHub Secara Aman dari Awal

• Penimpaan status kebijakan cakupan kode yang dinonaktifkan menjadi Gagal saat build gagal

Federasi identitas beban kerja di Azure Pipelines (pratinjau publik)

Apakah Anda ingin berhenti menyimpan rahasia dan sertifikat di koneksi layanan Azure? Ingin berhenti khawatir tentang mengelola rahasia ini setiap kali habis masa berlakunya? Kami sekarang mengumumkan pratinjau publik Federasi Identitas Beban Kerja untuk koneksi layanan Azure. Federasi identitas beban kerja menggunakan teknologi standar industri, Open ID Connect (OIDC), untuk menyederhanakan autentikasi antara Azure Pipelines dan Azure. Alih-alih rahasia, subyek federasi digunakan untuk memfasilitasi autentikasi ini.

Sebagai bagian dari fitur ini, koneksi layanan Azure (ARM) telah diperbarui dengan skema lain untuk mendukung federasi identitas Beban Kerja. Ini memungkinkan tugas Alur yang menggunakan koneksi layanan Azure untuk mengautentikasi menggunakan subjek federasi (sc://<org>/<project>/<service connection name>). Manfaat utama menggunakan skema ini atas skema autentikasi yang ada adalah sebagai berikut:

• Manajemen yang disederhanakan: Anda tidak membuat, menyalin, dan menyimpan rahasia dari perwakilan layanan di Azure AD ke Azure DevOps lagi. Rahasia yang digunakan dalam skema autentikasi lain dari koneksi layanan Azure (misalnya, perwakilan layanan) kedaluwarsa setelah periode tertentu (dua tahun saat ini). Ketika kedaluwarsa, alur gagal. Anda harus meregenerasi rahasia baru dan memperbarui koneksi layanan. Beralih ke federasi identitas beban kerja menghilangkan kebutuhan untuk mengelola rahasia ini dan meningkatkan pengalaman keseluruhan dalam membuat dan mengelola koneksi layanan.
• Keamanan yang ditingkatkan: Dengan federasi identitas beban kerja, tidak ada rahasia persisten yang terlibat dalam komunikasi antara Azure Pipelines dan Azure. Akibatnya, tugas yang berjalan dalam pekerjaan pipeline tidak dapat membocorkan atau mengungkap rahasia yang memiliki akses ke lingkungan produksi Anda. Hal ini sering menjadi perhatian pelanggan kami.

Anda dapat memanfaatkan fitur-fitur ini dengan dua cara:

• Gunakan skema federasi identitas beban kerja baru setiap kali Anda membuat koneksi layanan Azure baru. Ke depan, ini akan menjadi mekanisme yang direkomendasikan.
• Konversikan koneksi layanan Azure Anda yang sudah ada (yang didasarkan pada rahasia) ke skema baru. Anda dapat melakukan konversi ini satu koneksi pada satu waktu. Yang terbaik dari semuanya, Anda tidak perlu memodifikasi salah satu alur yang menggunakan koneksi layanan tersebut. Mereka akan secara otomatis menerapkan skema baru setelah Anda menyelesaikan konversi.

Untuk membuat koneksi layanan Azure baru menggunakan federasi identitas beban kerja, cukup pilih Federasi identitas beban kerja (otomatis) atau (manual) dalam pengalaman pembuatan koneksi layanan Azure:

Untuk mengonversi koneksi layanan Azure yang dibuat sebelumnya, pilih tindakan "Konversi" setelah memilih koneksi:

Semua tugas Azure yang disertakan dengan Azure Pipelines sekarang mendukung skema baru ini. Namun, jika Anda menggunakan tugas dari Marketplace atau tugas kustom internal untuk disebarkan ke Azure, tugas tersebut mungkin belum mendukung federasi identitas untuk beban kerja. Dalam kasus ini, kami meminta Anda memperbarui tugas Anda untuk mendukung federasi identitas beban kerja untuk meningkatkan keamanan. Daftar lengkap tugas yang didukung dapat ditemukan di sini.

Untuk pratinjau ini, kami mendukung federasi identitas beban kerja hanya untuk koneksi layanan Azure. Skema ini tidak berfungsi dengan jenis koneksi layanan lainnya. Lihat dokumen kami untuk detail selengkapnya.

Posting blog ini berisi detail selengkapnya.

Agen pipeline dapat didaftarkan menggunakan Microsoft Entra ID alih-alih PAT

Agen Pipeline sekarang mendukung lebih banyak argumen untuk menggunakan Service Principal atau pengguna untuk mendaftarkan agen. Anda harus memberikan identitas yang digunakan akses ke kumpulan agen dalam pengaturan keamanannya. Ini menghilangkan kebutuhan untuk menggunakan Token Akses Pribadi (PAT) dalam pengaturan agen yang dilakukan satu kali.

Mendaftarkan agen menggunakan Service Principal

Untuk menggunakan Service Principal untuk mendaftarkan agen Pipelines dengan Azure DevOps Services, berikan argumen berikut:

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

Menggunakan Perwakilan Layanan di ekstensi VM Agen

Azure VM dapat disertakan dalam Grup Penyebaran menggunakan Ekstensi VM. Ekstensi VM telah diperbarui untuk menggunakan Perwakilan Layanan alih-alih PAT untuk mendaftarkan agen:

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

Mendaftarkan agen secara interaktif menggunakan alur kode perangkat

Anda dapat menggunakan browser web untuk menyelesaikan penyiapan dengan mudah. Saat Anda menjalankan skrip konfigurasi agen, masukkan "AAD" untuk jenis autentikasi. Skrip akan memandu Anda melalui langkah-langkah berikutnya, termasuk ke mana harus masuk ke web dan kode apa yang akan dimasukkan. Setelah Anda memasukkan kode di web, kembali ke konsol untuk menyelesaikan penyiapan agen.

REST API untuk Lingkungan

Lingkungan adalah kumpulan sumber daya yang dapat Anda targetkan dengan penyebaran dari pipeline. Lingkungan memberi Anda riwayat penyebaran, keterlacakan untuk item kerja dan komit, serta mekanisme kontrol akses.

Kami tahu Anda ingin membuat lingkungan secara terprogram, jadi kami menerbitkan dokumentasi untuk REST API mereka.

Mencegah jalannya alur yang tidak diinginkan

Jika alur YAML Anda tidak menentukan bagian , alur tersebut berjalan untuk setiap perubahan yang dikirim ke repositori. Ini dapat menciptakan kebingungan mengenai mengapa sebuah pipeline dijalankan dan mengakibatkan banyak eksekusi yang tidak diinginkan.

Kami menambahkan pengaturan Alur tingkat organisasi dan proyek bernama Nonaktifkan pemicu YAML CI tersirat yang memungkinkan Anda mengubah perilaku ini. Anda bisa memilih untuk tidak mengaktifkan alur jika bagian pemicunya hilang.

Membangun repositori GitHub dengan aman secara default

Pada sprint terakhir, kami memperkenalkan kontrol terpusat untuk membangun PR dari repositori GitHub yang di-fork.

Dengan sprint ini, kami mengaktifkan opsi Securely build pull requests from forked repositories pada tingkat organisasi, untuk organisasi baru. Organisasi yang ada tidak terpengaruh.

Penonaktifan penimpaan status kebijakan cakupan kode menjadi Gagal ketika build mengalami kegagalan

Sebelumnya, status kebijakan cakupan kode ditimpa menjadi 'Gagal' jika build Anda di PR gagal. Ini adalah kendala bagi sebagian dari Anda yang memiliki build sebagai pengecekan opsional dan kebijakan cakupan kode sebagai pengecekan wajib untuk permintaan tarik, sehingga mengakibatkan permintaan tarik tersebut terblokir.

Dalam sprint ini, kebijakan cakupan kode tidak akan secara otomatis diubah menjadi 'Gagal' jika build mengalami kegagalan. Fitur ini akan diaktifkan untuk semua pelanggan.

Langkah selanjutnya

Nota

Fitur-fitur ini akan diluncurkan selama dua hingga tiga minggu ke depan.

Buka Azure DevOps dan lihat.

Pergi ke Azure DevOps

Cara memberikan umpan balik

Kami akan senang mendengar apa yang Anda pikirkan tentang fitur-fitur ini. Gunakan menu bantuan untuk melaporkan masalah atau memberikan saran.

Anda juga bisa mendapatkan saran dan pertanyaan yang dijawab oleh komunitas di Stack Overflow.