Azure-docs: Azure DevOps Build Pipeline no puede obtener secretos de Key Vault cuando está protegido con vnet y firewall

@ aspnet4you Gracias por los comentarios.
Estamos investigando activamente y nos comunicaremos contigo pronto.

@ KalyanChanumolu-MSFT - Gracias por investigar el problema. Key Vault es un componente de infraestructura crítico y, por su naturaleza de negocio, no queremos exponerlo a redes que no son de confianza. Si hubiera construido una máquina en mi ventilación, habría estado bien, pero mi objetivo es usar Azure DevOps para CI / CD. Necesito guardar las claves y los secretos, y poder recuperarlos de forma segura.

@ aspnet4you , Gracias por compartir la consulta. Incluir las direcciones IP en la lista blanca no es una forma eficiente, pero definitivamente es una solución. Estamos trabajando con el equipo de Producto para obtener Azure Dev Ops como un servicio confiable para Azure Key Vault y eso sería una solución completa en todos los términos. Permítanos en algún momento y compartiré mis próximas actualizaciones con usted.

Puede agregar un paso en la definición de compilación para incluir en la lista blanca la dirección IP del agente y luego eliminarla de la lista blanca al final de la compilación. Esta no es una solución, sino una solución alternativa hasta que el equipo de productos de Azure agregue Azure DevOps como un servicio confiable. Gracias a @ Daniel Mann por brindar la idea.

La solución es simple, pero no iba a confiar en ipify.org como punto final de la API REST para obtener la dirección IP de mi agente de compilación. En su lugar, creé mi propio (y confiable) servicio en Azure Function- GetClientIP. DevOps no es mi trabajo diario y estaba teniendo dificultades para descubrir cómo asignar y usar variables definidas por el usuario y pasarlas al siguiente paso / tarea / etapa en la tubería. La documentación de Microsoft sobre el uso de variables no me ayudó lo suficiente, ¡pero lo descubrí después de muchas ejecuciones fallidas!

Vea la solución completa en mi blog, Azure DevOps Build Pipeline, use claves y secretos de Key Vault .

@ aspnet4you , hay conversaciones sobre cómo obtener Azure DevOps como un servicio confiable. Azure DevOps tiene un escenario distinto en el que la identidad que accede a Key Vault pertenece al cliente, no a Microsoft. Esto viola los requisitos de escalabilidad y seguridad para un "servicio confiable".

En este momento, la única solución alternativa parece ser agregar las direcciones IP de las máquinas DevOps al firewall de AKV. Este es un subconjunto más pequeño que todas las IP de Datacenter y se ajustará al límite de 127 reglas de IP.

Actualmente estoy trabajando para obtener las direcciones IP y actualizaré el hilo en breve.

@ aspnet4you , encuentre los detalles sobre las direcciones IP a continuación:

Para incluir en la lista blanca los servicios de AzureDevops : https://docs.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops

Para agentes alojados en la https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#agent -ip-ranges

Espero que esto ayude.

@ aspnet4you , espero que esto ayude. No dude en comunicarse con nosotros en caso de que haya más consultas al respecto. Cerramos este hilo por ahora.

@ souravmishra-msft parece que la lista blanca de los servicios devops azure, las ip en el enlace no es suficiente.
Por ejemplo, al intentar vincular el grupo de variables de devops a los secretos de keyvault, necesitaba agregar también la ip: 52.236.xx (oculté intencionalmente los 2 bytes de latitud). ¿Sabes de dónde están estas ip? ¿Puede proporcionar la gama completa de IP para el enlace de grupos de variables de devops?

@ aspnet4you , Gracias por compartir la consulta. Incluir las direcciones IP en la lista blanca no es una forma eficiente, pero definitivamente es una solución. Estamos trabajando con el equipo de Producto para obtener Azure Dev Ops como un servicio confiable para Azure Key Vault y eso sería una solución completa en todos los términos. Permítanos en algún momento y compartiré mis próximas actualizaciones con usted.

¿Alguna actualización sobre esta función? ¿Existe algún vínculo para realizar un seguimiento de la función 'Azure Dev Ops como servicio de confianza para Azure Key Vault'?

Misma solicitud para otras ofertas de VNET Service Endpoint PAAS: https://feedback.azure.com/forums/217298-storage/suggestions/35850511-make-azuredevops-a-trusted-microsoft-services-to

@ aspnet4you , ¿cómo es suficiente

