¡Gracias por la respuesta! Actualmente estamos investigando y lo actualizaremos en breve.

¡Vota por esto! Rangos de IP de host de Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

¡Vota por esto! Rangos de IP de host de Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

@XiaoningLiu eso no es habitual.

@renattomachado

También me encontré con este problema en particular. Si su aplicación no es de misión crítica (es decir, incluso un segundo de acceso público podría paralizar su negocio), le recomiendo lo siguiente:

1. Establezca la configuración de su firewall en Azure para su cuenta de almacenamiento.
2. En su versión (o compilación) establezca su permiso para su cuenta de almacenamiento en todas las redes mediante programación, como el siguiente (esto usa la CLI de Azure, pero podría hacer lo mismo con Powershell).

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

1. Haga lo que sea necesario para acceder a su cuenta de almacenamiento.
2. Restablezca inmediatamente la configuración de red a Denegar. Cuando se establece en Denegar, respetará la configuración que se configuró previamente en el Paso 1.

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

Espero que eso te ayude.

@XiaoningLiu

¿Hay alguna forma de obtener el rango de IP / IP pública? Intenté usar curl en https://ipecho.net/ y agregar esa IP (todo en una tarea mientras estaba en una tubería), pero parece que realmente no funciona. Idealmente, podríamos obtener el rango de IP del agente que estamos usando, agregarlo a la lista blanca y simplemente eliminarlo de inmediato. De esa manera, no tenemos que ejecutar algún tipo de trabajo que analice el conjunto semanal de direcciones IP para nuestra (s) región (es).

El mismo problema aquí. Uso de Azure DevOps para implementar recursos de Azure con Terraform. Debido a los requisitos de seguridad, debemos activar las reglas de firewall de VNET. Tan pronto como lo activamos, Terraform no puede recuperar la información de la cuenta de almacenamiento (403) de Azure DevOps y la canalización de implementación se interrumpe.

"Permitir que los servicios de Microsoft de confianza accedan a esta cuenta de almacenamiento" está habilitado, pero obviamente Azure DevOps no se reconoce como tal ...

¿Hay alguna novedad sobre este? queremos que nuestras cuentas de almacenamiento estén protegidas, pero también queremos implementar y utilizar DevOps Pipelines. y tener los mismos problemas que todos los demás aquí.

Aquí se explica cómo averiguar qué rangos de IP son. https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

@artistico

Creo que el problema es que el uso de ese XML requeriría que uno tenga alguna automatización o proceso que mantenga la lista negra y elimine las IP antiguas.

Idealmente, habría una forma de obtener la IP de la máquina que está utilizando mientras ejecuta un agente alojado, de esa manera puede hacer algo similar a lo que describí anteriormente, excepto para una sola máquina (la que ejecuta el trabajo de DevOps) .

Sí, además de que el firewall parece estar limitado a 100 entradas de todos modos, así que esto no va a funcionar.

Estamos trabajando en un plan para habilitar definiciones de "etiqueta" o "alias" para permitir que este tipo de rangos sean definidos por el servicio. aún no ETA.

por favor cierra

¿Por qué se cierra este problema cuando no se ha abordado?
'... trabajar en un plan ... realmente no se ocupa del problema.

@nickforr Ya que estamos trabajando en ello. Aún no tengo una ETA sobre esto,

Actualmente experimenta el mismo problema, ¿hay alguna actualización ahora?

@ SumanthMarigowda-MSFT o @cbrooksmsft : ¿hay alguna forma de rastrear la solicitud de función relacionada con esto? Incluso si no se siente cómodo compartiendo una ETA, sería útil recibir una notificación cuando se haya realizado.
¡Gracias!

De manera similar a lo que sugirió @tabeth, en muchos casos estaba cambiando las reglas del firewall de diferentes recursos (sql, function app et.c) para permitir temporalmente el tráfico desde la ip del agente devops. Sin embargo, esto no funciona para las cuentas de almacenamiento, debido a esto :

