Azure-docs: Azure DevOps Build Pipeline ne peut pas obtenir de secrets de Key Vault lorsqu'il est sécurisé avec un réseau virtuel et un pare-feu

@ aspnet4you Merci pour vos commentaires.
Nous enquêtons activement et vous répondrons sous peu.

@ KalyanChanumolu-MSFT - Merci d'avoir examiné le problème. Key Vault est un composant d'infrastructure critique et, de par sa nature commerciale, nous ne voulons pas l'exposer à des réseaux non approuvés. Si j'avais construit une machine dans mon évent, cela aurait été bien, mais mon objectif est d'utiliser Azure DevOps pour CI / CD. J'ai besoin de récupérer les clés et les secrets et être en mesure de les récupérer en toute sécurité.

@ aspnet4you , Merci d'avoir partagé la requête. La liste blanche des adresses IP n'est pas un moyen efficace, mais c'est certainement une solution de contournement. Nous travaillons avec l'équipe produit pour obtenir Azure Dev Ops en tant que service de confiance pour Azure Key Vault et ce serait une solution complète dans tous les termes. Permettez-nous un jour et je partagerai mes prochaines mises à jour avec vous.

Vous pouvez ajouter une étape dans la définition de compilation pour ajouter l'adresse IP de l'agent à la liste blanche, puis la supprimer de la liste blanche à la fin de la compilation. Ce n'est pas une solution mais une solution de contournement jusqu'à ce que l'équipe produit Azure ajoute Azure DevOps en tant que service de confiance. Merci à @ Daniel Mann pour cette idée.

La solution est simple mais je n'allais pas faire confiance à ipify.org en tant que point de terminaison de l'API REST pour obtenir l'adresse IP de mon agent de construction. Au lieu de cela, j'ai créé mon propre service (et de confiance) sur Azure Function - GetClientIP. DevOps n'est pas mon travail quotidien et j'avais du mal à comprendre comment attribuer et utiliser des variables définies par l'utilisateur et les transmettre à l'étape / tâche / étape suivante du pipeline! La documentation Microsoft sur l'utilisation des variables ne m'aidait pas assez mais je l'ai compris après de nombreuses exécutions infructueuses!

Consultez la solution complète sur mon blog - Azure DevOps Build Pipeline - utilisez les clés et les secrets de Key Vault .

@ aspnet4you , Il y a des discussions sur l'obtention d'Azure DevOps en tant que service de confiance. Azure DevOps a un scénario distinct dans lequel l'identité qui accède à Key Vault appartient au client et non à Microsoft. Cela enfreint les exigences d'évolutivité et de sécurité du «service de confiance».

À l'heure actuelle, la seule solution de contournement semble être d'ajouter les adresses IP des machines DevOps au pare-feu AKV. Il s'agit d'un sous-ensemble plus petit que toutes les adresses IP de Datacenter et correspondra à la limite de 127 règles IP.

Je travaille actuellement sur l'obtention des adresses IP et je mettrai à jour le fil sous peu.

@ aspnet4you , veuillez trouver les détails sur les adresses IP ci-dessous:

Pour la liste blanche des services AzureDevops - https://docs.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops

Pour les agents hébergés sur liste blanche - https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#agent -ip-ranges

J'espère que cela t'aides.

@ aspnet4you ,

@ souravmishra-msft il semble que la liste blanche des services azure devops, les adresses IP dans le lien ne sont pas suffisantes.
Par exemple, en essayant de lier le groupe de variables de devops aux secrets de keyvault, je devais également ajouter l'ip: 52.236.xx (j'ai intentionnellement caché les 2 octets lat). Savez-vous d'où sont ces IP? Pouvez-vous fournir la gamme complète de liens IP pour les groupes de variables devops?

@ aspnet4you , Merci d'avoir partagé la requête. La liste blanche des adresses IP n'est pas un moyen efficace, mais c'est certainement une solution de contournement. Nous travaillons avec l'équipe produit pour obtenir Azure Dev Ops en tant que service de confiance pour Azure Key Vault et ce serait une solution complète dans tous les termes. Permettez-nous un jour et je partagerai mes prochaines mises à jour avec vous.

Une mise à jour sur cette fonctionnalité? Existe-t-il un lien pour suivre la fonctionnalité `` Azure Dev Ops en tant que service de confiance pour Azure Key Vault ''

Même demande pour les autres offres PAAS de point de terminaison de service VNET - https://feedback.azure.com/forums/217298-storage/suggestions/35850511-make-azuredevops-a-trusted-microsoft-services-to

@ aspnet4you , comment la liste blanche de l'adresse IP seule suffit-elle pour obtenir des secrets / clés sans politique d'accès au coffre-fort?

