Terima kasih untuk umpan baliknya! Kami sedang menyelidiki dan akan segera mengabari Anda.

Beri suara untuk ini! Rentang IP host Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-range

Beri suara untuk ini! Rentang IP host Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-range

@XiaoningLu itu tidak biasa.

@rendy_sby

Saya juga menemukan masalah khusus ini. Jika aplikasi Anda tidak memiliki misi penting (yaitu, bahkan satu detik dari akses publik dapat melumpuhkan bisnis Anda), saya merekomendasikan hal berikut:

1. Atur pengaturan firewall Anda di Azure untuk akun penyimpanan Anda.
2. Dalam rilis (atau versi) Anda, atur izin Anda untuk akun penyimpanan Anda ke semua jaringan secara terprogram, seperti berikut (ini menggunakan Azure CLI, tetapi Anda dapat melakukan hal yang sama menggunakan Powershell).

az storage account update --resource-group "myresourcegroup" --name "mystorageaccount" --default-action Allow

1. Lakukan apa pun yang perlu Anda lakukan untuk mengakses akun penyimpanan Anda.
2. Segera setel ulang pengaturan jaringan ke Tolak. Jika disetel ke Tolak, setelan Anda yang sebelumnya disiapkan di Langkah 1 akan berlaku.

az storage account update --resource-group "myresourcegroup" --name "mystorageaccount" --default-action Deny

Semoga itu membantu Anda.

@Xiaoning

Apakah ada cara untuk mendapatkan rentang IP / IP publik? Saya mencoba hanya menggunakan curl di https://ipecho.net/ dan menambahkan IP itu (semua dalam tugas sementara di Pipeline), tetapi tampaknya tidak benar-benar berfungsi. Idealnya kita bisa mendapatkan rentang IP dari Agen yang kita gunakan, menambahkannya ke daftar putih, dan langsung menghapusnya. Dengan begitu, kami tidak perlu menjalankan tugas yang mengurai kumpulan IP mingguan untuk wilayah kami.

Masalah yang sama di sini. Menggunakan Azure DevOps untuk menerapkan sumber daya Azure dengan Terraform. Karena persyaratan keamanan, kami perlu mengaktifkan aturan firewall VNET. Segera setelah kami mengaktifkannya, Terraform tidak dapat mengambil informasi akun Penyimpanan (403) dari Azure DevOps dan pipeline penerapan terputus.

"Izinkan layanan Microsoft tepercaya untuk mengakses akun penyimpanan ini" diaktifkan, tetapi jelas Azure DevOps tidak dikenali seperti itu ...

Apa ada kabar yang satu ini? kami ingin akun penyimpanan kami diamankan tetapi kami juga ingin menerapkan dan menggunakan DevOps Pipelines. dan memiliki masalah yang sama seperti orang lain di sini.

Berikut adalah cara mengetahui rentang IP yang mana. https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

@tokopedia

Saya pikir masalahnya adalah bahwa penggunaan XML itu kemudian akan mengharuskan seseorang untuk memiliki beberapa otomatisasi atau proses yang mempertahankan daftar hitam dan menghapus IP lama.

Idealnya akan ada cara untuk mendapatkan IP mesin yang Anda gunakan saat menjalankan agen yang dihosting, dengan cara itu Anda dapat melakukan sesuatu yang mirip dengan apa yang saya jelaskan di atas, kecuali untuk satu mesin (yang menjalankan pekerjaan DevOps) .

Ya, selain itu firewall tampaknya dibatasi hanya untuk 100 entri saja, jadi ini tidak akan berhasil.

Kami sedang mengerjakan rencana untuk mengaktifkan definisi "tag" atau "alias" untuk memungkinkan jenis rentang ini ditentukan oleh layanan. belum ETA.

tolong-tutup

Mengapa masalah ini ditutup jika belum ditangani?
'... mengerjakan rencana ... tidak benar-benar berurusan dengan masalah ini.

@nickforr Karena kami sedang mengerjakannya. Saya belum memiliki ETA untuk ini,

Saat ini mengalami masalah yang sama, apakah ada pembaruan sekarang?

@ SumanthMarigowda-MSFT atau @cbrooksmsft - Adakah cara untuk melacak permintaan fitur yang berkaitan dengan ini - meskipun Anda merasa tidak nyaman berbagi ETA, akan berguna jika diberi tahu ketika sudah selesai.
Terima kasih!

