Merci pour les commentaires! Nous étudions actuellement et vous tiendrons au courant sous peu.

Votez pour ça! Plages d'adresses IP de l'hôte Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

Votez pour ça! Plages d'adresses IP de l'hôte Azure Pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=vsts&tabs=yaml#agent -ip-ranges

@XiaoningLiu ce n'est pas habituel.

@renattomachado

Je suis également tombé sur ce problème particulier. Si votre application n'est pas critique (c'est-à-dire que même une seconde d'accès public pourrait paralyser votre entreprise), je recommande ce qui suit:

1. Définissez vos paramètres de pare-feu dans Azure pour votre compte de stockage.
2. Dans votre version (ou build), définissez votre autorisation pour votre compte de stockage sur tous les réseaux par programme, comme suit (cela utilise Azure CLI, mais vous pouvez faire de même avec Powershell).

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

1. Faites tout ce que vous devez faire pour accéder à votre compte de stockage.
2. Réinitialisez immédiatement les paramètres réseau sur Refuser. Lorsqu'il est réglé sur Refuser, il respectera vos paramètres précédemment configurés à l'étape 1.

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

J'espère que cela vous aidera.

@XiaoningLiu

Existe-t-il un moyen d'obtenir la plage IP / l'adresse IP publique? J'ai simplement essayé d'utiliser curl sur https://ipecho.net/ et d'ajouter cette adresse IP (le tout dans une tâche dans un pipeline), mais cela ne semble pas vraiment fonctionner. Idéalement, nous pourrions simplement obtenir la plage d'adresses IP de l'agent que nous utilisons, l'ajouter à la liste blanche et la supprimer immédiatement. De cette façon, nous n'avons pas à exécuter une sorte de travail qui analyse l'ensemble hebdomadaire d'adresses IP pour notre (nos) région (s).

Même problème ici. Utilisation d'Azure DevOps pour déployer des ressources Azure avec Terraform. En raison des exigences de sécurité, nous devons activer les règles de pare-feu VNET. Dès que nous l'activons, Terraform n'est pas en mesure de récupérer les informations de compte de stockage (403) à partir d'Azure DevOps et le pipeline de déploiement est interrompu.

"Autoriser les services Microsoft de confiance à accéder à ce compte de stockage" est activé, mais il est évident qu'Azure DevOps n'est pas reconnu comme tel ...

Y a-t-il des nouvelles sur celui-ci? nous voulons que nos comptes de stockage soient sécurisés, mais nous voulons également déployer et utiliser des pipelines DevOps. et avoir les mêmes problèmes que tout le monde ici.

Voici comment savoir quelles sont les plages IP. https://visualstudio.microsoft.com/team-services/support/ip-addresses-used-hosted-build/

@artisticcheese

Je pense que le problème est que l'utilisation de ce XML nécessiterait alors une automatisation ou un processus qui maintienne la liste noire et supprime les anciennes adresses IP.

Idéalement, il y aurait un moyen d'obtenir l'adresse IP de la machine que vous utilisez lors de l'exécution d'un agent hébergé, de cette façon vous pouvez faire quelque chose de similaire à ce que j'ai décrit ci-dessus, sauf pour une seule machine (celle exécutant le travail DevOps) .

Oui, en plus de ce pare-feu semble être limité à 100 entrées seulement de toute façon, donc cela ne fonctionnera pas.

Nous travaillons sur un plan pour activer les définitions "tag" ou "alias" pour permettre à ces types de plages d'être définis par le service. pas encore ETA.

s'il vous plait fermer

Pourquoi ce problème est-il clos alors qu'il n'a pas été résolu?
«... travailler sur un plan ... ne résout pas vraiment le problème.

@nickforr Depuis que nous y travaillons. Je n'ai pas encore d'ETA à ce sujet,

Vous rencontrez actuellement le même problème, existe-t-il une mise à jour maintenant?

@ SumanthMarigowda-MSFT ou @cbrooksmsft - Existe-t-il un moyen de suivre la demande de fonctionnalité relative à cela - même si vous n'êtes pas à l'aise pour partager un ETA, il serait utile d'être informé lorsque cela a été fait.
Merci!

