Azure-docs: Azure DevOps Build Pipeline tidak bisa mendapatkan rahasia dari Key Vault jika diamankan dengan vnet dan firewall

Dibuat pada 15 Sep 2019  ·  50Komentar  ·  Sumber: MicrosoftDocs/azure-docs

Saya ingin menggunakan rahasia yang disimpan dalam brankas kunci dari tugas DevOps Build Pipeline dan saya ingin mengikuti praktik terbaik keamanan dan pertahanan secara mendalam. Sebagai praktik keamanan terbaik, saya ingin brankas kunci dapat diakses dari jaringan virtual tertentu, layanan biru tertentu, dan dari ip internet tepercaya. Tentu saja, saya akan menggunakan prinsip layanan dan izin yang sesuai (daftar / dapatkan).

Sayangnya, Azure DevOps bukanlah salah satu layanan tepercaya. Jadi, alternatif saya adalah membuat daftar putih IP DevOps. Saya menemukan DevOps saya berada di wilayah AS Timur 2 dan saya mengunduh IP Pusat Data Azure (difilter dengan AS Timur2). Ada sekitar 285 IP di AS East2. Firewall Vault Kunci memiliki batas jumlah aturan firewall yang dapat Anda tambahkan dan jumlahnya 127! Jadi, saya kurang beruntung!

Saat ini, saya bisa mendapatkan rahasia dari key vault di build pipeline hanya jika saya mengizinkan semua jaringan! Ya, saya masih harus mengotentikasi untuk mendapatkan rahasia tetapi saya kalah dalam pertahanan secara mendalam. Saya benar-benar perlu mengunci brankas kunci ke jaringan tepercaya tetapi saya tidak bisa. Mengapa? Saya tidak dapat menambahkan lebih dari 127 aturan firewall (untuk mencakup wilayah) dan DevOps bukan salah satu layanan biru tepercaya!


Detail Dokumen

Jangan edit bagian ini.

Pri2 awaiting-product-team-response key-vaulsvc product-question triaged

Komentar yang paling membantu

Dan omong-omong, artikel yang direferensikan di atas mengatakan rentang IP dapat berubah setiap minggu. Menyarankan kami memperbarui firewall setiap minggu dan bahkan mencoba melacak perubahannya cukup konyol.

Semua 50 komentar

@ aspnet4you Terima kasih atas tanggapannya.
Kami sedang menyelidiki secara aktif dan akan segera menghubungi Anda.

@ KalyanChanumolu-MSFT - Terima kasih telah menyelidiki masalah ini. Key Vault adalah komponen infrastruktur penting dan berdasarkan sifat bisnisnya, kami tidak ingin mengeksposnya ke jaringan yang tidak tepercaya. Jika saya membuat mesin di ventilasi saya, itu akan baik-baik saja tetapi tujuan saya adalah menggunakan Azure DevOps untuk CI / CD. Saya perlu menyimpan kunci dan rahasia, dan dapat mengambilnya dengan aman.

@ aspnet4you , Terima kasih telah berbagi pertanyaan. Memasukkan IP ke daftar putih bukanlah cara yang efisien, tetapi pasti merupakan solusi. Kami bekerja dengan tim Produk untuk mendapatkan Azure Dev Ops sebagai layanan Tepercaya untuk Azure Key Vault dan itu akan menjadi perbaikan lengkap dalam semua persyaratan. Izinkan kami kapan-kapan dan saya akan membagikan pembaruan saya berikutnya dengan Anda.

Anda dapat menambahkan langkah dalam definisi build untuk memasukkan alamat IP agen ke daftar putih, lalu menghapusnya dari daftar putih di akhir build. Ini bukan solusi melainkan solusi hingga tim produk Azure menambahkan Azure DevOps sebagai layanan tepercaya. Terima kasih kepada @ Daniel Mann untuk memberikan idenya.

Solusinya sederhana tetapi saya tidak akan mempercayai ipify.org sebagai titik akhir REST API untuk mendapatkan alamat ip agen build saya. Sebagai gantinya, saya membuat layanan saya sendiri (dan tepercaya) di Azure Function- GetClientIP. DevOps bukanlah pekerjaan harian saya dan saya mengalami kesulitan untuk mencari tahu cara menetapkan dan menggunakan variabel yang ditentukan pengguna dan meneruskannya ke langkah / tugas / tahap berikutnya dalam saluran! Dokumentasi Microsoft tentang penggunaan variabel tidak cukup membantu saya, tetapi saya mengetahuinya setelah banyak proses yang gagal!