Mirip dengan apa yang @tabeth sugest, dalam banyak kasus saya mengubah aturan firewall dari sumber daya yang berbeda (sql, function app et.c) untuk memungkinkan lalu lintas sementara dari ip agen devops. Namun ini tidak berfungsi untuk akun penyimpanan, karena ini :

Aturan jaringan IP tidak berpengaruh pada permintaan yang berasal dari wilayah Azure yang sama dengan akun penyimpanan.

@cbrooksmsft Bisakah Anda menjelaskan mengapa Anda meminta agar masalah ini ditutup? Ini masih rusak. Jika masalah ini diangkat di tempat yang salah, dapatkah Anda memberikan tautan ke tempat bug pengganti telah muncul yang melacak masalah ini sehingga akan diselesaikan?

Masalah ini diangkat 24 November 2018. Mungkinkah ini keliru diminta untuk ditutup tanpa membuat masalah penggantian yang benar? Saya bertanya karena kita sekarang 2 tahun ke depan dan sepertinya bug ini masih ada?

Solusi yang disarankan di sini (hanya dengan menghapus keamanan) dapat membahayakan data pelanggan.

mohon saran,

txs
Alan

Mereka sepertinya berencana memilikinya pada Q2 2020
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1710676

@artisticcheese Anda ditautkan ke pengumuman yang sangat luas. Bagian mana dari pengumuman itu yang menurut Anda membahas masalah ini? Jika yang Anda maksud adalah "tag layanan" maka bukankah ini mengatasi masalah? Tag layanan tampak seperti pengelompokan aturan per "tag" yang bermanfaat, dan masalah yang dijelaskan di sini akan tetap ada. (khususnya bahwa pengembang biru langit lokal tidak secara otomatis masuk daftar putih dengan dimasukkannya --bypass "Logging Metrics AzureServices Mungkin saya melewatkan sesuatu?

Untuk merekap bagi siapa pun yang baru mengenal utas ini; ketika saya membuat sumber daya penyimpanan biru untuk digunakan dalam pipa devops biru seperti di bawah ini

az storage account create -g "{resource-group-redacted}" `
-n "{storage-account-name-redacted}" `
-l "westeurope" `
--kind "StorageV2" `
--sku "Standard_RAGRS" `
--access-tier "Hot" `
--bypass Logging Metrics AzureServices `
--default-action "Deny" `
--https-only "true" 

jika saya memiliki langkah dalam pipeline devops biru saya yang menggunakan AzureFileCopy@3 misalnya

    - task: AzureFileCopy<strong i="13">@3</strong>
                  displayName: "Publish files to '$(my_storage)' storage"
                  inputs:
                      SourcePath: $(Build.ArtifactStagingDirectory)
                      azureSubscription: $(subscription)
                      Destination: AzureBlob
                      storage: $(my_storage)
                      ContainerName: $web

maka ini akan gagal dengan kesalahan izin,

Gagal memvalidasi tujuan. Server jarak jauh mengembalikan kesalahan: (403) Terlarang.

Padahal sebenarnya (jika dokumentasi seharusnya dipercaya) menggunakan --bypass AzureServices saat membuat akun penyimpanan seharusnya memberikan azuredevops dengan izin ke akun penyimpanan.

Saya percaya ini inti masalahnya, dan tidak ada dalam pengumuman Q2 2020 yang tampaknya membahas masalah khusus ini?

Saya akan senang jika salah dalam hal ini.
SEBUAH

Mereka sepertinya berencana memilikinya pada Q2 2020
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/edit/1710676

Tidak yakin itu direncanakan. Ini secara khusus menyatakan: Tag Layanan untuk Microsoft Hosted Agents for Pipelines tidak didukung.

Saya juga mengalami masalah yang sama. Adakah yang bisa secara resmi mengkonfirmasi ini masih direncanakan?

Saya tidak dapat menyambungkan agen yang dihosting Microsoft Azure Devops pipeline ke akun penyimpanan. Apakah ini akan diselesaikan

@cbrooksmsft dapatkah Anda membalas pertanyaan di atas? Anda meminta untuk menutup masalah tetapi tampaknya ini tidak terselesaikan?
Jika ini benar-benar telah diselesaikan, akan menjadi perhatian (profesional) Microsoft untuk setidaknya berkomentar di sini untuk mengatakan, "hai teman-teman ini diperbaiki dengan melakukan X".

Masalah yang Sama

FYI: https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

Referensi ke perubahan mendatang untuk tag layanan. Ini masih belum menyelesaikan masalah kami:

_Tag Servis tidak berlaku untuk Agen yang Diinangi Microsoft. Pelanggan masih diharuskan untuk mengizinkan seluruh geografi untuk Agen yang Diinangi Microsoft._

Referensi ke perubahan mendatang untuk tag layanan. Ini masih belum menyelesaikan masalah kami:

_Tag Servis tidak berlaku untuk Agen yang Diinangi Microsoft. Pelanggan masih diharuskan untuk mengizinkan seluruh geografi untuk Agen yang Diinangi Microsoft._

Referensi ke perubahan mendatang untuk tag layanan. Ini masih belum menyelesaikan masalah kami:

_Tag Servis tidak berlaku untuk Agen yang Diinangi Microsoft. Pelanggan masih diharuskan untuk mengizinkan seluruh geografi untuk Agen yang Diinangi Microsoft._

Referensi ke perubahan mendatang untuk tag layanan. Ini masih belum menyelesaikan masalah kami:

_Tag Servis tidak berlaku untuk Agen yang Diinangi Microsoft. Pelanggan masih diharuskan untuk mengizinkan seluruh geografi untuk Agen yang Diinangi Microsoft._

Benar, tidak membacanya dengan benar 😓

Saya mengalami masalah yang sama dan terus terang saya terkejut masalah ini telah ditutup. Pikiran pertama saya adalah bahwa saya harus membuat alat terjadwal untuk mengurai file JSON mingguan mereka di sini dengan semua rentang IP, tetapi tampaknya mereka tidak menyediakan API untuk itu. Jadi, opsi terbaik saya adalah mengunduh file JSON secara manual setiap minggu, memasukkannya ke beberapa proses penguraian, dan kemudian mendorong rentang IP untuk mengizinkan (kita berbicara ratusan) ke pengaturan firewall akun penyimpanan? Pasti ada cara yang lebih baik. Ayo Microsoft!

Ada API, itu tidak berfungsi (ketinggalan zaman)
https://docs.microsoft.com/en-us/rest/api/virtualnetwork/servicetags/list

Juga lebih atau kurang mudah untuk mengotomatiskan (mengunduh / mem-parsing file JSON dll)
https://artisticcheese.wordpress.com/2020/08/17/automating-azure-sql-firewall-rules-based-on-azure-service-tags/

@artisticcheese terima kasih infonya. Pemikiran yang menarik, tetapi saya tidak nyaman mengorek halaman web mereka untuk menarik file JSON itu. Ini adalah aplikasi produksi dan itu terlalu berisiko. Dan selain itu, metode ini akan melibatkan ratusan entri di firewall akun penyimpanan untuk membiarkan pipeline Azure saya menyalin beberapa file. Itu bisa dilakukan, tapi itu berlebihan untuk tujuan saya.

Tuan-tuan, saya telah mengumpulkan Anda di sini hari ini untuk memohon suara Anda! -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

Ini perlu diperbaiki secepatnya, ini adalah masalah yang sedang berlangsung selama dua tahun terakhir ... bagikan, tweet, bantu perbaiki, dan dapatkan di radar Microsoft 👍

@renattomachado @mimckitt @ Adams-MSFT @XiaoningLiu @tabeth @sesispla @SeiketsuJael @artisticcheese @cbrooksmsft @nickforr @ SumanthMarigowda-MSFT @solaomoDevOps @shahiddev @ Marcin-vt @goblinfactory @artisticcheese @lymedo @ felipecruz91 @pratimvengurlekar @justinimel @ Marcin-vt @tokopedia

@BobbyCGD Telah

Sebagai solusinya, berikut adalah tugas yang saya gunakan ...

- bash: |
    sudo apt-get -y install grepcidr
    for d in {0..30}; do
      date_string=`date -d "-${d} days" +%Y%m%d`
      url="https://download.microsoft.com/download/7/1/D/71D86715-5596-4529-9B13-DA13A5DE5B63/ServiceTags_Public_${date_string}.json"
      echo "Trying '${url}'"
      curl -X GET -sfLO ${url}
      if [ -f "ServiceTags_Public_${date_string}.json" ]; then
          break
      fi
    done
    cat ServiceTags*.json | jq -r '.values[].properties.addressPrefixes[]' > networks.txt
    IP=`curl -s http://ipinfo.io/json | jq -r '.ip'`
    echo "Current IP is '${IP}'"
    grepcidr -f networks.txt <(echo "$IP") >/dev/null && echo "${IP} belongs to the trusted Azure Service tags addresses" || exit 1
    echo "##vso[task.setvariable variable=AGENT_IP;issecret=true]${IP}"
  displayName: Get agent IP

@lymedo @arkiaconsulting

Saya rasa demikian, saya menggunakan agen windows dan telah memilih untuk tidak memeriksa apakah alamat IP agen ada dalam daftar alamat IP di tag layanan. Inilah langkah yang saya tambahkan ke pipeline saya

steps:
- bash: |
   IP=`curl -s http://ipinfo.io/json | jq -r '.ip'`
   echo "Current IP is '${IP}'"
   echo "##vso[task.setvariable variable=agentIp;issecret=true]${IP}"
  displayName: 'env: set $(agentIp)'

Saya kemudian menggunakan

steps:
- task: AzureCLI<strong i="12">@2</strong>
  displayName: 'env: add agent_ip to firewall'
  inputs:
    azureSubscription: '***'
    scriptType: ps
    scriptLocation: inlineScript
    inlineScript: 'az storage account network-rule add --account-name $(apimStorageAccountName) --ip-address $(agentIp)'

sebelum mencoba menerbitkan ke akun penyimpanan dan setelah saya selesai menerbitkan saya gunakan

steps:
- task: AzureCLI<strong i="16">@2</strong>
  displayName: 'env: add agent_ip to firewall'
  inputs:
    azureSubscription: '***'
    scriptType: ps
    scriptLocation: inlineScript
    inlineScript: 'az storage account network-rule add --account-name $(apimStorageAccountName) --ip-address $(agentIp)'

@BobbyCGD Jika Anda tidak memeriksa IP yang ditemukan oleh ipinfo, Anda berasumsi bahwa itu belum diretas ... Berhati-hatilah dengan lingkungan produksi!

@arkiaconsulting Jelas berisiko, tetapi dalam kasus penggunaan khusus saya tidak menjadi masalah. Penerapan selalu "diawasi". Hal terburuk yang bisa terjadi adalah langkah penerapan gagal. Pada kasus ini:

1. Peringatan email dikirim
2. IP segera dihapus tanpa ketergantungan pada keberhasilan langkah penerapan

Sayangnya ini https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html. telah ditutup. Mudah-mudahan mereka akan mempertimbangkan untuk membuka kembali dan menyelidiki masalah tersebut.

Saya belum mengawasi utas ini ... utas ini sangat tua, namun masih menjadi masalah. Menurut saya tidak benar ini harus ditandai sebagai "ditutup" ... Saya akan menahan diri untuk tidak berkomentar ... tetapi hidup harus terus berjalan ... jadi ... di bawah ini adalah solusi yang saya gunakan, itu tampaknya bekerja dengan baik untuk saya, yaitu

• gunakan kunci penyimpanan
• dan gunakan * az storage blob upload-batch *
• lakukan semuanya di PowerShell

Pendekatan ini mungkin tidak berhasil untuk Anda, tetapi untuk berjaga-jaga jika itu adalah contoh skrip PowerShell yang berfungsi untuk saya di pipeline devops mana pun sejauh ini, Anda dapat bereksperimen dengannya dan melihat apakah itu berfungsi di pipeline Anda juga?

https://gist.github.com/goblinfactory/1f75678c45b2917b29fcb5158550024c

keuntungan dari PowerShell ini adalah Anda dapat menjalankannya secara lokal persis sama seperti yang dijalankan pada agen build devops. lebih mudah untuk menyesuaikan saat dijalankan secara lokal.

semoga bermanfaat.

semoga berhasil

salam

Alan

Ini masih menjadi masalah. Tolong buka kembali ini.