@oviliz - Muy buena pregunta. La lista blanca de IP es una de las últimas defensas contra el acceso no autorizado a la bóveda. El director de servicio debe estar configurado con la política de acceso de Key Vault para enumerar y obtener claves y secretos. Es el segundo requisito, como se indica en mi publicación, Azure DevOps Build Pipeline, use claves y secretos de Key Vault .

Hola @ KalyanChanumolu-MSFT ¿alguna actualización? Hoy me enfrenté al mismo problema. No puedo recuperar el secreto de mi KV en el paso de Azure Key Vault en mi canalización de lanzamiento (Azure DevOps). Los enlaces con las IP anteriores están rotos ... Entonces, ¿cómo puedo recuperar secretos en mi canalización? ¿Permitir que los servicios de Microsoft de confianza eludan este firewall? (Sí) - tampoco ayudó.

También estoy enfrentando este problema y está claro como el barro qué IP deben incluirse en la lista blanca. Además, esto está abriendo nuestra bóveda a servicios que no controlamos, así que estoy bastante descontento con esta solución.

Y, por cierto, los artículos mencionados anteriormente dicen que los rangos de IP pueden cambiar semanalmente. Sugerir que actualicemos el cortafuegos semanalmente e incluso que intentemos realizar un seguimiento de los cambios es bastante ridículo.

Estoy enfrentando el mismo problema, y ​​la lista blanca de direcciones IP semanalmente no es una opción en absoluto.

¿Sería posible tener un agente autohospedado para Build Pipeline dentro de una VM, configurar esta VM dentro de una VNet y luego permitirle el acceso dentro de Key Vault? No soy un profesional de ninguna manera, entonces, ¿qué tan absurdo es este enfoque?

FWIW Me inspiré en esta solución aquí: https://www.visualstudiogeeks.com/DevOps/PrivateAzureAseV2AppServiceVstsDeploymentUsingAzureDtl

Agréganos a la lista. ¿Cómo puede ser que ADO no sea un servicio confiable para Key Vaults?

Si busca los archivos semanales para devops o agentes alojados, no resalta ningún ips. ¿Qué IPS está utilizando en https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519 ??? y si busca por centro de datos, hay servicio de aplicaciones, espacios de desarrollo, etc., pero ¿qué se correlaciona con devops y agentes de host?

@ ShaneBala-keyvault, según lo solicitado, agregándote a este hilo.

Agréganos a la lista. ¿Cómo puede ser que ADO no sea un servicio confiable para Key Vaults?

Contigo allí, buscando mover muchos proyectos a AZ Devops, pero esto es un problema

+1, esto debería arreglarse lo antes posible. Incluso si las variables secretas de la canalización se pueden usar para las versiones, me gustaría tener una única fuente de verdad. El valor de la variable secreta de la canalización no se puede volver a ver después de guardar, por lo que, de cualquier manera, la información debe almacenarse en otro lugar.

SO pregunta sobre este problema:

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

+1 esto es realmente crucial. ¿Algún comentario de Microsoft sobre eso?

@ souravmishra-msft ¿Debería reabrirse quizás?

@Ogglas Esto definitivamente debería ser reabierto. Deben incluir ips o etiquetar el servicio para omitir Azure Keyvault Firewall. Lo hacen para otros servicios, ¿por qué no devops azure?

+1, mismo problema aquí

+1

también uniéndome a la pila en ... un gran problema para mí también

¿Cómo diablos está tan cerca ???? los enlaces enlaces de la "solución alternativa" tampoco funcionan :)

@jsburckhardt : no estoy seguro de a qué solución te refieres, pero puedes revisar la publicación de mi blog,
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

¿Necesitamos crear un nuevo número para esto o encontrar una manera de volver a abrirlo, @ souravmishra-msft?

@captainbrown , he vuelto a abrir este hilo. También he actualizado el Administrador de Programas internamente una vez más, ya que desde el momento en que se abrió este hilo inicialmente se creó el hilo interno con el Equipo de Producto.

También estoy asignando este hilo al Administrador de programas. Es posible que les lleve algún tiempo responder en este hilo, ya que no estoy seguro de la complejidad que este cambio podría requerir desde el lado del producto.

También he aumentado el hilo interno que está sucediendo en este hilo de github y lo mantendré actualizado sobre el progreso.

También me gustaría decir que he corregido las URL que se mencionaron en uno de mis comentarios anteriormente en este hilo. Es posible que desee echar un vistazo a esos también de vez en cuando y hacernos saber si funcionan para su solución y, si no, actualizarnos sobre eso también.

