प्रतिक्रिया के लिए धन्यवाद! हम वर्तमान में जांच कर रहे हैं और शीघ्र ही आपको अपडेट करेंगे।

इसके लिए वोट करें! Azure पाइपलाइन होस्ट IP की श्रेणियाँ https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-पर्वतमाला

इसके लिए वोट करें! Azure पाइपलाइन होस्ट IP की श्रेणियाँ https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-पर्वतमाला

@XiaoningLiu यह सामान्य नहीं है।

@renattomachado

मैं इस विशेष मुद्दे पर भी आया। यदि आपका आवेदन मिशन क्रिटिकल नहीं है (यानी, सार्वजनिक पहुंच का एक सेकंड भी आपके व्यवसाय को अपंग कर सकता है) तो मैं निम्नलिखित की सिफारिश करता हूं:

1. अपने भंडारण खाते के लिए Azure में अपनी फ़ायरवॉल सेटिंग सेट करें।
2. आपकी रिहाई में (या बिल्ड) अपने स्टोरेज खाते के लिए अपनी अनुमति को प्रोग्रामेटिक रूप से सभी नेटवर्क पर सेट करें, जैसे निम्न (यह एज़्योर सीएलआई का उपयोग करता है, लेकिन आप पॉवर्सशेल का उपयोग करके भी ऐसा कर सकते हैं)।

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

1. अपने संग्रहण खाते तक पहुँचने के संबंध में आपको जो कुछ भी करने की आवश्यकता है वह करें।
2. तुरंत नेटवर्क सेटिंग्स को वापस Deny पर रीसेट करें। जब इनकार करने के लिए तैयार है तो यह आपकी सेटिंग्स का सम्मान करेगा जो पहले चरण 1 में सेटअप थे।

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

उम्मीद है कि आपकी मदद करता है।

@XiaoningLiu

क्या आईपी रेंज / सार्वजनिक आईपी प्राप्त करने का कोई तरीका है? मैंने बस https://ipecho.net/ पर curl का उपयोग करने की कोशिश की और उस IP (सभी को एक पाइपलाइन में काम करते हुए) को जोड़ दिया, लेकिन यह वास्तव में काम नहीं करता है। आदर्श रूप से हम बस उस एजेंट से आईपी रेंज प्राप्त कर सकते हैं जिसका हम उपयोग कर रहे हैं, इसे श्वेतसूची में जोड़ें, और इसे तुरंत हटा दें। इस तरह हमें अपने क्षेत्र के लिए आईपी के साप्ताहिक सेट को पार्स करने वाले किसी प्रकार की नौकरी नहीं करनी है।

एक ही मुद्दा यहाँ। Azure DevOps का उपयोग Terraform के साथ Azure संसाधनों को तैनात करने के लिए। सुरक्षा आवश्यकताओं के कारण, हमें VNET फ़ायरवॉल नियमों को चालू करने की आवश्यकता है। जैसे ही हम इसे चालू करते हैं, Terraform Azure DevOps से संग्रहण खाता जानकारी (403) को पुनर्प्राप्त करने में सक्षम नहीं होता है और परिनियोजन पाइपलाइन टूट जाती है।

"विश्वसनीय Microsoft सेवाओं को इस संग्रहण खाते तक पहुंचने की अनुमति दें" सक्षम है, लेकिन जाहिर है कि Azure DevOps को इस तरह से मान्यता प्राप्त नहीं है ...

क्या इस पर कोई खबर है? हम चाहते हैं कि हमारे संग्रहण खाते सुरक्षित हों, लेकिन हम DevOps पाइपलाइनों को तैनात करना और उनका उपयोग करना चाहते हैं। और यहाँ हर किसी के समान मुद्दे हैं।

यहां बताया गया है कि किस प्रकार की आईपी रेंज हैं। https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

@ आर्टिस्टिक

मुझे लगता है कि मुद्दा यह है कि उस XML के उपयोग के लिए किसी को कुछ स्वचालन या प्रक्रिया की आवश्यकता होगी जो कि ब्लैकलिस्ट को बनाए रखता है और पुराने आईपी को हटा देता है।

आदर्श रूप में एक मशीन का आईपी प्राप्त करने का एक तरीका होगा जिसे आप होस्ट किए गए एजेंट को चलाने के दौरान उपयोग कर रहे हैं, इस तरह से आप जो मैंने ऊपर वर्णित किया है उसके समान कुछ कर सकते हैं, सिवाय एक मशीन के (एक DevOps नौकरी चलाने वाले) ।