Lihat solusi lengkapnya di blog saya- Azure DevOps Build Pipeline- gunakan kunci dan rahasia dari Key Vault .

@ aspnet4you , Ada pembicaraan untuk mendapatkan Azure DevOps sebagai layanan tepercaya. Azure DevOps memiliki skenario berbeda di mana identitas yang mengakses Key Vault adalah milik pelanggan, bukan milik Microsoft. Ini melanggar persyaratan skalabilitas dan keamanan untuk "layanan tepercaya".

Saat ini satu-satunya solusi tampaknya adalah menambahkan alamat IP mesin DevOps ke firewall AKV. Ini adalah subset yang lebih kecil dari semua IP Pusat Data, dan akan sesuai dengan batas 127 aturan IP.

Saat ini saya sedang berupaya mendapatkan IP, dan akan segera memperbarui utas.

@ aspnet4you , Temukan detail tentang IP di bawah ini:

Untuk memasukkan layanan AzureDevops ke daftar putih - https://docs.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops

Untuk memasukkan Agen yang Dihosting ke https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#agent -ip-range

Semoga ini membantu.

@ aspnet4you , Semoga ini bisa membantu. Jangan ragu untuk menghubungi kami jika ada pertanyaan lain seputar hal ini. Kami menutup utas ini untuk saat ini.

@ souravmishra-msft memastikan bahwa layanan azure devops yang masuk daftar putih, ip di tautannya tidak cukup.
Misalnya mencoba menautkan grup variabel dari devops ke rahasia dari keyvault, saya juga perlu menambahkan ip: 52.236.xx (saya sengaja menyembunyikan lat 2 byte). Tahukah Anda dari mana ip ini? Dapatkah Anda memberikan berbagai ip lengkap untuk tautan grup variabel devops?

@ aspnet4you , Terima kasih telah berbagi pertanyaan. Memasukkan IP ke daftar putih bukanlah cara yang efisien, tetapi pasti merupakan solusi. Kami bekerja dengan tim Produk untuk mendapatkan Azure Dev Ops sebagai layanan Tepercaya untuk Azure Key Vault dan itu akan menjadi perbaikan lengkap dalam semua persyaratan. Izinkan kami kapan-kapan dan saya akan membagikan pembaruan saya berikutnya dengan Anda.

Ada pembaruan tentang fitur ini? Apakah ada tautan untuk melacak fitur 'Azure Dev Ops sebagai layanan Tepercaya untuk Azure Key Vault'

Permintaan yang sama untuk penawaran PAAS Titik Akhir Layanan VNET lainnya - https://feedback.azure.com/forums/217298-storage/suggestions/35850511-make-azuredevops-a-trusted-microsoft-services-to

@ aspnet4you , bagaimana membuat daftar putih IP saja cukup untuk mendapatkan Rahasia / Kunci tanpa Kebijakan Akses Key Vault yang relevan?

@oviliz - Pertanyaan yang sangat bagus. Memasukkan IP ke daftar putih adalah salah satu pertahanan terakhir terhadap akses tidak sah ke vault. Service Principal harus dikonfigurasi dengan Key Vault Access Policy untuk mendaftar dan mendapatkan kunci dan rahasia. Ini adalah persyaratan ke-2 seperti yang dinyatakan dalam posting saya - Azure DevOps Build Pipeline- gunakan kunci dan rahasia dari Key Vault .

Halo @ KalyanChanumolu-MSFT ada pembaruan? Hari ini saya menghadapi masalah yang sama. Saya tidak dapat mengambil rahasia dari KV saya di langkah Azure Key Vault di pipa Rilis saya (Azure DevOps). Tautan dengan IP di atas rusak ... Jadi bagaimana saya bisa mendapatkan kembali rahasia di saluran saya? Izinkan layanan Microsoft tepercaya untuk melewati firewall ini? (Ya) - tidak membantu juga.

Saya juga menghadapi masalah ini dan jelas sekali IP mana yang perlu dimasukkan ke daftar putih. Plus, ini membuka lemari besi kami ke layanan yang tidak kami kendalikan jadi saya sangat tidak senang dengan solusi ini.

Dan omong-omong, artikel yang direferensikan di atas mengatakan rentang IP dapat berubah setiap minggu. Menyarankan kami memperbarui firewall setiap minggu dan bahkan mencoba melacak perubahannya cukup konyol.

Saya menghadapi masalah yang sama, dan memasukkan IP ke daftar putih setiap minggu bukanlah opsi sama sekali.

