Manajemen keamanan yang ditingkatkan
Dengan pembaruan ini, Anda sekarang memiliki opsi untuk mengaktifkan atau menonaktifkan Advanced Security untuk seluruh proyek atau organisasi Anda. Anda juga dapat mengaktifkan Advanced Security secara otomatis untuk repositori atau proyek yang baru dibuat.
Di Azure Pipelines, kami menambahkan kontrol terpusat untuk meningkatkan keamanan permintaan pull yang dibangun dari repositori GitHub fork.
Lihat catatan rilis untuk mempelajari selengkapnya tentang fitur-fitur ini.
Umum
Pengaktifan tingkat proyek dan organisasi untuk Keamanan Tingkat Lanjut
Estimasi jumlah komitter selama pengaktifan Keamanan Tingkat Lanjut
Azure Pipelines
Mencoba kembali tahap saat persetujuan dan waktu pemeriksaan habis
Kontrol terpusat untuk membangun PR dari reposItori GitHub bercabangan
Azure Repos
Azure Artifacts
Umum
Pengaktifan tingkat proyek dan organisasi untuk Keamanan Tingkat Lanjut
Sekarang Anda dapat mengaktifkan atau menonaktifkan Keamanan Tingkat Lanjut untuk seluruh proyek atau organisasi Anda. Bersama dengan penambahan baru menampilkan jumlah penerapan sebelum pengaktifan, memilih "Aktifkan semua" di tingkat proyek atau organisasi akan memberi Anda perkiraan berapa banyak committer aktif baru yang mungkin ditagih. Anda juga dapat memilih untuk mengaktifkan Keamanan Tingkat Lanjut secara otomatis untuk repositori atau proyek yang baru dibuat di bawah proyek atau organisasi Anda masing-masing. Setiap repositori yang diaktifkan melalui pengaturan ini akan memiliki pemindaian repositori rahasia dan perlindungan push aktif.
Pengaktifan tingkat proyek:
Pengaktifan tingkat organisasi:
Estimasi jumlah komitter selama pengaktifan Keamanan Tingkat Lanjut
Sebagai bagian dari pengalaman onboarding Keamanan Tingkat Lanjut , Anda sekarang dapat melihat perkiraan berapa banyak komitter aktif yang mungkin telah ditambahkan sebagai akibat dari mengaktifkan Keamanan Tingkat Lanjut untuk repositori, proyek, atau organisasi tertentu. Jumlah ini adalah perkiraan dan Anda mungkin melihat sedikit perbedaan antara perkiraan yang disediakan dan apa yang dilaporkan untuk penagihan setelah pengaktifan. Perkiraan ini juga dapat diperoleh melalui API dengan dokumentasi tambahan yang menjelaskan proses ini akan segera hadir.
Azure Pipelines
Mencoba kembali tahap saat persetujuan dan waktu pemeriksaan habis
Ketika persetujuan dan waktu pemeriksaan habis, tahap tempat mereka berada dilewati. Tahapan yang memiliki dependensi pada tahap yang dilewati juga dilewati.
Sekarang Anda dapat mencoba kembali tahap saat persetujuan dan memeriksa waktu habis. Sebelumnya, ini hanya dimungkinkan ketika persetujuan habis.
Peran administrator untuk semua Lingkungan
Lingkungan dalam alur YAML mewakili sumber daya komputasi tempat Anda menyebarkan aplikasi, misalnya kluster AKS atau sekumpulan VM. Mereka memberi Anda kontrol keamanan dan keterlacakan untuk penyebaran Anda.
Mengelola lingkungan bisa sangat menantang. Ini karena, ketika lingkungan dibuat, orang yang membuatnya secara otomatis menjadi administrator utama. Misalnya, jika Anda ingin mengelola persetujuan dan pemeriksaan semua lingkungan dengan cara terpusat, Anda harus meminta setiap administrator lingkungan untuk menambahkan pengguna atau grup tertentu sebagai administrator, lalu menggunakan REST API untuk mengonfigurasi pemeriksaan. Pendekatan ini melelahkan, rawan kesalahan, dan tidak menskalakan saat lingkungan baru ditambahkan.
Dengan sprint ini, kami menambahkan peran Administrator di tingkat hub lingkungan. Ini membawa lingkungan hingga setingkat dengan koneksi layanan atau kumpulan agen. Untuk menetapkan peran Administrator ke pengguna atau grup, Anda harus sudah menjadi administrator hub lingkungan atau pemilik organisasi.
Pengguna dengan peran Administrator ini dapat mengelola izin, mengelola, melihat, dan menggunakan lingkungan apa pun. Ini termasuk membuka lingkungan ke semua alur.
Saat Anda memberikan peran Administrator pengguna di tingkat hub lingkungan, mereka menjadi administrator untuk semua lingkungan yang ada dan untuk lingkungan di masa mendatang.
Kontrol terpusat untuk membangun PR dari reposItori GitHub bercabangan
Jika Anda membangun repositori publik dari GitHub, Anda harus mempertimbangkan sikap Anda pada build fork. Fork sangat berbahaya karena mereka berasal dari luar organisasi Anda.
Anda dapat meningkatkan keamanan alur yang membangun repositori publik GitHub dengan meninjau rekomendasi kami tentang cara Membangun repositori GitHub dan perlindungan Repositori. Sayangnya, mengelola banyak alur dan memastikan kepatuhan mereka terhadap praktik terbaik dapat membutuhkan sejumlah besar upaya.
Untuk meningkatkan keamanan alur Anda, kami menambahkan kontrol tingkat organisasi untuk menentukan bagaimana alur membangun PR dari repositori GitHub bercabangan. Pengaturan baru diberi nama Batasi permintaan pull bangunan dari repositori GitHub fork dan bekerja di tingkat organisasi dan proyek.
Pengaturan tingkat organisasi membatasi proyek pengaturan dapat memiliki, dan pengaturan tingkat proyek membatasi alur pengaturan yang dapat dimiliki.
Mari kita lihat cara kerja tombol di tingkat organisasi. Kontrol baru nonaktif secara default, jadi tidak ada pengaturan yang diberlakukan secara universal.
Saat mengaktifkan tombol, Anda dapat memilih untuk menonaktifkan pembuatan PR dari repositori GitHub fork. Ini berarti, tidak ada alur yang akan berjalan ketika PR seperti itu dibuat.
Saat Anda memilih opsi Buat permintaan pull dengan aman dari repositori fork , semua alur, seluruh organisasi, tidak dapat membuat rahasia tersedia untuk build PR dari repositori bercabangan, tidak dapat membuat build ini memiliki izin yang sama dengan build normal, dan harus dipicu oleh komentar PR. Proyek masih dapat memutuskan untuk tidak mengizinkan alur untuk membangun PR tersebut.
Saat Anda memilih opsi Kustomisasi , Anda dapat menentukan cara membatasi pengaturan alur. Misalnya, Anda dapat memastikan bahwa semua alur memerlukan komentar untuk membangun PR dari repositori GitHub fork, ketika PR milik anggota non-tim dan non-kontributor. Namun, Anda dapat memilih untuk memungkinkan mereka membuat rahasia tersedia untuk build tersebut. Proyek dapat memutuskan untuk tidak mengizinkan alur untuk membangun PR tersebut, atau membangunnya dengan aman, atau memiliki pengaturan yang lebih ketat yang ditentukan di tingkat organisasi.
Azure Repos
"Kebijakan cabang" baru mencegah pengguna menyetujui perubahan mereka sendiri
Untuk meningkatkan kontrol sekeliling perubahan yang disetujui pengguna dan mencocokkan persyaratan peraturan/kepatuhan yang lebih ketat, kami menyediakan opsi untuk mencegah pengguna menyetujui perubahannya sendiri kecuali diizinkan secara eksplisit.
Pengguna dengan kemampuan untuk mengelola kebijakan cabang sekarang dapat beralih opsi yang baru ditambahkan "Memerlukan setidaknya satu persetujuan pada setiap iterasi" di bawah "Ketika perubahan baru didorong". Ketika opsi ini dipilih, maka setidaknya satu suara persetujuan untuk perubahan cabang sumber terakhir diperlukan. Persetujuan pengguna tidak dihitung terhadap perulangan sebelumnya yang tidak disetujui yang didorong oleh pengguna tersebut. Akibatnya, persetujuan tambahan pada iterasi terakhir diperlukan untuk dilakukan oleh pengguna lain.
Gambar berikut menunjukkan permintaan pull yang dibuat oleh pengguna A dan 4 penerapan tambahan (iterasi) yang dibuat untuk permintaan pull tersebut oleh pengguna B, C, A lagi dan C. Setelah iterasi kedua (penerapan yang dilakukan oleh pengguna B) dilakukan, pengguna C menyetujuinya. Pada saat itu, ini menyiratkan persetujuan penerapan pertama pengguna A (ketika permintaan pull dibuat) dan kebijakan yang baru diperkenalkan akan berhasil. Setelah iterasi kelima (penerapan terakhir pengguna C), persetujuan dilakukan oleh pengguna A. Ini menyiratkan persetujuan untuk penerapan sebelumnya yang dilakukan oleh pengguna C, tetapi tidak menyiratkan persetujuan untuk penerapan kedua yang dilakukan oleh pengguna A dalam iterasi keempat. Agar kebijakan yang baru diperkenalkan berhasil, perulangan yang tidak disetujui empat harus disetujui baik dengan persetujuan dari pengguna B, C atau pengguna lain yang belum membuat perubahan apa pun pada permintaan pull.
Azure Artifacts
Memperkenalkan dukungan Artefak Azure untuk Cargo Crates (pratinjau publik)
Kami sangat senang mengumumkan bahwa Azure Artifacts sekarang menawarkan dukungan asli untuk peti Kargo. Dukungan ini mencakup paritas fitur sehubungan dengan protokol kami yang ada, selain crates.io tersedia sebagai sumber hulu. Pengembang dan tim karat sekarang dapat menggunakan, menerbitkan, mengelola, dan berbagi peti Kargo mereka dengan mulus, semua saat menggunakan infrastruktur Azure yang kuat dan tetap berada di lingkungan Azure DevOps yang akrab.
Tidak diperlukan pendaftaran untuk pratinjau; Anda dapat memulai dengan menavigasi ke proyek Azure DevOps Anda, memilih Artefak, dan mengikuti instruksi untuk menyambungkan proyek Rust Anda ke umpan Azure Artifacts Anda.
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 Anda yang dijawab oleh komunitas di Stack Overflow.
Terima kasih,
Silviu Andrica