Semblable à ce que @tabeth suggère , dans de nombreux cas, j'ai changé les règles de pare-feu de différentes ressources (sql, function app et.c) pour autoriser temporairement le trafic depuis l'IP de l'agent devops. Cependant, cela ne fonctionne pas pour les comptes de stockage, pour cette raison:

Les règles de réseau IP n'ont aucun effet sur les demandes provenant de la même région Azure que le compte de stockage.

@cbrooksmsft Pouvez-vous expliquer pourquoi vous avez demandé que ce problème soit fermé? C'est toujours cassé. Si ce problème a été soulevé au mauvais endroit, pouvez-vous fournir un lien vers l'endroit où le bogue de remplacement a été soulevé qui suit ce problème afin qu'il soit résolu?

Ce problème a été soulevé le 24 novembre 2018. Il est possible qu'il ait été demandé par erreur de le fermer sans créer le problème de remplacement correct? Je demande parce que nous sommes maintenant dans 2 ans et il semble que ce bogue existe toujours?

Les solutions de contournement suggérées ici (consistant simplement à supprimer la sécurité) pourraient mettre en danger les données des clients.

s'il vous plaît donnez votre avis,

txs
Alan

Ils semblaient prévoir de l'avoir au deuxième trimestre 2020
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

@artisticcheese vous a lié à une annonce très large. Selon vous, quelle partie de cette annonce résout ce problème? Si vous voulez dire «balises de service», alors je ne le fais pas, cela résout le problème? Les balises de service ressemblent à un regroupement utile de règles par "balise", et le problème décrit ici existerait toujours. (spécifiquement que le devops local d'Azure n'est pas automatiquement mis sur la liste blanche par l'inclusion de --bypass "Logging Metrics AzureServices Peut-être ai-je manqué quelque chose?

Pour récapituler pour toute personne nouvelle sur ce fil; lorsque je crée une ressource de stockage azure à utiliser dans le pipeline azure devops comme ci-dessous

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 j'ai une étape dans mon pipeline azure devops qui utilise 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

alors cela échouera avec une erreur d'autorisation,

Échec de la validation de la destination. Le serveur distant a renvoyé une erreur: (403) Interdit.

Quand en fait (si l'on en croit la documentation), l'utilisation de --bypass AzureServices lors de la création du compte de stockage est censée fournir à azuredevops l'autorisation du compte de stockage.

Je crois que c'est le nœud du problème, et rien dans l'annonce du deuxième trimestre 2020 ne semble aborder ce problème spécifique?

J'adorerais me tromper là-dessus.
UNE

Ils semblaient prévoir de l'avoir au deuxième trimestre 2020
https://devblogs.microsoft.com/devops/azure-devops-roadmap-update-for-2020-q2/

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

Pas sûr que ce soit prévu. Il indique spécifiquement: Le numéro de service pour les agents hébergés Microsoft pour les pipelines n'est pas pris en charge.

Je rencontre également le même problème. N'importe qui pourrait officiellement confirmer que cela est toujours prévu?

Je ne parviens pas à connecter l'agent hébergé Microsoft du pipeline Azure Devops au compte de stockage. Est-ce que ça va être résolu

@cbrooksmsft pouvez-vous s'il vous plaît répondre aux questions ci-dessus? vous avez demandé de fermer le problème mais cela ne semble pas être résolu?
Si cela a été résolu, il serait prudent (professionnel) de la part de Microsoft au moins de commenter ici pour dire: "hé les gars, c'est réglé en faisant X".

Même problème

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

Référence aux modifications à venir pour les balises de service. Cela ne résout toujours pas notre problème:

_Le numéro de service ne s'applique pas aux agents hébergés Microsoft. Les clients doivent toujours autoriser l'intégralité de la géographie pour les agents hébergés Microsoft.

Référence aux modifications à venir pour les balises de service. Cela ne résout toujours pas notre problème:

_Le numéro de service ne s'applique pas aux agents hébergés Microsoft. Les clients doivent toujours autoriser l'intégralité de la géographie pour les agents hébergés Microsoft.

Référence aux modifications à venir pour les balises de service. Cela ne résout toujours pas notre problème:

_Le numéro de service ne s'applique pas aux agents hébergés Microsoft. Les clients doivent toujours autoriser l'intégralité de la géographie pour les agents hébergés Microsoft.

Référence aux modifications à venir pour les balises de service. Cela ne résout toujours pas notre problème:

_Le numéro de service ne s'applique pas aux agents hébergés Microsoft. Les clients doivent toujours autoriser l'intégralité de la géographie pour les agents hébergés Microsoft.

C'est vrai, je ne l'ai pas lu correctement 😓

Je rencontre le même problème et je suis franchement surpris que ce problème soit résolu. Ma première pensée a été que je vais devoir créer un outil planifié pour analyser leur fichier JSON hebdomadaire ici avec toutes les plages IP, mais ils ne semblent pas fournir d'API pour cela. Ma meilleure option est donc de télécharger manuellement le fichier JSON chaque semaine, de le transmettre à un processus d'analyse, puis de pousser les plages IP pour autoriser (nous parlons des centaines) les paramètres du pare-feu du compte de stockage? Il y a sûrement une meilleure façon. Allez Microsoft!

Il y a une API, cela ne fonctionne tout simplement pas (très obsolète)
https://docs.microsoft.com/en-us/rest/api/virtualnetwork/servicetags/list

De plus, il est plus ou moins facile à automatiser (téléchargement / analyse de fichiers JSON, etc.)
https://artisticcheese.wordpress.com/2020/08/17/automating-azure-sql-firewall-rules-based-on-azure-service-tags/

@artisticcheese , merci pour l'info. Pensées intéressantes, mais je ne suis pas à l'aise de gratter leur page Web pour extraire ce fichier JSON. Ceci est une application de production et c'est trop risqué. Et à part cela, cette méthode impliquerait des centaines d'entrées dans le pare-feu du compte de stockage pour laisser simplement mon pipeline Azure hébergé copier quelques fichiers. C'est faisable, mais c'est exagéré pour mes besoins.

Messieurs, je vous ai réunis ici aujourd'hui pour plaider pour votre vote! -> https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html

Cela doit être corrigé dès que possible, c'est un problème récurrent depuis deux ans ... partagez, tweetez, aidez à le résoudre et mettez-le sur le 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 a voté

Pour contourner le problème, voici une tâche que j'utilise ...

- 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

Je pense que oui, j'utilise un agent Windows et j'ai choisi de ne pas vérifier si l'adresse IP de l'agent est dans la liste des adresses IP dans l'étiquette de service. Voici l'étape que j'ai ajoutée à mon 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)'

J'utilise alors

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

avant d'essayer de publier sur le compte de stockage et après avoir terminé la publication, j'utilise

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 vous ne vérifiez pas l'IP trouvée par ipinfo, vous supposez qu'elle n'a pas été piratée ... Attention à l'environnement de production!

@arkiaconsulting Certainement un risque, mais dans mon cas d'utilisation spécifique, ce n'est pas un problème. Les déploiements sont toujours «supervisés». La pire chose qui puisse arriver est l'échec de l'étape de déploiement. Dans ce cas:

1. Une alerte email est envoyée
2. L'adresse IP est supprimée immédiatement sans aucune dépendance sur le succès de l'étape de déploiement

Malheureusement, ce https://developercommunity.visualstudio.com/content/problem/1189404/azuredevops-dont-considerate-as-microsoft-services.html. a été fermé. J'espère qu'ils envisageront de rouvrir et d'examiner la question.

Je n'ai pas gardé un œil sur ce fil ... c'est tellement vieux, et pourtant c'est toujours un problème. Je ne pense pas que ce soit juste que cela devrait être marqué comme "fermé" ... je m'abstiendrai de commenter ... mais la vie doit continuer ... alors ... voici une solution de contournement que j'utilise, que semble bien fonctionner pour moi, c'est-à-dire

• utiliser une clé de stockage
• et utilisez * az storage blob upload-batch *
• tout faire dans PowerShell

cette approche peut ne pas fonctionner pour vous, mais juste au cas où elle le ferait, voici un exemple de script PowerShell qui fonctionne pour moi dans n'importe quel pipeline devops jusqu'à présent, vous pouvez l'expérimenter et voir si cela fonctionne également dans votre pipeline?

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

l'avantage de ce powershell est que vous pouvez l'exécuter localement exactement de la même manière que sur l'agent de compilation devops. plus facile à modifier lors de l'exécution locale.

j'espère utile.

bonne chance

Cordialement

Alan

C'est toujours un problème. Veuillez le rouvrir.