@oviliz - Très bonne question. La liste blanche des adresses IP est l'un des derniers moyens de défense contre l'accès non autorisé au coffre-fort. Le principal du service doit être configuré avec la stratégie d'accès Key Vault pour répertorier et obtenir les clés et les secrets. C'est la deuxième exigence comme indiqué dans mon article - Azure DevOps Build Pipeline - utilisez les clés et les secrets de Key Vault .

Bonjour @ KalyanChanumolu-MSFT des mises à jour? Aujourd'hui, j'ai été confronté au même problème. Je ne peux pas récupérer le secret de mon KV dans l'étape Azure Key Vault dans mon pipeline de publication (Azure DevOps). Les liens avec les adresses IP ci-dessus sont rompus ... Comment puis-je récupérer des secrets dans mon pipeline? Autoriser les services Microsoft de confiance à contourner ce pare-feu? (Oui) - n'a pas aidé aussi.

Je suis également confronté à ce problème et il est clair que les adresses IP doivent être ajoutées à la liste blanche. De plus, cela ouvre notre coffre-fort à des services que nous ne contrôlons pas, je ne suis donc pas satisfait de cette solution.

Et en passant, les articles référencés ci-dessus indiquent que les plages d'adresses IP peuvent changer chaque semaine. Suggérer de mettre à jour le pare-feu chaque semaine et même d'essayer de suivre les changements est assez ridicule.

Je suis confronté au même problème et la liste blanche des adresses IP chaque semaine n'est pas du tout une option.

Serait-il possible d'avoir un agent auto-hébergé pour le pipeline de construction à l'intérieur d'une machine virtuelle, de configurer cette machine virtuelle dans un réseau virtuel, puis de lui autoriser l'accès dans le Key Vault? Je ne suis absolument pas un pro, alors à quel point cette approche est-elle absurde?

FWIW J'ai été inspiré par cette solution ici: https://www.visualstudiogeeks.com/DevOps/PrivateAzureAseV2AppServiceVstsDeploymentUsingAzureDtl

Ajoutez-nous à la liste. Comment se fait-il qu'ADO ne soit pas un service de confiance pour les coffres-forts de clés?

Si vous recherchez dans les fichiers hebdomadaires des devops ou des agents hébergés, aucune ips n'est mise en évidence. Quels ips utilisez-vous dans https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519 ??? et si vous recherchez par Datacenter, il y a des services d'applications, des espaces de développement, etc., mais qu'est-ce qui est en corrélation avec les devops et les agents hôtes?

@ ShaneBala-keyvault, comme demandé, vous ajoutant à ce fil.

Ajoutez-nous à la liste. Comment se fait-il qu'ADO ne soit pas un service de confiance pour les coffres-forts de clés?

Avec vous là-bas, vous cherchez à déplacer de nombreux projets vers AZ Devops, mais c'est un problème

+1, cela devrait être corrigé dès que possible. Même si des variables de pipeline secrètes peuvent être utilisées pour les versions, j'aimerais avoir une seule source de vérité. La valeur de la variable secrète du pipeline ne peut pas être consultée à nouveau après la sauvegarde, donc de toute façon, les informations doivent être stockées ailleurs.

SO question sur ce problème:

https://stackoverflow.com/q/61411653/3850405

+1 c'est vraiment crucial. Un commentaire de Microsoft à ce sujet?

@ souravmishra-msft Cela devrait-il être rouvert peut-être?

@Ogglas Cela devrait certainement être rouvert. Ils doivent répertorier les ips ou baliser le service pour contourner le pare-feu Azure Keyvault. Ils le font pour d'autres services, pourquoi pas azure devops?

+1, même problème ici

+1

se joindre également à la pile sur .. énorme problème pour moi aussi

Comment diable est-ce si proche ???? les liens liens de la "solution de contournement" ne fonctionnent pas non plus :)

@jsburckhardt -
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Avons-nous besoin de créer un nouveau problème pour cela, ou de trouver un moyen de le rouvrir, @ souravmishra-msft?

@captainbrown , j'ai rouvert ce fil. J'ai également mis à jour à nouveau le gestionnaire de programme en interne, car à partir du moment où ce fil a été ouvert initialement, le fil interne a été créé avec l'équipe produit.

J'attribue également ce fil au Gestionnaire de programmes. Il leur faudra peut-être un certain temps pour répondre sur ce fil, car je ne suis pas sûr de la complexité que ce changement pourrait nécessiter du côté du produit.

J'ai également augmenté le thread interne qui se déroule contre ce thread github et je vous tiendrai au courant de la progression.

Je voudrais également signaler que j'ai corrigé les URL mentionnées dans l'un de mes commentaires plus tôt dans ce fil. Vous voudrez peut-être jeter un coup d'œil à ceux-ci également une fois dans l'intervalle et nous faire savoir si ceux-ci fonctionnent pour votre solution et sinon, nous en informer également.

