Obrigado pelo feedback! No momento, estamos investigando e atualizaremos você em breve.

Vote nisso! Intervalos de IP do host do Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

Vote nisso! Intervalos de IP do host do Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

@XiaoningLiu isso não é normal.

@renattomachado

Também me deparei com esse problema específico. Se seu aplicativo não for de missão crítica (ou seja, até mesmo um segundo de acesso público pode prejudicar seu negócio), eu recomendo o seguinte:

1. Defina suas configurações de firewall no Azure para sua conta de armazenamento.
2. Em sua versão (ou compilação), defina sua permissão para sua conta de armazenamento para todas as redes programaticamente, como a seguir (isso usa a CLI do Azure, mas você pode fazer o mesmo usando o Powershell).

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

1. Faça o que for necessário para acessar sua conta de armazenamento.
2. Redefina imediatamente as configurações de rede para Negar. Quando definido como Negar, respeitará suas configurações que foram configuradas anteriormente na Etapa 1.

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

Espero que isso ajude você.

@XiaoningLiu

Existe uma maneira de obter o intervalo de IP / IP público? Tentei apenas usar curl em https://ipecho.net/ e adicionar esse IP (tudo em uma tarefa enquanto em um pipeline), mas parece não funcionar realmente. Idealmente, poderíamos apenas obter o intervalo de IP do Agente que estamos usando, adicioná-lo à lista de permissões e apenas removê-lo imediatamente. Dessa forma, não precisamos executar algum tipo de trabalho que analise o conjunto semanal de IPs para nossa (s) região (ões).

Mesmo problema aqui. Usando o Azure DevOps para implantar recursos do Azure com o Terraform. Devido aos requisitos de segurança, precisamos ativar as regras de firewall VNET. Assim que o ativamos, o Terraform não consegue recuperar as informações da conta de armazenamento (403) do Azure DevOps e o pipeline de implantação é interrompido.

"Permitir que serviços confiáveis ​​da Microsoft acessem esta conta de armazenamento" está habilitado, mas obviamente o Azure DevOps não é reconhecido como tal ...

Há alguma notícia sobre este? Queremos que nossas contas de armazenamento sejam protegidas, mas também queremos implantar e usar DevOps Pipelines. e tendo os mesmos problemas que todos os outros aqui.

Veja como descobrir quais são os intervalos de IP. https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

@artisticcheese

Acho que o problema é que o uso desse XML exigiria alguma automação ou processo que mantém a lista negra e remove IPs antigos.

Idealmente, haveria uma maneira de obter o IP da máquina que você está usando ao executar um agente hospedado, dessa forma, você pode fazer algo semelhante ao que descrevi acima, exceto para uma única máquina (aquela que executa o trabalho DevOps) .

Sim, além disso, o firewall parece estar limitado a apenas 100 entradas de qualquer maneira, então isso não vai funcionar.

Estamos trabalhando em um plano para habilitar as definições de "tag" ou "alias" para permitir que esses tipos de intervalos sejam definidos pelo serviço. ainda não ETA.

feche por favor

Por que este problema está sendo resolvido se não foi resolvido?
'... trabalhar em um plano ... não é realmente lidar com o problema.

@nickforr Já que estamos trabalhando nisso. Eu não tenho um ETA sobre isso ainda,

Atualmente com o mesmo problema, há alguma atualização agora?

@ SumanthMarigowda-MSFT ou @cbrooksmsft - Existe alguma maneira de rastrear a solicitação de recurso relacionada a isso - mesmo que você não se sinta confortável em compartilhar um HEC, seria útil ser notificado quando estiver concluído.
Obrigado!

Semelhante ao que @tabeth sugere, em muitos casos eu estava alterando regras de firewall de diferentes recursos (sql, app de função et.c) para permitir temporariamente o tráfego do ip do agente devops. No entanto, isso não está funcionando para contas de armazenamento, devido ao seguinte :

As regras de rede IP não têm efeito nas solicitações originadas da mesma região do Azure que a conta de armazenamento.