Las reglas de red IP no tienen ningún efecto en las solicitudes que se originan en la misma región de Azure que la cuenta de almacenamiento.

@cbrooksmsft ¿Puede explicar por qué pidió que se cerrara este problema? Esto todavía está roto. Si este problema se planteó en el lugar incorrecto, ¿puede proporcionar un enlace al lugar donde se ha planteado el error de reemplazo que está rastreando este problema para que se resuelva?

Este problema se planteó el 24 de noviembre de 2018. ¿Es posible que se haya solicitado por error que se cierre sin crear el problema de reemplazo correcto? Pregunto porque ahora estamos 2 años después y parece que este error todavía existe.

Las soluciones alternativas sugeridas aquí (de simplemente eliminar la seguridad) podrían poner en riesgo los datos del cliente.

por favor avise,

txs
Alan

Parecían estar planeando tenerlo en el 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 te vinculó a un anuncio muy amplio. ¿Qué parte de ese anuncio crees que aborda este problema? Si te refieres a "etiquetas de servicio", ¿entonces no soluciono el problema? Las etiquetas de servicio parecen una agrupación útil de reglas por "etiqueta", y el problema que se describe aquí seguiría existiendo. (específicamente que el devops azul local no se incluye automáticamente en la lista blanca mediante la inclusión de --bypass "Logging Metrics AzureServices Quizás me he perdido algo?

Para recapitular para cualquier persona nueva en este hilo; cuando creo un recurso de almacenamiento azul para usar en la canalización devops azul como se muestra a continuación

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" 

si tengo un paso en mi canalización 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

entonces esto fallará con un error de permiso,

No se pudo validar el destino. El servidor remoto devolvió un error: (403) Prohibido.

Cuando, de hecho (si se supone que se debe creer en la documentación) usar --bypass AzureServices al crear la cuenta de almacenamiento, se supone que proporciona a azuredevops permiso para la cuenta de almacenamiento.

Creo que este es el meollo del problema, y ​​¿nada en el anuncio del segundo trimestre de 2020 parece abordar este problema específico?

Me encantaría equivocarme en esto.
UN

Parecían estar planeando tenerlo en el 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

No estoy seguro de que esté planeado. Indica específicamente: No se admiten las etiquetas de servicio para agentes alojados de Microsoft para canalizaciones.

También me pasa el mismo problema. ¿Alguien podría confirmar oficialmente que esto todavía está planeado?

No puedo conectar el agente alojado de Microsoft de la canalización de Azure Devops a la cuenta de almacenamiento. ¿Esto se va a resolver?

@cbrooksmsft , ¿puede responder a las preguntas anteriores? solicitó cerrar el problema, pero esto no parece resolverse?
Si realmente se ha resuelto, sería considerado (profesional) por parte de Microsoft al menos comentar aquí para decir, "Hola chicos, esto se soluciona haciendo X".

Mismo problema

Para su información: https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

Referencia a los próximos cambios para las etiquetas de servicio. Esto todavía no resuelve nuestro problema:

_La etiqueta de servicio no se aplica a los agentes alojados de Microsoft. Los clientes todavía deben permitir la geografía completa para los agentes alojados de Microsoft.

Referencia a los próximos cambios para las etiquetas de servicio. Esto todavía no resuelve nuestro problema:

_La etiqueta de servicio no se aplica a los agentes alojados de Microsoft. Los clientes todavía deben permitir la geografía completa para los agentes alojados de Microsoft.

Referencia a los próximos cambios para las etiquetas de servicio. Esto todavía no resuelve nuestro problema:

_La etiqueta de servicio no se aplica a los agentes alojados de Microsoft. Los clientes todavía deben permitir la geografía completa para los agentes alojados de Microsoft.

Referencia a los próximos cambios para las etiquetas de servicio. Esto todavía no resuelve nuestro problema:

_La etiqueta de servicio no se aplica a los agentes alojados de Microsoft. Los clientes todavía deben permitir la geografía completa para los agentes alojados de Microsoft.

Es cierto, no lo leí correctamente 😓

Me estoy encontrando con el mismo problema y, francamente, me sorprende que este problema se haya cerrado. Lo primero que pensé fue que tendré que crear una herramienta programada para analizar su archivo JSON semanal aquí con todos los rangos de IP, pero no parecen proporcionar una API para eso. Entonces, mi mejor opción es descargar manualmente el archivo JSON cada semana, alimentarlo a algún proceso de análisis y luego presionar los rangos de IP para permitir (estamos hablando de cientos) en la configuración del firewall de la cuenta de almacenamiento. Seguro que hay una forma mejor. ¡Vamos Microsoft!

Hay API, simplemente no funciona (muy desactualizado)
https://docs.microsoft.com/en-us/rest/api/virtualnetwork/servicetags/list

Además, es más o menos fácil de automatizar (descargar / analizar archivos JSON, etc.)
https://artisticcheese.wordpress.com/2020/08/17/automating-azure-sql-firewall-rules-based-on-azure-service-tags/

@artisticcheese , gracias por la información. Pensamientos interesantes, pero no me siento cómodo raspando su página web para extraer ese archivo JSON. Esta es una aplicación de producción y eso es demasiado arriesgado. Y aparte de eso, este método implicaría cientos de entradas en el firewall de la cuenta de almacenamiento para permitir que mi canalización de Azure alojada copie algunos archivos. Es factible, pero es exagerado para mis propósitos.

Caballeros, ¡los he reunido hoy aquí para suplicar su voto! -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

Esto debe arreglarse lo antes posible, es un problema continuo durante los últimos dos años ... compartir, tuitear, ayudar a solucionarlo y ponerlo en el radar de 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 @gradyal

@BobbyCGD Votado

Como solución temporal, aquí hay una tarea que utilizo ...

- 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

Creo que sí, estoy usando un agente de Windows y he optado por no verificar si la dirección IP del agente está en la lista de direcciones IP en la etiqueta de servicio. Este es el paso que agregué a mi canalización

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

Entonces 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 intentar publicar en la cuenta de almacenamiento y después de terminar de publicar, 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 Si no verifica la IP encontrada por ipinfo, asume que no ha sido pirateada ... ¡Tenga cuidado con el entorno de producción!

@arkiaconsulting Definitivamente es un riesgo, pero en mi caso de uso específico no es un problema. Las implementaciones son siempre "supervisadas". Lo peor que podría suceder es que el paso de implementación falle. En este caso:

1. Se envía una alerta por correo electrónico
2. La IP se elimina de inmediato sin depender del éxito del paso de implementación

Lamentablemente este https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html. ha sido cerrado. Con suerte, considerarán reabrir y analizar el problema.

No he estado vigilando este hilo ... es demasiado antiguo y, sin embargo, sigue siendo un problema. No creo que sea correcto, esto debería estar marcado como "cerrado" ... Me abstendré de comentar ... pero la vida tiene que continuar ... así que ... a continuación hay una solución que estoy usando, que parece estar funcionando bien para mí, es decir

• usar una clave de almacenamiento
• y use * az storage blob upload-batch *
• hazlo todo en powershell

Este enfoque puede no funcionar para usted, pero en caso de que lo haga, aquí hay un script de PowerShell de muestra que me funciona en cualquier canal de DevOps hasta ahora, ¿puede experimentar con él y ver si también funciona en su canal de distribución?

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

la ventaja de este PowerShell es que puede ejecutarlo localmente exactamente de la misma manera que se ejecuta en el agente de compilación devops. más fácil de modificar cuando se ejecuta localmente.

con suerte útil.

la mejor de las suertes

Saludos

Alan

Esto sigue siendo un problema. Vuelva a abrir esto.