@ souravmishra-msft merci beaucoup d'avoir rouvert ce numéro. Autoriser les plages pour les services devops ne fonctionne pas pour permettre l'accès au keyvault (les plages sont peut-être obsolètes sur le site Web) et la liste des sous-réseaux possibles est entièrement trop longue pour être ajoutée au contrôle d'accès au réseau sur le keyvault.

Mon équipe et moi attendrons avec impatience le mot de votre responsable de programme

Merci d'avoir rouvert ...

D'accord, merci pour la réouverture. C'est un problème que nous aimerions vraiment voir abordé également.

@ souravmishra-msft Merci, j'espère que cela sera bientôt priorisé.

+1, c'est aussi un problème pour nous. Non seulement l'accès Azure DevOps à Key-vault, mais nous avons également besoin du pipeline DevOps pour générer certains fichiers et les télécharger sur un compte de stockage protégé par un pare-feu, mais nous sommes confrontés au même problème, à savoir qu'Azure DevOps n'est pas un service de confiance et la solution de contournement serait de mettre sur liste blanche ~ 250 adresses IP sur une base hebdomadaire, ce qui serait très moche (en plus de ne pas savoir s'il y a une limite quant au nombre d'adresses IP pouvant être ajoutées au pare-feu du compte de stockage). Ce serait formidable si cela peut être résolu!

Il existe actuellement une solution de contournement pour ce problème.

Vous pouvez utiliser un agent auto-hébergé et ajouter les plages IPv4 suivantes à la liste d'autorisation du pare-feu du coffre de clés. Détails ici: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops

(L'équipe Azure DevOps est consciente de ce problème et le travail pour un correctif permanent est actuellement en cours)

Cette fonctionnalité est actuellement en préversion.

Voici un autre travail autour ... vous pouvez configurer votre propre vnet avec un ensemble de balance.

https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/scale-set-agents?view=azure-devops

Une autre astuce ... Je ne m'approprie pas cette astuce, quelqu'un m'a montré.
Si vous avez un compte d'entreprise devops, il existe un moyen d'autoriser les devops à lire les secrets de keyvault pour votre bibliothèque.
Si vous avez un compte personnel, cela ne fonctionne pas.

Vous pouvez ouvrir le pare-feu sur le réseau Azure / 11, configurer la connexion de devops à azure avec le keyvault. Configurez la bibliothèque de variables et ajoutez le secret. Une fois les secrets ajoutés, supprimez la règle de pare-feu et essayez d'ajouter un secret. Le message d'erreur vous transmettra une adresse IP que vous pourrez placer dans le pare-feu. Nous avons constaté qu'elle n'avait pas changé en un mois et nous comprenons qu'elle peut changer. À ce stade, nous recherchons des solutions de contournement comme tout le monde. Je vais faire des tests supplémentaires avec les versions et les versions, mais cela permet à l'interface graphique Native Devops d'interagir directement avec Keyvaults.

Encore une fois, cela ne fonctionne pas avec un compte personnel.

+1, nous avons un problème similaire en utilisant AzDO au serveur SQL via un lien privé / un point de terminaison.

+1 problème similaire ici.

Des solutions de contournement sont fournies ici. Ce n'est pas un problème avec le document lui-même. Il s'agit d'une solution de contournement https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops # please-close vous pouvez également publier une demande de fonctionnalité ici https: // developercommunity.visualstudio.com/spaces/21/index.html

Demande de fonctionnalité ici:

https://developercommunity.visualstudio.com/idea/1152209/azure-devops-build-pipeline-cant-get-secrets-from-1.html

+1, touchez ce problème aujourd'hui.

Si Microsoft va activer les balises de service pour Azure DevOps, peut-il être utilisé d'une manière ou d'une autre sur le pare-feu Keyvault? https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

@ JQUINONES82 Je crains que non pour les agents hébergés. Depuis votre lien:

Le numéro de service ne s'applique pas aux agents hébergés Microsoft.

+1, atteignant ce niveau depuis 2 ans

+1, touchez ce problème aujourd'hui.

Ceci est fermé, alors comment puis-je obtenir le correctif?

La sécurité n'est pas une demande de fonctionnalité, c'est une nécessité pour tout composant cloud. Si ce n'est pas résolu, peut-il être rouvert? J'ai vu mentionné quelque chose en préversion ... Je vais prendre une fonction de prévisualisation. Cela va retarder notre déploiement car je ne veux pas dépenser encore plus d'argent pour faire tourner des machines virtuelles dans Azure pour le faire ...

@jsburckhardt -
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Salut mon pote, est une bonne solution de contournement. Malheureusement, en raison de restrictions de sécurité. L'équipe ne contrôle pas les adresses IP de la liste blanche KV / vNet