Mengakses repositori, artefak, dan sumber daya lainnya
Layanan Azure DevOps | Azure DevOps Server 2022 - Azure DevOps Server 2019
Pada run-time, setiap pekerjaan dalam alur dapat mengakses sumber daya lain di Azure DevOps. Misalnya, pekerjaan dapat:
- Lihat kode sumber dari repositori Git
- Menambahkan tag ke repositori
- Mengakses umpan di Artefak Azure
- Mengunggah log dari agen ke layanan
- Mengunggah hasil pengujian dan artefak lain dari agen ke layanan
- Memperbarui item kerja
Azure Pipelines menggunakan token akses pekerjaan untuk melakukan tugas ini. Token akses pekerjaan adalah token keamanan yang dihasilkan secara dinamis oleh Azure Pipelines untuk setiap pekerjaan pada waktu proses. Agen tempat pekerjaan dijalankan menggunakan token akses pekerjaan untuk mengakses sumber daya ini di Azure DevOps. Anda dapat mengontrol sumber daya yang dapat diakses alur dengan mengontrol bagaimana izin diberikan ke token akses pekerjaan.
Izin token berasal dari (a) cakupan otorisasi pekerjaan dan (b) izin yang Anda tetapkan pada akun layanan build kumpulan atau proyek.
Cakupan otorisasi pekerjaan
Anda dapat mengatur cakupan otorisasi pekerjaan menjadi koleksi atau proyek. Dengan mengatur cakupan ke koleksi, Anda memilih untuk mengizinkan alur mengakses semua repositori dalam koleksi atau organisasi. Dengan mengatur cakupan ke proyek, Anda memilih untuk membatasi akses hanya ke repositori yang berada dalam proyek yang sama dengan alur.
Cakupan otorisasi pekerjaan dapat diatur untuk seluruh organisasi Azure DevOps atau untuk proyek tertentu.
Catatan
Di Azure DevOps Server 2020, Batasi cakupan otorisasi pekerjaan ke proyek saat ini hanya berlaku untuk alur YAML dan alur build klasik. Ini tidak berlaku untuk alur rilis klasik. Alur rilis klasik selalu berjalan dengan cakupan pengumpulan proyek.
Untuk mengatur cakupan otorisasi pekerjaan untuk organisasi:
- Navigasi ke halaman pengaturan organisasi Anda di antarmuka pengguna Azure DevOps.
- Pilih Pengaturan di bawah Alur.
- Aktifkan Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk membatasi cakupan proyek. Ini adalah pengaturan yang direkomendasikan, karena meningkatkan keamanan untuk alur Anda.
Untuk mengatur cakupan otorisasi pekerjaan untuk proyek tertentu:
- Navigasi ke halaman pengaturan proyek Anda di antarmuka pengguna Azure DevOps.
- Pilih Pengaturan di bawah Alur.
- Aktifkan Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk membatasi cakupan proyek. Ini adalah pengaturan yang direkomendasikan, karena meningkatkan keamanan untuk alur Anda.
- Untuk mengatur cakupan otorisasi pekerjaan di tingkat organisasi untuk semua proyek, pilih Pengaturan organisasi>Alur> Pengaturan.
- Untuk mengatur cakupan otorisasi pekerjaan untuk proyek tertentu, pilih Alur> pengaturan>Proyek Pengaturan.
Aktifkan satu atau beberapa pengaturan berikut. Mengaktifkan pengaturan ini disarankan, karena meningkatkan keamanan untuk alur Anda.
- Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis - Pengaturan ini berlaku untuk alur YAML dan alur build klasik, dan tidak berlaku untuk alur rilis klasik.
- Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur rilis - Pengaturan ini hanya berlaku untuk alur rilis klasik.
Catatan
Jika cakupan diatur ke proyek di tingkat organisasi, Anda tidak dapat mengubah cakupan di setiap proyek.
Penting
Jika cakupan tidak dibatasi pada tingkat organisasi atau tingkat proyek, maka setiap pekerjaan di alur YAML Anda mendapatkan token akses pekerjaan terlingkup koleksi. Dengan kata lain, alur Anda memiliki akses ke repositori apa pun di proyek organisasi Anda. Jika lawan dapat memperoleh akses ke satu alur dalam satu proyek, mereka akan dapat mendapatkan akses ke repositori apa pun di organisasi Anda. Inilah sebabnya mengapa, disarankan agar Anda membatasi cakupan pada tingkat tertinggi (pengaturan organisasi) untuk berisi serangan ke satu proyek.
Jika Anda menggunakan Azure DevOps Server 2019, maka semua pekerjaan YAML berjalan dengan cakupan otorisasi pekerjaan yang diatur ke koleksi. Dengan kata lain, pekerjaan ini memiliki akses ke semua repositori dalam koleksi proyek Anda. Anda tidak dapat mengubah ini di Azure DevOps Server 2019.
Alur YAML tidak tersedia di TFS.
Catatan
Jika alur Anda berada dalam proyek publik, maka cakupan otorisasi pekerjaan secara otomatis dibatasi untuk memproyeksikan apa pun yang Anda konfigurasi dalam pengaturan apa pun. Pekerjaan dalam proyek publik dapat mengakses sumber daya seperti membangun artefak atau hasil pengujian hanya dalam proyek dan bukan dari proyek lain dari organisasi.
Membatasi cakupan otorisasi pekerjaan ke repositori Azure DevOps yang direferensikan
Selain pengaturan cakupan otorisasi pekerjaan yang dijelaskan di bagian sebelumnya, Azure Pipelines menyediakan cakupan otorisasi pekerjaan Batasi ke pengaturan repositori Azure DevOps yang direferensikan.
Alur dapat mengakses repositori Azure DevOps apa pun dalam proyek yang diotorisasi kecuali batasi cakupan otorisasi pekerjaan ke repositori Azure DevOps yang direferensikan diaktifkan. Dengan opsi ini diaktifkan, Anda dapat mengurangi cakupan akses untuk semua alur menjadi hanya repositori Azure DevOps yang secara eksplisit direferensikan oleh checkout
langkah atau uses
pernyataan dalam pekerjaan alur yang menggunakan repositori tersebut.
Untuk informasi selengkapnya, lihat Repositori Azure Repos Git - Membatasi cakupan otorisasi pekerjaan ke repositori Azure DevOps yang direferensikan.
Melindungi akses ke repositori di alur YAML
Selain pengaturan cakupan otorisasi pekerjaan yang dijelaskan di bagian sebelumnya, Azure Pipelines menyediakan akses Lindungi ke repositori dalam pengaturan alur YAML.
Alur dapat mengakses repositori Azure DevOps apa pun dalam proyek yang diotorisasi kecuali melindungi akses ke repositori di alur YAML diaktifkan. Dengan opsi ini diaktifkan, Anda dapat mengurangi cakupan akses untuk semua alur menjadi hanya repositori Azure DevOps yang secara eksplisit direferensikan oleh checkout
langkah atau uses
pernyataan dalam pekerjaan alur yang menggunakan repositori tersebut.
Untuk informasi selengkapnya, lihat Repositori Azure Repos Git - Melindungi akses ke repositori di alur YAML.
Penting
Lindungi akses ke repositori di alur YAML diaktifkan secara default untuk organisasi dan proyek baru yang dibuat setelah Mei 2020.
Identitas build terlingkup
Azure DevOps menggunakan dua identitas bawaan untuk menjalankan alur.
- Identitas cakupan koleksi, yang memiliki akses ke semua proyek dalam koleksi (atau organisasi untuk Layanan Azure DevOps)
- Identitas cakupan proyek, yang memiliki akses ke satu proyek
Identitas ini dialokasikan izin yang diperlukan untuk melakukan aktivitas waktu eksekusi build/rilis saat memanggil kembali ke sistem Azure DevOps. Ada izin default bawaan, dan Anda juga dapat mengelola izin Anda sendiri sesuai kebutuhan.
Nama identitas cakupan koleksi memiliki format berikut:
Project Collection Build Service ({OrgName})
- Misalnya, jika nama organisasi adalah
fabrikam-tailspin
, akun ini memiliki namaProject Collection Build Service (fabrikam-tailspin)
.
Nama identitas cakupan proyek memiliki format berikut:
{Project Name} Build Service ({Org Name})
- Misalnya, jika nama organisasi adalah
fabrikam-tailspin
dan nama proyek adalahSpaceGameWeb
, akun ini memiliki namaSpaceGameWeb Build Service (fabrikam-tailspin)
.
Secara default, identitas cakupan koleksi digunakan, kecuali dikonfigurasi sebaliknya seperti yang dijelaskan di bagian Cakupan otorisasi Pekerjaan sebelumnya.
Mengelola izin akun layanan build
Salah satu hasil pengaturan akses cakupan proyek mungkin adalah bahwa identitas cakupan proyek mungkin tidak memiliki izin ke sumber daya yang dimiliki oleh cakupan koleksi.
Anda mungkin ingin mengubah izin token akses pekerjaan dalam skenario seperti berikut ini:
- Anda ingin alur Anda mengakses umpan yang berada di proyek yang berbeda.
- Anda ingin alur Anda dibatasi untuk mengubah kode di repositori.
- Anda ingin alur Anda dibatasi untuk membuat item kerja.
Untuk memperbarui izin token akses pekerjaan:
Pertama, tentukan cakupan otorisasi pekerjaan untuk alur Anda. Lihat bagian di atas untuk memahami cakupan otorisasi pekerjaan. Jika cakupan otorisasi pekerjaan adalah koleksi, maka akun layanan build yang sesuai untuk mengelola izin adalah Project Collection Build Service (your-collection-name). Jika cakupan otorisasi pekerjaan adalah proyek, akun layanan build untuk mengelola izin adalah Layanan Build nama proyek Anda (nama koleksi Anda).
Untuk membatasi atau memberikan akses tambahan ke Project Collection Build Service (your-collection-name):
- Pilih Kelola keamanan di menu luapan di halaman Alur.
- Di bawah Pengguna, pilih Project Collection Build Service (your-collection-name).
- Buat perubahan apa pun pada izin terkait alur untuk akun ini.
- Navigasi ke pengaturan organisasi untuk organisasi Azure DevOps Anda (atau pengaturan pengumpulan untuk koleksi proyek Anda).
- Pilih Izin di bawah Keamanan.
- Di bawah tab Pengguna, cari Project Collection Build Service (your-collection-name).
- Buat perubahan apa pun pada izin terkait non-alur untuk akun ini.
- Karena Project Collection Build Service (nama koleksi Anda) adalah pengguna di organisasi atau koleksi Anda, Anda dapat menambahkan akun ini secara eksplisit ke sumber daya apa pun - misalnya, ke umpan di Azure Artifacts.
Untuk membatasi atau memberikan akses tambahan ke Layanan Build nama proyek Anda (nama koleksi Anda):
- Akun layanan build tempat Anda dapat mengelola izin hanya akan dibuat setelah Anda menjalankan alur sekali. Pastikan Anda sudah menjalankan alur sekali.
- Pilih Kelola keamanan di menu luapan di halaman Alur.
- Di bawah Pengguna, pilih Layanan Build nama proyek Anda (nama koleksi Anda).
- Buat perubahan apa pun pada izin terkait alur untuk akun ini.
- Navigasi ke pengaturan organisasi untuk organisasi Azure DevOps Anda (atau pengaturan pengumpulan untuk koleksi proyek Anda).
- Pilih Izin di bawah Keamanan.
- Di bawah tab Pengguna, cari layanan build Nama proyek Anda (nama koleksi Anda).
- Buat perubahan apa pun pada izin terkait non-alur untuk akun ini.
- Karena Layanan Build nama proyek Anda (nama koleksi Anda) adalah pengguna di organisasi atau koleksi Anda, Anda dapat menambahkan akun ini secara eksplisit ke sumber daya apa pun - misalnya, ke umpan di Azure Artifacts.
Mengonfigurasi izin untuk proyek untuk mengakses proyek lain dalam koleksi proyek yang sama
Dalam contoh ini, fabrikam-tailspin/SpaceGameWeb
identitas build dengan cakupan proyek diberikan izin untuk mengakses fabrikam-tailspin/FabrikamFiber
proyek.
Dalam proyek FabrikamFiber, navigasikan ke Pengaturan proyek, Izin.
Buat Grup baru bernama Proyek Eksternal dan tambahkan akun Layanan Build SpaceGameWeb.
Pilih Pengguna, mulai ketik nama SpaceGameWeb, dan pilih akun SpaceGameWeb Build Service . Jika Awalnya Anda tidak melihat hasil pencarian, pilih Perluas pencarian.
Berikan izin Tampilkan informasi tingkat proyek untuk pengguna tersebut.
Contoh - Mengonfigurasi izin untuk mengakses repositori lain dalam koleksi proyek yang sama
Dalam contoh ini, fabrikam-tailspin/SpaceGameWeb
identitas build yang dicakup proyek diberikan izin untuk mengakses FabrikamFiber
repositori dalam fabrikam-tailspin/FabrikamFiber
proyek.
Ikuti langkah-langkah untuk memberikan
SpaceGameWeb
izin identitas build cakupan proyek untuk mengaksesFabrikamFiber
proyek.Dalam proyek FabrikamFiber, navigasikan ke Pengaturan proyek, Repositori, FabrikamFiber.
+ Pilih ikon, mulai ketik nama SpaceGameWeb, dan pilih akun SpaceGameWeb Build Service.
Mulai ketik nama SpaceGameWeb, dan pilih akun SpaceGameWeb Build Service .
Berikan izin Baca untuk pengguna tersebut.
Contoh - Mengonfigurasi izin untuk mengakses sumber daya lain dalam koleksi proyek yang sama
Dalam contoh ini, fabrikam-tailspin/SpaceGameWeb
identitas build dengan cakupan proyek diberikan izin untuk mengakses sumber daya lain dalam fabrikam-tailspin/FabrikamFiber
proyek.
Ikuti langkah-langkah untuk memberikan
SpaceGameWeb
izin identitas build cakupan proyek untuk mengaksesFabrikamFiber
proyek.Konfigurasikan izin yang diinginkan untuk pengguna tersebut.
FAQ
Bagaimana cara menentukan cakupan otorisasi pekerjaan alur YAML saya?
- Jika proyek Anda adalah proyek publik, cakupan otorisasi pekerjaan selalu diproyeksikan terlepas dari pengaturan lainnya.
Semua alur YAML di Azure DevOps Server 2019 berjalan di bawah cakupan otorisasi pekerjaan pengumpulan .
- Periksa pengaturan Alur di bawah pengaturan Organisasi Azure DevOps Anda:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini diaktifkan, maka cakupannya adalah proyek.
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini tidak diaktifkan, periksa pengaturan Alur di bawah pengaturan Proyek Anda di Azure DevOps:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini diaktifkan, maka cakupannya adalah proyek.
- Jika tidak, cakupannya adalah koleksi.
- Jika alur berada dalam proyek privat, periksa pengaturan Alur di bawah pengaturan Organisasi Azure DevOps Anda:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis diaktifkan, maka cakupannya adalah proyek.
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis tidak diaktifkan, periksa pengaturan Alur di bawah pengaturan Proyek Anda di Azure DevOps:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis diaktifkan, maka cakupannya adalah proyek.
- Jika tidak, cakupannya adalah koleksi.
Bagaimana cara menentukan cakupan otorisasi pekerjaan alur build klasik saya?
- Jika alur berada dalam proyek publik, maka cakupan otorisasi pekerjaan adalah proyek terlepas dari pengaturan lain.
- Buka editor untuk alur dan navigasikan ke tab Opsi .
- Jika cakupan otorisasi pekerjaan Build adalah Proyek saat ini, maka cakupannya adalah proyek.
- Jika tidak, cakupannya adalah koleksi.
- Periksa pengaturan Alur di bawah pengaturan Organisasi Azure DevOps Anda:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini diaktifkan, maka cakupannya adalah proyek.
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini tidak diaktifkan, periksa pengaturan Alur di bawah pengaturan Proyek Anda di Azure DevOps:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini diaktifkan, maka cakupannya adalah proyek.
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini tidak diaktifkan, buka editor untuk alur, dan navigasikan ke tab Opsi .
- Jika cakupan otorisasi pekerjaan Build adalah Proyek saat ini, maka cakupannya adalah proyek.
- Jika tidak, cakupannya adalah koleksi.
- Jika alur berada dalam proyek privat, periksa pengaturan Alur di bawah pengaturan Organisasi Azure DevOps Anda:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis diaktifkan, maka cakupannya adalah proyek.
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis tidak diaktifkan, periksa pengaturan Alur di bawah pengaturan Proyek Anda di Azure DevOps:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis diaktifkan, maka cakupannya adalah proyek.
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur non-rilis tidak diaktifkan, buka editor untuk alur, dan navigasikan ke tab Opsi .
- Jika cakupan otorisasi pekerjaan Build adalah Proyek saat ini, maka cakupannya adalah proyek.
- Atau, cakupannya adalah koleksi.
Saat membuat alur klasik baru, cakupan otorisasi pekerjaan diatur ke proyek saat ini dan cakupan otorisasi pekerjaan build diatur ke proyek secara default.
Bagaimana cara menentukan cakupan otorisasi pekerjaan alur rilis klasik saya?
Alur rilis klasik di Azure DevOps Server 2020 ke bawah berjalan dengan cakupan koleksi .
- Jika alur berada dalam proyek publik, maka cakupan otorisasi pekerjaan adalah proyek terlepas dari pengaturan lain.
- Jika alur berada dalam proyek privat, periksa pengaturan Alur di bawah pengaturan Organisasi Azure DevOps Anda:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur rilis diaktifkan, maka cakupannya adalah proyek.
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur rilis tidak diaktifkan, periksa pengaturan Alur di bawah pengaturan Proyek Anda di Azure DevOps:
- Jika Batasi cakupan otorisasi pekerjaan ke proyek saat ini untuk alur rilis diaktifkan, maka cakupannya adalah proyek.
- Jika tidak, cakupannya adalah koleksi.