हां, इसके अलावा फ़ायरवॉल केवल 100 प्रविष्टियों तक ही सीमित प्रतीत होता है, इसलिए यह काम नहीं कर रहा है।

हम इस प्रकार की श्रेणियों को सेवा द्वारा परिभाषित करने की अनुमति देने के लिए "टैग" या "उपनाम" परिभाषाओं को सक्षम करने की योजना पर काम कर रहे हैं। अभी तक ईटीए नहीं।

कृपया बंद करें

जब इसे संबोधित नहीं किया गया है तो यह मुद्दा क्यों बंद किया जा रहा है?
'... एक योजना पर काम करना ... वास्तव में इस मुद्दे से निपटना नहीं है।

@nickforr जब से हम इस पर काम कर रहे हैं। मेरे पास अभी तक इस पर कोई ईटीए नहीं है,

वर्तमान में एक ही समस्या का अनुभव कर रहा है, क्या अब कोई अद्यतन है?

@ SumanthMarigowda-MSFT या @cbrooksmsft - क्या इससे संबंधित फ़ीचर अनुरोध पर नज़र रखने का कोई तरीका है - भले ही आप ईटीए साझा करने में सहज नहीं हों, लेकिन जब यह किया गया हो तो इसे अधिसूचित किया जाना उपयोगी होगा।
धन्यवाद!

@Tabeth sugest के समान, कई मामलों में मैं विभिन्न संसाधनों (sql, फंक्शन ऐप et.c) के चैंज फ़ायरवॉल नियम था, जिससे कि devops agent ip से अस्थायी रूप से ट्रैफ़िक की अनुमति दी जा सके। हालाँकि, यह भंडारण खातों के लिए काम नहीं कर रहा है, इस वजह से:

IP नेटवर्क नियमों का भंडारण खाते के समान Azure क्षेत्र से होने वाले अनुरोधों पर कोई प्रभाव नहीं पड़ता है।

@cbrooksmsft क्या आप

यह मुद्दा 24 नवंबर 2018 को उठाया गया था। यह संभव है कि गलती से सही प्रतिस्थापन मुद्दा बनाए बिना इसे बंद करने के लिए कहा गया था? मैं पूछता हूं क्योंकि अब हम लाइन से 2 साल नीचे हैं और ऐसा लग रहा है कि यह बग अभी भी मौजूद है?

यहां (केवल सुरक्षा हटाने के) सुझाए गए कार्य ग्राहक के डेटा को जोखिम में डाल सकते हैं।

कृपया सलाह दें,

txs
एलन

ऐसा लगता है कि यह Q2 2020 में होने की योजना बना रहे थे
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