@ souravmishra-msft muchas gracias por reabrir este número. Permitir los rangos para los servicios de devops no funciona para permitir el acceso al keyvault (quizás los rangos estén desactualizados en el sitio web) y la lista de posibles subredes es demasiado larga para agregarla al control de acceso a la red en el keyvault.

Mi equipo y yo estaremos esperando ansiosamente noticias de su gerente de programa

Gracias por reabrir ... @captainbrown Vi el mismo problema en el que la documentación o el archivo json con los servicios ip definitivamente está desactualizado / no documentado correctamente.

De acuerdo, gracias por reabrir. Este es un problema que también nos gustaría que se abordara.

@ souravmishra-msft Gracias, espero que esto sea priorizado pronto.

+1, esto también es un problema para nosotros. No solo el acceso de Azure DevOps a Key-vault, sino que también necesitamos la canalización de DevOps para generar algunos archivos y cargarlos en una cuenta de almacenamiento protegida por firewall, pero nos enfrentamos al mismo problema, que Azure DevOps no es un servicio confiable. y la solución alternativa sería incluir en la lista blanca ~ 250 direcciones IP semanalmente, por lo que sería muy desagradable (y tampoco estoy seguro de si hay algún límite en cuanto a cuántas direcciones IP se pueden agregar al firewall de la cuenta de almacenamiento). ¡Sería genial si esto se pudiera solucionar!

Actualmente hay una solución para este problema.

Puede usar un agente autohospedado y agregar los siguientes rangos de IPv4 a la lista de permitidos del firewall de Key Vault. Detalles aquí: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops

(El equipo de Azure DevOps está al tanto de este problema y actualmente se está trabajando para una solución permanente)

Esta función se encuentra actualmente en versión preliminar.

Aquí hay otra solución ... puede configurar su propia red virtual con un conjunto de escalas.

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

Otro truco ... no me apropio de este truco, alguien me mostró.
Si tiene una cuenta de devops empresarial, hay una manera de permitir que devops lea los secretos de la caja fuerte de claves de su biblioteca.
Si tiene una cuenta personal, esto no funciona.

Puede abrir el firewall a la red Azure / 11, configurar la conexión de devops a azure con keyvault. Configure la biblioteca de variables y agregue el secreto. Una vez que se agregan los secretos, elimine la regla de firewall e intente agregar un secreto. El mensaje de error le pasará una IP que puede colocar en el firewall. Hemos descubierto que no ha cambiado en un mes y entendemos que puede cambiar. En este punto, estamos buscando soluciones alternativas como todos los demás. Voy a hacer más pruebas con versiones y versiones, pero esto permite que la GUI de Native Devops interactúe directamente con Keyvaults.

Nuevamente, esto no funciona con una cuenta personal.

+1 tenemos un problema similar al usar AzDO en el servidor SQL a través de un enlace / punto final privado.

+1 Problema similar aquí.

Aquí se proporcionan soluciones. No es un problema con el documento en sí. Esta es una solución https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops # please-close también puede publicar una solicitud de función aquí https: // developercommunity.visualstudio.com/spaces/21/index.html

Solicitud de funciones aquí:

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

+1, aborde este problema hoy.

SI Microsoft va a habilitar etiquetas de servicio para Azure DevOps, ¿se puede usar de alguna manera en Keyvault Firewall? https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

@ JQUINONES82 Me temo que no para agentes alojados. Desde tu enlace:

La etiqueta de servicio no se aplica a los agentes alojados de Microsoft.

+1, presionando esto durante los últimos 2 años

+1, aborde este problema hoy.

Esto está cerrado, entonces, ¿cómo puedo solucionarlo?

La seguridad no es una solicitud de función, es una necesidad para cualquier componente de la nube. Si esto no se soluciona, ¿se puede volver a abrir? Vi que se menciona algo en vista previa ... Tomaré una función de vista previa. Esto va a retrasar nuestra implementación, ya que no quiero gastar aún más dinero girando máquinas virtuales en azul para hacer esto ...

@jsburckhardt : no estoy seguro de a qué solución te refieres, pero puedes revisar la publicación de mi blog,
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Hola amigo, es una buena solución. Desafortunadamente, debido a restricciones de seguridad. El equipo no tiene control de las direcciones IP incluidas en la lista blanca de KV / vNet