Perlindungan repositori

Layanan Azure DevOps | Azure DevOps Server 2022 | Azure DevOps Server 2020

Kode sumber, file YAML alur, dan skrip &alat yang diperlukan semuanya disimpan dalam repositori kontrol versi. Izin dan kebijakan cabang harus digunakan untuk memastikan perubahan pada kode dan alur aman. Anda juga dapat menambahkan izin alur dan pemeriksaan ke repositori.

Selain itu, Anda harus meninjau kontrol akses default untuk repositori.

Karena desain Git, perlindungan di tingkat cabang hanya akan membawa Anda sejauh ini. Pengguna dengan akses push ke repositori biasanya dapat membuat cabang baru. Jika Anda menggunakan proyek sumber terbuka GitHub, siapa pun dengan akun GitHub dapat membuat fork repositori Anda dan mengusulkan kontribusi kembali. Karena alur dikaitkan dengan repositori dan bukan dengan cabang tertentu, Anda harus menganggap kode dan file YAML tidak tepercaya.

Fork

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. Untuk melindungi produk Anda dari kode berkontribusi, pertimbangkan rekomendasi berikut.

Catatan

Rekomendasi berikut berlaku terutama untuk membangun repositori publik dari GitHub.

Jangan berikan rahasia ke build fork

Secara default, alur Anda dikonfigurasi untuk membangun fork, tetapi rahasia dan sumber daya yang dilindungi tidak tersedia untuk pekerjaan di alur tersebut secara default. Jangan matikan perlindungan terakhir ini.

Screenshot of fork build protection UI.

Catatan

Saat Anda mengaktifkan build fork untuk mengakses rahasia, Azure Pipelines secara default membatasi token akses yang digunakan untuk build fork. Ini memiliki akses yang lebih terbatas untuk membuka sumber daya daripada token akses normal. Untuk memberi build fork izin yang sama dengan build reguler, aktifkan build Buat fork memiliki izin yang sama dengan pengaturan build reguler.

Screenshot of fork build protection UI in Azure DevOps Server 2020 and lower.

Catatan

Bahkan jika Anda mengaktifkan build fork untuk mengakses rahasia, Azure Pipelines membatasi token akses yang digunakan untuk build fork. Ini memiliki akses yang lebih terbatas untuk membuka sumber daya daripada token akses normal. Anda tidak dapat menonaktifkan perlindungan ini.

Pertimbangkan untuk memicu build fork secara manual

Anda dapat menonaktifkan build fork otomatis dan sebaliknya menggunakan komentar permintaan pull sebagai cara untuk membangun kontribusi ini secara manual. Pengaturan ini akan memberi Anda kesempatan untuk meninjau kode sebelum memicu build.

Menggunakan agen yang dihosting Microsoft untuk build fork

Jangan menjalankan build dari fork pada agen yang dihost sendiri. Dengan demikian, Anda secara efektif menyediakan jalur ke organisasi eksternal untuk menjalankan kode luar pada mesin di dalam jaringan perusahaan Anda. Gunakan agen yang dihosting Microsoft jika memungkinkan. Untuk agen yang dihost sendiri, gunakan beberapa bentuk isolasi jaringan dan pastikan agen tidak mempertahankan statusnya di antara pekerjaan.

Meninjau perubahan kode

Sebelum Anda menjalankan alur pada permintaan pull fork, tinjau perubahan yang diusulkan dengan cermat, dan pastikan Anda nyaman menjalankannya.

Versi alur YAML yang akan Anda jalankan adalah versi dari permintaan pull. Dengan demikian, beri perhatian khusus pada perubahan pada kode YAML dan kode yang berjalan ketika alur berjalan, seperti skrip baris perintah atau pengujian unit.

Batasan cakupan token GitHub

Saat Anda membuat permintaan pull fork GitHub, Azure Pipelines memastikan alur tidak dapat mengubah konten repositori GitHub apa pun. Pembatasan ini hanya berlaku jika Anda menggunakan aplikasi Azure Pipelines GitHub untuk berintegrasi dengan GitHub. Jika Anda menggunakan bentuk integrasi GitHub lainnya, misalnya, aplikasi OAuth, pembatasan tidak diberlakukan.

Cabang pengguna

Pengguna di organisasi Anda dengan izin yang tepat dapat membuat cabang baru yang berisi kode baru atau yang diperbarui. Kode tersebut dapat berjalan melalui alur yang sama dengan cabang yang dilindungi Anda. Selanjutnya, jika file YAML di cabang baru diubah, maka YAML yang diperbarui akan digunakan untuk menjalankan alur. Meskipun desain ini memungkinkan fleksibilitas dan layanan mandiri yang besar, tidak semua perubahan aman (baik dibuat dengan berbahaya atau tidak).

Jika alur Anda menggunakan kode sumber atau ditentukan di Azure Repos, Anda harus sepenuhnya memahami model izin Azure Repos. Secara khusus, pengguna dengan izin Buat Cabang di tingkat repositori dapat memperkenalkan kode ke repositori bahkan jika pengguna tersebut tidak memiliki izin Kontribusi .

Langkah berikutnya

Selanjutnya, pelajari tentang lebih banyak perlindungan yang ditawarkan oleh pemeriksaan pada sumber daya yang dilindungi.