@artisticcheese आप एक बहुत व्यापक घोषणा से जुड़े। उस घोषणा का कौन सा हिस्सा आपको लगता है कि इस मुद्दे को संबोधित करता है? यदि आप "सेवा टैग" का मतलब है, तो मैं इस मुद्दे को संबोधित न? सेवा टैग "टैग" प्रति नियमों के एक सहायक समूह की तरह दिखता है, और यहाँ वर्णित समस्या अभी भी मौजूद होगी। (विशेष रूप से स्थानीय azure devops को --bypass "Logging Metrics AzureServices शामिल किए जाने से स्वतः सफेदी नहीं हुई है शायद मैंने कुछ याद किया है?

इस धागे के लिए किसी को भी नया करने के लिए; जब मैं नीचे के रूप में azure devops पाइपलाइन में उपयोग के लिए azure भंडारण संसाधन बनाता हूं

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" 

अगर मेरे पास मेरी azure devops पाइपलाइन में एक कदम है जो AzureFileCopy@3 उदा का उपयोग करता है

    - 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

तब यह अनुमति त्रुटि के साथ विफल हो जाएगा,

गंतव्य को मान्य करने में विफल। दूरस्थ सर्वर ने एक त्रुटि दी: (403) निषिद्ध।

जब वास्तव में (यदि दस्तावेज़ को माना जाता है तो) --bypass AzureServices का उपयोग करते समय भंडारण खाता बनाने के लिए भंडारण खाते की अनुमति के साथ azuredevops प्रदान

मेरा मानना ​​है कि यह समस्या की जड़ है, और Q2 2020 की घोषणा में कुछ भी इस विशिष्ट मुद्दे को संबोधित नहीं करता है?

मैं इस पर गलत होना पसंद करूंगा।
ए

ऐसा लगता है कि यह Q2 2020 में होने की योजना बना रहे थे
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

यह सुनिश्चित नहीं है कि यह योजनाबद्ध है। यह विशेष रूप से बताता है: पाइपलाइनों के लिए Microsoft होस्टेड एजेंटों के लिए सेवा टैग समर्थित नहीं हैं।

मैं भी एक ही मुद्दे का अनुभव करने के लिए होता है। कोई भी आधिकारिक तौर पर पुष्टि कर सकता है कि यह अभी भी नियोजित है?

मैं Azure Devops पाइपलाइन Microsoft होस्टेड एजेंट को संग्रहण खाते से कनेक्ट करने में असमर्थ हूं। क्या यह हल होने वाला है

क्या आप ऊपर दिए गए सवालों के जवाब दे सकते हैं? आपने बंद करने का अनुरोध किया है लेकिन इसका समाधान नहीं हो रहा है?
यदि इसे वास्तव में हल कर लिया गया है, तो यह कम से कम यह कहने के लिए Microsoft के विचारशील (पेशेवर) होगा कि "अरे दोस्तों यह एक्स करके तय किया गया है"।

वही मुद्दा

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

सेवा टैग के लिए आगामी परिवर्तनों का संदर्भ। यह अभी भी हमारी समस्या का समाधान नहीं करता है:

_The सेवा टैग Microsoft होस्टेड एजेंटों पर लागू नहीं होता है। ग्राहकों को अभी भी Microsoft होस्टेड एजेंटों के लिए पूरे भूगोल की अनुमति देना आवश्यक है ।_

सेवा टैग के लिए आगामी परिवर्तनों का संदर्भ। यह अभी भी हमारी समस्या का समाधान नहीं करता है:

_The सेवा टैग Microsoft होस्टेड एजेंटों पर लागू नहीं होता है। ग्राहकों को अभी भी Microsoft होस्टेड एजेंटों के लिए पूरे भूगोल की अनुमति देना आवश्यक है ।_

सेवा टैग के लिए आगामी परिवर्तनों का संदर्भ। यह अभी भी हमारी समस्या का समाधान नहीं करता है:

_The सेवा टैग Microsoft होस्टेड एजेंटों पर लागू नहीं होता है। ग्राहकों को अभी भी Microsoft होस्टेड एजेंटों के लिए पूरे भूगोल की अनुमति देना आवश्यक है ।_

सेवा टैग के लिए आगामी परिवर्तनों का संदर्भ। यह अभी भी हमारी समस्या का समाधान नहीं करता है:

_The सेवा टैग Microsoft होस्टेड एजेंटों पर लागू नहीं होता है। ग्राहकों को अभी भी Microsoft होस्टेड एजेंटों के लिए पूरे भूगोल की अनुमति देना आवश्यक है ।_

सच है, यह ठीक से नहीं पढ़ा properly

मैं इसी समस्या में चल रहा हूं और मुझे आश्चर्य है कि यह मुद्दा बंद हो गया। मेरा पहला विचार यह था कि मैं अपने सभी JSON फ़ाइल को यहाँ से सभी IP श्रेणियों के साथ पार्स करने के लिए एक अनुसूचित उपकरण बनाने जा रहा हूँ, लेकिन वे इसके लिए एक एपीआई प्रदान नहीं करते हैं। तो मेरा सबसे अच्छा विकल्प हर हफ्ते JSON फ़ाइल को मैन्युअल रूप से डाउनलोड करना है, इसे कुछ पार्सिंग प्रक्रिया में फ़ीड करना है, और फिर स्टोरेज फ़ायरवॉल सेटिंग्स में अनुमति देने के लिए आईपी पर्वतमाला (हम सैकड़ों बात कर रहे हैं) को धक्का दें? निश्चित रूप से एक बेहतर तरीका है। Microsoft!

एपीआई है, यह सिर्फ काम नहीं करता है (तारीख से बाहर)
https://docs.microsoft.com/en-us/rest/api/virtualnetwork/servicetags/list

स्वचालित रूप से (JSON फ़ाइलों को डाउनलोड करना / पार्स करना) को कम या ज्यादा करना आसान है
https://artisticcheese.wordpress.com/2020/08/17/automating-azure-sql-firewall-rules-based-on-azure-service-tags/

@artisticcheese , जानकारी के लिए धन्यवाद। दिलचस्प विचार, लेकिन मैं उस JSON फ़ाइल को खींचने के लिए अपने वेबपृष्ठ को स्क्रैप करने में सहज नहीं हूं। यह एक उत्पादन ऐप है और यह बहुत जोखिम भरा है। और इसके अलावा, इस पद्धति में स्टोरेज फ़ायरवॉल में सैकड़ों प्रविष्टियाँ शामिल होंगी, बस मेरी होस्टेड एज़्योर पाइपलाइन को कुछ फाइलों को कॉपी करने दें। यह उल्लेखनीय है, लेकिन यह मेरे उद्देश्यों के लिए ओवरकिल है।

सज्जनों, मैंने आज आपको अपने वोट की याचना करने के लिए यहाँ इकट्ठा किया है! -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

इसे एएसएपी तय करने की आवश्यकता है, यह पिछले दो वर्षों से एक जारी मुद्दा है ... इसे साझा करें, ट्वीट करें, इसे ठीक करने में मदद करें और इसे Microsoft के रडार पर ले जाएं AS

@ एडम्स-MSFT @XiaoningLiu @tabeth @sesispla @SeiketsuJael @artisticcheese @cbrooksmsft @nickforr @ SumanthMarigowda-MSFT @solaomoDevOps @shahiddev @ मार्सिन-vt @goblinfactory @artisticcheese @lymedo @ felipecruz91 @pratimvengurlekar @justinimel @ मार्सिन-vt @renattomachado @mimckitt @ स्नातक

@BobbyCGD को वोट दिया गया

वर्कअराउंड के रूप में, यहां एक कार्य है जिसका मैं उपयोग करता हूं ...

- 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

मुझे लगता है कि, मैं विंडोज एजेंट का उपयोग कर रहा हूं और यह जांचने का विकल्प नहीं चुना है कि क्या एजेंट का आईपी पता सेवा टैग में आईपी पते की सूची में है। यहाँ कदम है जो मैंने अपनी पाइपलाइन में जोड़ा है

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)'