Apakah mungkin memiliki agen yang dihosting sendiri untuk Build Pipeline di dalam VM, menyiapkan VM ini di dalam VNet, lalu mengizinkannya mengakses dalam Key Vault? Saya bukan pro sama sekali, jadi seberapa absurd pendekatan ini?

FWIW Saya terinspirasi oleh solusi ini di sini: https://www.visualstudiogeeks.com/DevOps/PrivateAzureAseV2AppServiceVstsDeploymentUsingAzureDtl

Tambahkan kami ke daftar. Bagaimana mungkin ADO bukanlah layanan tepercaya untuk Key Vaults?

Jika Anda mencari file mingguan untuk pengembang atau agen yang dihosting, itu tidak akan menyorot ips apa pun. Ip apa yang Anda gunakan di https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519 ??? dan jika Anda mencari berdasarkan Datacenter ada appservice, devspaces, dll, tapi apa yang berhubungan dengan devops dan host agent?

@ ShaneBala-keyvault, Seperti yang diminta, menambahkan Anda ke utas ini.

Tambahkan kami ke daftar. Bagaimana mungkin ADO bukanlah layanan tepercaya untuk Key Vaults?

Dengan Anda Di Sana, Mencari untuk memindahkan Banyak proyek ke AZ Devops tetapi ini adalah Masalah

+1, ini harus diperbaiki secepatnya. Bahkan jika variabel pipeline rahasia dapat digunakan untuk rilis, saya ingin memiliki satu sumber kebenaran. Nilai variabel pipa rahasia tidak dapat dilihat lagi setelah disimpan, jadi bagaimanapun cara Anda meletakkannya, informasi tersebut perlu disimpan di tempat lain.

SO pertanyaan tentang masalah ini:

https://stackoverflow.com/q/61411653/3850405

+1 ini sangat penting. Ada komentar dari Microsoft tentang itu?

@ Souravmishra-msft Haruskah ini dibuka kembali?

@Ogglas Ini pasti harus dibuka kembali. Mereka harus mencantumkan ips atau menandai layanan untuk melewati Azure Keyvault Firewall. Mereka melakukannya untuk layanan lain, mengapa tidak dengan azure devops?

+1, masalah yang sama di sini

+1

juga bergabung dalam tumpukan di .. masalah besar bagi saya juga

Bagaimana bisa sedekat ini ???? tautan tautan "solusi" juga tidak berfungsi :)

@jsburckhardt - Tidak yakin solusi mana yang Anda maksud tetapi Anda dapat meninjau posting blog saya,
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Apakah kami perlu membuat terbitan baru untuk ini, atau mencari cara untuk membukanya kembali, @ souravmishra-msft?

@captainbrown , saya telah membuka kembali utas ini. Saya juga telah memperbarui Manajer Program secara internal sekali lagi, sejak thread ini pertama kali dibuka, thread internal dibuat dengan Tim Produk.

Saya juga menetapkan utas ini ke Manajer Program. Mungkin perlu beberapa saat bagi mereka untuk menanggapi utas ini karena saya tidak yakin tentang kerumitan yang mungkin diperlukan perubahan ini dari sisi produk.

Saya juga telah menemukan utas internal yang terjadi pada utas github ini dan akan terus memberi Anda informasi terbaru tentang kemajuannya.

Saya juga ingin menyatakan bahwa saya telah memperbaiki URL yang disebutkan di salah satu komentar saya di awal utas ini. Anda mungkin ingin melihatnya juga sesekali dan memberi tahu kami jika solusi tersebut sesuai untuk solusi Anda dan jika tidak, perbarui kami juga.

@ souravmishra-msft terima kasih banyak telah membuka kembali masalah ini. Mengizinkan rentang untuk layanan devops tidak berfungsi untuk mengizinkan akses ke keyvault (mungkin rentang tersebut sudah usang di situs web) dan daftar subnet yang mungkin terlalu panjang untuk ditambahkan ke kontrol akses jaringan pada keyvault.

Tim saya dan saya akan sangat menantikan kabar dari Manajer Program Anda

Terima kasih telah membuka kembali ... @captainbrown Saya melihat masalah yang sama dimana dokumentasi atau file json dengan layanan ip sudah pasti ketinggalan zaman / tidak terdokumentasi dengan baik.

Setuju, terima kasih telah membuka kembali. Ini adalah masalah yang ingin kami atasi juga.

@ souravmishra-msft Terima kasih, semoga segera menjadi prioritas.

