피드백을 주셔서 감사합니다! 현재 조사 중이며 곧 업데이트 할 예정입니다.

이것에 투표하십시오! Azure Pipeline 호스트 IP 범위 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

이것에 투표하십시오! Azure Pipeline 호스트 IP 범위 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

@XiaoningLiu 평범 하지 않습니다.

안녕하세요.

나는이 특별한 문제를 만났다. 애플리케이션이 미션 크리티컬하지 않은 경우 (즉, 1 초의 공개 액세스로도 비즈니스를 마비시킬 수 있음) 다음을 권장합니다.

1. Azure에서 스토리지 계정에 대한 방화벽 설정을 지정합니다.
2. 릴리스 (또는 빌드)에서 다음과 같이 프로그래밍 방식으로 모든 네트워크에 스토리지 계정에 대한 권한을 설정합니다 (이는 Azure CLI를 사용하지만 Powershell을 사용하여 동일하게 수행 할 수 있음).

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

1. 스토리지 계정 액세스와 관련하여 필요한 모든 작업을 수행하십시오.
2. 즉시 네트워크 설정을 다시 거부로 재설정하십시오. 거부로 설정하면 이전에 1 단계에서 설정 한 설정이 적용됩니다.

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

도움이되기를 바랍니다.

안녕하세요.

IP 범위 / 공용 IP를 얻는 방법이 있습니까? https://ipecho.net/ 에서 curl 를 사용하고 해당 IP를 추가하려고 시도했지만 (파이프 라인에있는 동안 작업에 모두 포함) 실제로 작동하지 않는 것 같습니다. 이상적으로는 사용중인 에이전트에서 IP 범위를 가져 와서 화이트리스트에 추가하고 즉시 제거 할 수 있습니다. 이렇게하면 리전의 주간 IP 세트를 구문 분석하는 일종의 작업을 실행할 필요가 없습니다.

여기에도 같은 문제가 있습니다. Azure DevOps를 사용하여 Terraform으로 Azure 리소스를 배포합니다. 보안 요구 사항으로 인해 VNET 방화벽 규칙을 설정해야합니다. 이 기능을 켜 자마자 Terraform은 Azure DevOps에서 저장소 계정 정보 (403)를 검색 할 수 없으며 배포 파이프 라인이 중단됩니다.

"신뢰할 수있는 Microsoft 서비스가이 스토리지 계정에 액세스하도록 허용"이 활성화되어 있지만 분명히 Azure DevOps는 그렇게 인식되지 않습니다.

이것에 대한 소식이 있습니까? 우리는 스토리지 계정의 보안을 원하지만 DevOps Pipelines를 배포하고 사용하려고합니다. 여기에있는 다른 사람들과 같은 문제를 가지고 있습니다.

다음은 IP 범위를 확인하는 방법입니다. https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

안녕하세요.

문제는 해당 XML을 사용하려면 블랙리스트를 유지하고 오래된 IP를 제거하는 자동화 또는 프로세스가 필요하다는 것입니다.

이상적으로는 호스팅 에이전트를 실행하는 동안 사용중인 컴퓨터의 IP를 가져 오는 방법이있을 것입니다. 그러면 단일 컴퓨터 (DevOps 작업을 실행하는 컴퓨터)를 제외하고 위에서 설명한 것과 유사한 작업을 수행 할 수 있습니다. .

예, 그 외에 방화벽은 어쨌든 100 개의 항목으로 만 제한되는 것처럼 보이므로 작동하지 않을 것입니다.

우리는 서비스에서 이러한 종류의 범위를 정의 할 수 있도록 "태그"또는 "별칭"정의를 활성화하는 계획을 수립하고 있습니다. 아직 ETA가 아닙니다.

닫아주세요

이 문제가 해결되지 않은데 종결되는 이유는 무엇입니까?
'... 계획을 세우는 것은 ... 실제로 문제를 다루는 것이 아닙니다.

@nickforr 우리가 작업

현재 동일한 문제가 발생하고 있습니다. 현재 업데이트가 있습니까?

@ SumanthMarigowda-MSFT 또는 @cbrooksmsft-이와 관련된 기능 요청을 추적하는 방법이 있습니까? ETA를 공유하는 것이 불편 하더라도 완료되면 알림을받는 것이 유용 할 것입니다.
감사!

