Federasi identitas beban kerja untuk pratinjau publik Azure Pipelines
Kami sangat senang mengumumkan bahwa federasi identitas Beban Kerja untuk Azure Pipelines sekarang dalam pratinjau publik! Koneksi layanan Azure (ARM) telah diperbarui dengan skema tambahan untuk mendukung federasi identitas beban kerja.
Lihat catatan rilis untuk mempelajari cara mendaftar pratinjau publik.
Azure Boards
Azure Pipelines
Federasi identitas beban kerja di Azure Pipelines (pratinjau publik)
Agen alur dapat didaftarkan menggunakan ID Microsoft Entra alih-alih PAT
Penimpaan status kebijakan cakupan kode yang dinonaktifkan menjadi Gagal saat build gagal
Azure Repos
Azure Boards
Batas untuk jalur area dan perulangan
Batasan berperan penting dalam menjaga kesehatan dan efisiensi layanan global yang besar. Dalam sprint ini, kami memperkenalkan batas keras 10.000 per proyek untuk jalur perulangan dan area. Kunjungi halaman Pelacakan kerja, proses, dan batas proyek untuk mempelajari selengkapnya tentang batas yang berbeda dalam layanan.
Azure Pipelines
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 memutar rahasia ini setiap kali kedaluwarsa? Kami sekarang mengumumkan pratinjau publik Federasi Identitas Beban Kerja untuk koneksi layanan Azure.Federasi identitas beban kerja menggunakan teknologi standar industri, Open ID Koneksi (OIDC), untuk menyederhanakan autentikasi antara Azure Pipelines dan Azure. Alih-alih rahasia, subyek federation digunakan untuk memfasilitasi otentikasi 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 alur tidak dapat membocorkan atau menyelundupkan 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 yang ditanam di rumah untuk disebarkan ke Azure, tugas tersebut mungkin belum mendukung federasi identitas 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 alur dapat didaftarkan menggunakan ID Microsoft Entra alih-alih PAT
Agen Alur sekarang mendukung lebih banyak argumen untuk menggunakan Perwakilan Layanan atau pengguna untuk mendaftarkan agen. Anda harus memberikan identitas yang digunakan akses ke kumpulan agen dalam pengaturan keamanannya. Ini menghapus kebutuhan untuk menggunakan Token Akses Pribadi (PAT) untuk penyiapan agen satu kali.
Mendaftarkan agen menggunakan Perwakilan Layanan
Untuk menggunakan Perwakilan Layanan untuk mendaftarkan agen Alur 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 alur. Lingkungan memberi Anda riwayat penyebaran, keterlacakan untuk item dan penerapan kerja, dan mekanisme kontrol akses.
Kami tahu Anda ingin membuat lingkungan secara terprogram, jadi kami menerbitkan dokumentasi untuk REST API mereka.
Mencegah eksekusi alur yang tidak diinginkan
Hari ini, jika alur YAML Anda tidak menentukan trigger bagian, alur tersebut berjalan untuk setiap perubahan yang didorong ke repositorinya. Ini dapat menciptakan kebingungan mengapa alur berjalan dan menyebabkan 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 dapat memilih untuk tidak memicu alur jika bagian pemicunya hilang.
Membangun repositori GitHub dengan aman secara default
Sprint terakhir, kami memperkenalkan kontrol terpusat untuk membangun PR dari repositori GitHub bercabangan.
Dengan sprint ini, kami mengaktifkan Securely build pull requests from forked repositories opsi di tingkat organisasi, untuk organisasi baru. Organisasi yang ada tidak terpengaruh.
Penimpaan status kebijakan cakupan kode yang dinonaktifkan menjadi Gagal saat build gagal
Sebelumnya dalam, status kebijakan cakupan kode ditimpa menjadi 'Gagal' jika build Anda di PR gagal. Ini adalah pemblokir untuk beberapa dari Anda yang memiliki build sebagai pemeriksaan opsional dan kebijakan cakupan kode sebagai pemeriksaan yang diperlukan untuk PR yang mengakibatkan PR diblokir.
Dengan sprint ini, kebijakan cakupan kode tidak akan ditimpa menjadi 'Gagal' jika build gagal. Fitur ini akan diaktifkan untuk semua pelanggan.
Azure Repos
Dukungan filter tanpa blob dan tanpa pohon
Azure DevOps sekarang mendukung dua pemfilteran tambahan saat mengkloning/mengambil. Ini adalah: --filter=blob:none Dan --filter=tree:0 Opsi pertama (klon blobless) paling baik digunakan untuk pengembangan reguler sementara opsi kedua (klon tanpa pohon) lebih cocok untuk kasus-kasus di mana Anda membuang klon setelah, misalnya menjalankan build.
Langkah berikutnya
Catatan
Fitur-fitur ini akan diluncurkan selama dua hingga tiga minggu ke depan.
Buka Azure DevOps dan lihat.
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.
Terima kasih,
Silviu Andrica