@cbrooksmsft Você pode explicar por que solicitou o encerramento deste problema? Isso ainda está quebrado. Se este problema foi levantado no local errado, então você pode fornecer um link para onde o bug de substituição foi levantado que está rastreando este problema para que seja resolvido?

Este problema foi levantado em 24 de novembro de 2018. É possível que tenha sido solicitado por engano para ser fechado sem criar o problema de substituição correto? Eu pergunto porque agora estamos 2 anos na linha e parece que esse bug ainda existe?

As soluções alternativas sugeridas aqui (de simplesmente remover a segurança) podem colocar os dados do cliente em risco.

Por favor informar,

txs
Alan

Eles pareciam estar planejando tê-lo no segundo trimestre de 2020
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

@artisticcheese você vinculou a um anúncio muito amplo. Que parte desse anúncio você acha que aborda esse problema? Se você quer dizer "etiquetas de serviço", isso não aborda o problema? As tags de serviço parecem um agrupamento útil de regras por "tag", e o problema descrito aqui ainda existiria. (especificamente que os desenvolvedores azuis locais não são incluídos automaticamente na lista de permissões com a inclusão de --bypass "Logging Metrics AzureServices Talvez eu tenha esquecido alguma coisa?

Para recapitular para alguém novo neste tópico; quando eu crio um recurso de armazenamento azure para uso no pipeline de devops azure como abaixo

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" 

se eu tiver uma etapa no meu pipeline de devops azul que usa AzureFileCopy@3 eg

    - 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

então isso irá falhar com erro de permissão,

Falha ao validar o destino. O servidor remoto retornou um erro: (403) Proibido.

Quando, de fato (se é que se acredita na documentação), o uso de --bypass AzureServices ao criar a conta de armazenamento deve fornecer ao azuredevops permissão para a conta de armazenamento.

Acredito que esse seja o ponto crucial do problema, e nada no anúncio do segundo trimestre de 2020 parece resolver esse problema específico.

Eu adoraria estar errado nisso.
UMA

Eles pareciam estar planejando tê-lo no segundo trimestre de 2020
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

Não tenho certeza se está planejado. Ele declara especificamente: Não há suporte para etiquetas de serviço para agentes hospedados pela Microsoft para pipelines.

Eu também tenho o mesmo problema. Alguém pode confirmar oficialmente que isso ainda está planejado?

Não consigo conectar o agente hospedado da Microsoft do pipeline Devops do Azure à conta de armazenamento. Isso vai ser resolvido

@cbrooksmsft pode responder às perguntas acima? você pediu para fechar o problema, mas isso não parece estar resolvido?
Se realmente foi resolvido, seria considerado (profissional) da Microsoft pelo menos comentar aqui e dizer: "Ei pessoal, isso é consertado fazendo X".

O mesmo problema

Para sua informação: https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

Referência às próximas mudanças para etiquetas de serviço. Isso ainda não resolve nosso problema:

_A etiqueta de serviço não se aplica aos agentes hospedados da Microsoft. Os clientes ainda precisam permitir toda a geografia dos Agentes Hospedados da Microsoft._

Referência às próximas mudanças para etiquetas de serviço. Isso ainda não resolve nosso problema:

_A etiqueta de serviço não se aplica aos agentes hospedados da Microsoft. Os clientes ainda precisam permitir toda a geografia dos Agentes Hospedados da Microsoft._

Referência às próximas mudanças para etiquetas de serviço. Isso ainda não resolve nosso problema:

_A etiqueta de serviço não se aplica aos agentes hospedados da Microsoft. Os clientes ainda precisam permitir toda a geografia dos Agentes Hospedados da Microsoft._

Referência às próximas mudanças para etiquetas de serviço. Isso ainda não resolve nosso problema:

_A etiqueta de serviço não se aplica aos agentes hospedados da Microsoft. Os clientes ainda precisam permitir toda a geografia dos Agentes Hospedados da Microsoft._

Verdade, não li direito 😓

Estou tendo o mesmo problema e estou francamente surpreso que ele tenha sido resolvido. Meu primeiro pensamento foi que terei que construir uma ferramenta programada para analisar seu arquivo JSON semanal aqui com todos os intervalos de IP, mas eles não parecem fornecer uma API para isso. Portanto, minha melhor opção é baixar manualmente o arquivo JSON toda semana, alimentá-lo para algum processo de análise e, em seguida, enviar os intervalos de IP para permitir (estamos falando de centenas) para as configurações de firewall da conta de armazenamento. Certamente existe uma maneira melhor. Vamos, Microsoft!

Existe API, simplesmente não funciona (muito desatualizado)
https://docs.microsoft.com/en-us/rest/api/virtualnetwork/servicetags/list

Além disso, é mais ou menos fácil de automatizar (download / análise de arquivos JSON, etc.)
https://artisticcheese.wordpress.com/2020/08/17/automating-azure-sql-firewall-rules-based-on-azure-service-tags/

@artisticcheese , obrigado pela informação. Pensamentos interessantes, mas não me sinto confortável em raspar sua página da Web para puxar esse arquivo JSON. Este é um aplicativo de produção e é muito arriscado. Além disso, esse método envolveria centenas de entradas no firewall da conta de armazenamento para simplesmente permitir que meu pipeline hospedado do Azure copiasse alguns arquivos. É factível, mas é um exagero para meus propósitos.

Senhores, reuni vocês aqui hoje para implorar pelo seu voto! -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

Isso precisa ser consertado o mais rápido possível, é um problema constante nos últimos dois anos ... compartilhe, tweet, ajude a consertar e coloque-o no radar da Microsoft 👍

@renattomachado @mimckitt @ AdamS-MSFT @XiaoningLiu @tabeth @sesispla @SeiketsuJael @artisticcheese @cbrooksmsft @nickforr @ SumanthMarigowda-MSFT @solaomoDevOps @shahiddjust @ marcin-vt @gobecrinuz @felatelv @gobecrlinuz @felatinvt @gobecrinuz @felatinvt @gobecrlinuz @felatinv @gobecrlinuz @felatinv @gobecrinuz @felimvt @gobecrinuz @felimvt @gobecrlinuz @felimvt @gobecrlinuz @gradyal

@BobbyCGD votado

Como solução alternativa, aqui está uma tarefa que uso ...

- 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

Acho que sim, estou usando um agente do Windows e optei por não verificar se o endereço IP do agente está na lista de endereços IP na etiqueta de serviço. Aqui está a etapa que adicionei ao meu pipeline

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

Eu então uso

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

antes de tentar publicar na conta de armazenamento e depois de terminar a publicação, uso

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 Se você não checar o IP encontrado pelo ipinfo, você assume que ele não foi hackeado ... Tenha cuidado com o ambiente de produção!

@arkiaconsulting Definitivamente um risco, mas no meu caso de uso específico não é um problema. As implantações são sempre "supervisionadas", a pior coisa que pode acontecer é uma falha na etapa de implantação. Nesse caso:

1. Um alerta de email é enviado
2. O IP é removido imediatamente, sem dependência do sucesso da etapa de implantação

Infelizmente, isso https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html. foi fechado. Esperançosamente, eles considerarão a reabertura e examinarão o problema.

Não estou de olho neste tópico ... é tão antigo, mas ainda é um problema. Eu não acho que isso deve ser marcado como "fechado" ... Vou abster-me de comentar ... mas a vida tem que continuar ... então ... abaixo está uma solução alternativa que estou usando, que parece estar funcionando bem para mim, ou seja,

• use uma chave de armazenamento
• e use * az storage blob upload-batch *
• Faça tudo em PowerShell

essa abordagem pode não funcionar para você, mas caso funcione, aqui está um script de PowerShell de amostra que funciona para mim em qualquer pipeline de devops até agora. Você pode experimentá-lo e ver se funciona em seu pipeline também.

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

a vantagem deste PowerShell é que você pode executá-lo localmente exatamente da mesma forma que executa no agente de compilação devops. mais fácil de ajustar ao executar localmente.

esperançosamente útil.

boa sorte

Saudações

Alan

Isso ainda é um problema. Por favor, reabra isto.