@tabeth sugest와 유사하게, 대부분의 경우 devops 에이전트 IP에서 일시적으로 트래픽을 허용하기 위해 다른 리소스 (sql, function app et.c)의 방화벽 규칙을 변경했습니다. 그러나 다음과 같은 이유로 스토리지 계정에서는 작동하지 않습니다.

IP 네트워크 규칙은 스토리지 계정과 동일한 Azure 지역에서 시작되는 요청에 영향을주지 않습니다.

@cbrooksmsft 이 문제를 종결하도록 요청한 이유를 설명해 주시겠습니까? 이것은 여전히 ​​깨졌습니다. 이 문제가 잘못된 위치에서 발생한 경우이 문제를 추적하는 교체 버그가 발생한 위치에 대한 링크를 제공하여 해결할 수 있습니까?

이 문제는 2018 년 11 월 24 일에 제기되었습니다. 올바른 교체 문제를 만들지 않고 종료하도록 실수로 요청되었을 수 있습니까? 2 년이 지났는데이 버그가 여전히 존재하는 것 같아서 묻습니다.

여기에 제안 된 해결 방법 (단순한 보안 제거)은 고객 데이터를 위험에 빠뜨릴 수 있습니다.

조언하십시오,

txs
앨런

그들은 2020 년 2 분기에 그것을 가질 계획 인 것 같았습니다.
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

@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" 

예를 들어 AzureFileCopy@3 를 사용하는 azure devops 파이프 라인에 단계가있는 경우

    - 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에 제공 해야 합니다.

저는 이것이 문제의 핵심이라고 생각하며 2020 년 2 분기 발표에서이 특정 문제를 해결하는 것으로 보이지는 않습니까?

나는 이것에 대해 틀리고 싶습니다.
ㅏ

그들은 2020 년 2 분기에 그것을 가질 계획 인 것 같았습니다.
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

계획되어 있는지 확실하지 않습니다. 구체적으로 다음과 같이 명시되어 있습니다. 파이프 라인 용 Microsoft Hosted Agent의 서비스 태그는 지원되지 않습니다.

나는 또한 같은 문제를 경험합니다. 누구든지 이것이 아직 계획되어 있다는 것을 공식적으로 확인할 수 있습니까?

Azure Devops 파이프 라인 Microsoft 호스팅 에이전트를 스토리지 계정에 연결할 수 없습니다. 이게 해결 될까요?

@cbrooksmsft 위의 질문에 답장 해 주시겠습니까? 마감 문제를 요청했지만 해결되지 않은 것 같습니까?
그것이 실제로 해결 되었다면 적어도 여기에 "X를함으로써이 문제가 해결되었습니다"라고 언급하는 것은 마이크로 소프트의 배려 (전문가) 일 것입니다.

같은 문제

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

서비스 태그에 대한 예정된 변경 사항을 참조하십시오. 여전히 문제가 해결되지 않습니다.

_Microsoft Hosted Agent에는 서비스 태그가 적용되지 않습니다. 고객은 여전히 ​​Microsoft Hosted Agent에 대해 전체 지역을 허용해야합니다 ._

서비스 태그에 대한 예정된 변경 사항을 참조하십시오. 여전히 문제가 해결되지 않습니다.

_Microsoft Hosted Agent에는 서비스 태그가 적용되지 않습니다. 고객은 여전히 ​​Microsoft Hosted Agent에 대해 전체 지역을 허용해야합니다 ._

서비스 태그에 대한 예정된 변경 사항을 참조하십시오. 여전히 문제가 해결되지 않습니다.

_Microsoft Hosted Agent에는 서비스 태그가 적용되지 않습니다. 고객은 여전히 ​​Microsoft Hosted Agent에 대해 전체 지역을 허용해야합니다 ._

서비스 태그에 대한 예정된 변경 사항을 참조하십시오. 여전히 문제가 해결되지 않습니다.

_Microsoft Hosted Agent에는 서비스 태그가 적용되지 않습니다. 고객은 여전히 ​​Microsoft Hosted Agent에 대해 전체 지역을 허용해야합니다 ._