+1, ini juga menjadi masalah kami. Tidak hanya akses Azure DevOps ke Key-vault, tetapi kami juga perlu ke pipeline DevOps untuk menghasilkan beberapa file dan mengunggahnya ke Akun Penyimpanan yang dilindungi firewall, tetapi kami menghadapi masalah yang sama, bahwa Azure DevOps bukanlah layanan tepercaya dan solusinya adalah memasukkan ke daftar putih ~ 250 alamat IP setiap minggu, jadi itu akan sangat buruk (ditambah juga tidak yakin apakah ada batasan berapa banyak alamat IP yang dapat ditambahkan ke firewall akun penyimpanan). Akan sangat bagus jika ini bisa diatasi!

Saat ini ada solusi untuk masalah ini.

Anda dapat menggunakan agen yang dihosting sendiri dan menambahkan rentang IPv4 berikut ke daftar yang diizinkan dari firewall kubah kunci. Detailnya di sini: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops

(Tim Azure DevOps mengetahui masalah ini dan pekerjaan untuk perbaikan permanen sedang dalam proses)

Fitur ini sedang dalam pratinjau.

Berikut adalah cara lain untuk melakukannya ... Anda dapat mengatur vnet Anda sendiri dengan rangkaian skala.

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/scale-set-agents?view=azure-devops

Trik lain ... saya tidak mengambil kepemilikan trik ini, seseorang menunjukkan kepada saya.
Jika Anda memiliki akun pengembang perusahaan, ada cara untuk mengizinkan pengembang membaca rahasia keyvault untuk perpustakaan Anda.
Jika Anda memiliki akun pribadi, ini tidak berfungsi.

Anda dapat membuka firewall ke jaringan Azure / 11, mengatur koneksi dari devops ke azure dengan keyvault. Siapkan perpustakaan variabel dan tambahkan rahasianya. Setelah rahasia ditambahkan, hapus aturan firewall dan coba tambahkan rahasia. Pesan kesalahan akan memberikan Anda IP yang dapat Anda tempatkan di firewall. Kami telah menemukan bahwa itu tidak berubah dalam sebulan dan kami memahami bahwa itu bisa berubah. Pada titik ini, kami sedang mencari solusi seperti orang lain. Saya akan melakukan pengujian lebih lanjut dengan build dan rilis, tetapi ini memungkinkan Native Devops GUI untuk berinteraksi dengan Keyvaults secara langsung.

Sekali lagi, ini tidak berfungsi dengan akun pribadi.

1 Kami memiliki masalah yang sama menggunakan AzDO ke SQL server melalui tautan Pribadi / titik akhir.

+1 Masalah serupa di sini.

Solusi disediakan di sini. Ini bukan masalah dengan dokumen itu sendiri. Ini adalah solusinya https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops # please-close Anda juga dapat mengirim permintaan fitur di sini https: // developercommunity.visualstudio.com/spaces/21/index.html

+1, pukul masalah ini hari ini.

JIKA Microsoft akan mengaktifkan Tag Layanan untuk Azure DevOps, dapatkah itu digunakan di Keyvault Firewall? https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

@ JQUINONES82 Saya khawatir bukan untuk agen yang dihosting. Dari tautan Anda:

Tag Servis tidak berlaku untuk Agen yang Diinangi Microsoft.

+1, mencapai ini selama 2 tahun terakhir

+1, pukul masalah ini hari ini.

Ini ditutup, jadi bagaimana cara memperbaikinya?

Keamanan bukanlah permintaan fitur, ini adalah kebutuhan untuk komponen cloud apa pun. Jika ini tidak diperbaiki, dapatkah dibuka kembali? Saya melihat disebutkan sesuatu sedang dalam pratinjau ... Saya akan mengambil fitur pratinjau. Ini akan menahan penerapan kami karena saya tidak ingin menghabiskan lebih banyak uang untuk memutar VM dengan biru langit untuk melakukan ini ...

@jsburckhardt - Tidak yakin solusi mana yang Anda maksud tetapi Anda dapat meninjau posting blog saya,
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Hai sobat, ini solusi yang bagus. Sayangnya, karena batasan keamanan. Tim tidak memiliki kontrol atas IP yang masuk daftar putih KV / vNet

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

paulmarshall picture paulmarshall  ·  3Komentar

AronT-TLV picture AronT-TLV  ·  3Komentar

JeffLoo-ong picture JeffLoo-ong  ·  3Komentar

behnam89 picture behnam89  ·  3Komentar

jamesgallagher-ie picture jamesgallagher-ie  ·  3Komentar