मैं तब उपयोग करता हूं

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)'

भंडारण खाते में प्रकाशित करने की कोशिश करने से पहले और मेरे द्वारा प्रकाशित किए जाने के बाद मैं इसका उपयोग करता हूं

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 यदि आप ipinfo द्वारा पाए गए आईपी की जांच नहीं करते हैं, तो आप मानते हैं कि इसे हैक नहीं किया गया है ... उत्पादन पर्यावरण पर सावधान रहें!

@arkiaconsulting निश्चित रूप से एक जोखिम है, लेकिन मेरे विशिष्ट उपयोग के मामले में कोई समस्या नहीं है। तैनाती हमेशा "पर्यवेक्षित" सबसे खराब चीज होती है जो हो सकती है तैनाती चरण विफल रहता है। इस मामले में:

1. ईमेल अलर्ट भेजा जाता है
2. आईपी ​​दूर तैनाती कदम की सफलता पर कोई निर्भरता अभी दूर है

अफसोस की बात है कि यह https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html है। बंद कर दिया। उम्मीद है कि वे इस मुद्दे पर फिर से खोलने और देखने पर विचार करेंगे।

मैं इस धागे पर नजर नहीं रख रहा हूं ... यह बहुत पुराना है, और अभी भी यह एक समस्या है। मुझे नहीं लगता कि यह सही है इसे "बंद" के रूप में चिह्नित किया जाना चाहिए ... मैं टिप्पणी करने से बचूंगा ... लेकिन जीवन को आगे बढ़ना है ... इसलिए ... नीचे एक वर्कअराउंड का उपयोग कर रहा हूं, जो मेरे लिए अच्छी तरह से काम कर रहा है, यानी लगता है

• भंडारण कुंजी का उपयोग करें
• और * az स्टोरेज बूँद अपलोड-बैच * का उपयोग करें
• यह सब शक्तियां में करें

यह दृष्टिकोण आपके लिए काम नहीं कर सकता है, लेकिन अगर यह मेरे लिए अब तक किसी भी devops पाइपलाइन में काम करता है, तो यह एक नमूना पॉवर्सशेल स्क्रिप्ट है, तो आप इसके साथ प्रयोग कर सकते हैं और देखें कि क्या यह आपकी पाइपलाइन में भी काम करता है?

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

इस पॉवरशेल का लाभ यह है कि आप इसे स्थानीय रूप से ठीक उसी तरह चला सकते हैं जैसे कि यह डेप्स बिल्ड एजेंट पर चलता है। जब स्थानीय रूप से चलना आसान हो।

उम्मीद है कि उपयोगी है।

शुभकामनाएँ

सादर

एलन

यह अभी भी एक मुद्दा है। कृपया इसे पुनः खोलें।