사실, 제대로 읽지 않았습니다 😓

나는이 같은 문제에 직면하고 있으며이 문제가 종결되었다는 사실에 솔직히 놀랐습니다. 내 첫 번째 생각은 여기 에서 모든 IP 범위를 사용하여 주간 JSON 파일을 구문 분석하는 예약 된 도구를 구축해야한다는 것이었지만 API를 제공하지 않는 것 같습니다. 그래서 가장 좋은 방법은 매주 JSON 파일을 수동으로 다운로드하고 일부 구문 분석 프로세스에 제공 한 다음 IP 범위를 푸시하여 스토리지 계정 방화벽 설정을 허용하는 것입니까? 확실히 더 나은 방법이 있습니다. 어서 마이크로 소프트!

API가 있지만 작동하지 않습니다 (오래된 방식).
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 파일을 가져 오기 위해 웹 페이지를 긁어내는 것이 불편합니다. 이것은 프로덕션 앱이며 너무 위험합니다. 그 외에도이 방법은 스토리지 계정 방화벽에 수백 개의 항목을 포함하여 호스팅 된 Azure 파이프 라인이 몇 개의 파일을 복사하도록합니다. 할 수 있지만 내 목적에는 과잉입니다.

여러분, 오늘 여러분의 투표를 간청하기 위해 여러분을 모았습니다! -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

이 문제는 최대한 빨리 수정해야합니다. 지난 2 년 동안 계속되는 문제입니다. 공유하고, 트윗하고, 수정하고, Microsoft의 레이더에 올리세요.

아담스 - MSFT @XiaoningLiu @tabeth @sesispla @SeiketsuJael @artisticcheese @cbrooksmsft @nickforr @ SumanthMarigowda - MSFT @solaomoDevOps @shahiddev @ 마르신-VT @goblinfactory @artisticcheese @lymedo @ felipecruz91 @pratimvengurlekar @justinimel @ 마르신-VT @ @mimckitt @renattomachado 뿡뿡

@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

트윗 담아 가기

나는 Windows 에이전트를 사용하고 있으며 에이전트의 IP 주소가 서비스 태그의 IP 주소 목록에 있는지 확인하지 않기로 결정했습니다. 내 파이프 라인에 추가 한 단계는 다음과 같습니다.

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 에서 찾은 IP를 확인하지 않으면 해킹되지 않았다고 가정합니다. 프로덕션 환경에주의하세요!

@arkiaconsulting 확실히 위험하지만 내 특정 사용 사례에서는 문제가 아닙니다. 배포는 항상 "감독"됩니다. 발생할 수있는 최악의 상황은 배포 단계가 실패하는 것입니다. 이 경우 :

1. 이메일 알림이 발송됩니다.
2. IP는 배포 단계의 성공에 의존하지 않고 즉시 제거됩니다.

슬프게도 https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html. 폐쇄되었습니다. 재개를 고려하여 문제를 조사하기를 바랍니다.

나는이 스레드를 주시하지 않고있다 ... 그것은 너무 오래되었지만 여전히 문제이다. 나는 이것이 "폐쇄"로 표시되어야한다고 생각하지 않는다 ... 나는 논평을 자제 할 것이다 ... 그러나 삶은 계속되어야한다 ... 그래서 ... 아래는 내가 사용하고있는 해결 방법이다. 나를 위해 잘 작동하는 것 같습니다.

• 저장 키 사용
• 사용 * az storage blob upload-batch *
• 모든 것을 powershell에서 수행

이 접근 방식은 당신에게 적합하지 않을 수 있지만 지금까지 모든 devops 파이프 라인에서 저에게 적합한 샘플 powershell 스크립트가있는 경우를 대비하여 실험 해보고 파이프 라인에서도 작동하는지 확인할 수 있습니까?

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

이 powershell의 장점은 devops 빌드 에이전트에서 실행되는 것과 똑같이 로컬에서 실행할 수 있다는 것입니다. 로컬에서 실행할 때 쉽게 조정할 수 있습니다.

유용하길 바랍니다.

행운을 빌어 요

문안 인사

앨런

이것은 여전히 ​​문제입니다. 이것을 다시여십시오.