Azure-docs: O Azure DevOps Build Pipeline não consegue obter segredos do Key Vault quando protegido com vnet e firewall

@ aspnet4you Obrigado pelo feedback.
Estamos investigando ativamente e entraremos em contato com você em breve.

@ KalyanChanumolu-MSFT - Obrigado por analisar o problema. O Key Vault é um componente crítico de infraestrutura e, por sua natureza de negócio, não queremos expô-lo a redes não confiáveis. Se eu tivesse construído uma máquina em minha ventilação, estaria tudo bem, mas meu objetivo é usar o Azure DevOps para CI / CD. Preciso guardar as chaves e os segredos e ser capaz de recuperá-los com segurança.

@ aspnet4you , Obrigado por compartilhar a consulta. Colocar os IPs na lista de permissões não é uma maneira eficiente, mas é definitivamente uma solução alternativa. Estamos trabalhando com a equipe de Produto para obter Azure Dev Ops como um serviço confiável para o Azure Key Vault e isso seria uma correção completa em todos os termos. Permita-nos algum tempo e compartilharei minhas próximas atualizações com você.

Você pode incluir uma etapa na definição de construção para colocar o endereço IP do agente na lista de desbloqueio e, em seguida, removê-lo da lista de desbloqueio no final da construção. Isso não é uma solução, mas uma solução alternativa até que a equipe de produto do Azure adicione o Azure DevOps como um serviço confiável. Obrigado a @Daniel Mann por fornecer a ideia.

A solução é simples, mas eu não confiava no ipify.org como um endpoint da API REST para obter o endereço IP do meu agente de construção. Em vez disso, criei meu próprio (e confiável) serviço no Azure Function- GetClientIP. DevOps não é meu trabalho diário e eu estava tendo dificuldade em descobrir como atribuir e usar variáveis ​​definidas pelo usuário e passá-las para a próxima etapa / tarefa / estágio no pipeline! A documentação da Microsoft sobre o uso de variáveis ​​não estava me ajudando o suficiente, mas descobri depois de várias execuções sem sucesso!

Veja a solução completa em meu blog - Azure DevOps Build Pipeline - use chaves e segredos do Key Vault .

@ aspnet4you , há conversas sobre como obter o Azure DevOps como um serviço confiável. O Azure DevOps tem um cenário distinto em que a identidade que acessa o Key Vault pertence ao cliente, não à Microsoft. Isso viola os requisitos de escalabilidade e segurança para “serviço confiável”.

No momento, a única solução alternativa parece ser adicionar os endereços IP das máquinas DevOps ao firewall AKV. Este é um subconjunto menor do que todos os IPs do Datacenter e se ajustará ao limite de 127 regras de IP.

Atualmente, estou trabalhando para obter os IPs e atualizarei o tópico em breve.

@ aspnet4you , encontre os detalhes sobre os IPs abaixo:

Para whitelisting AzureDevops services - https://docs.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops

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

Espero que isto ajude.

@ aspnet4you , Espero que isso ajude. Sinta-se à vontade para entrar em contato conosco caso haja mais dúvidas sobre isso. Estamos encerrando este tópico por enquanto.

@ souravmishra-msft parece que a lista de permissões dos serviços do azure devops, o ip está no link não é suficiente.
Por exemplo, tentando ligar o grupo de variáveis ​​de devops aos segredos de keyvault, precisei adicionar também o ip: 52.236.xx (escondi intencionalmente os últimos 2 bytes). Você sabe de onde estão esses ip's? Você pode fornecer a gama completa de ip's para a vinculação de grupos de variáveis ​​devops?

@ aspnet4you , Obrigado por compartilhar a consulta. Colocar os IPs na lista de permissões não é uma maneira eficiente, mas é definitivamente uma solução alternativa. Estamos trabalhando com a equipe de Produto para obter Azure Dev Ops como um serviço confiável para o Azure Key Vault e isso seria uma correção completa em todos os termos. Permita-nos algum tempo e compartilharei minhas próximas atualizações com você.

Alguma atualização sobre este recurso? Existe algum link para rastrear o recurso 'Azure Dev Ops como um serviço confiável para o Azure Key Vault'

O mesmo pedido para outras ofertas de PAAS de endpoint de serviço VNET - https://feedback.azure.com/forums/217298-storage/suggestions/35850511-make-azuredevops-a-trusted-microsoft-services-to

@ aspnet4you , como

@oviliz - Ótima pergunta. A lista de permissões de IP é uma das últimas defesas contra o acesso não autorizado ao cofre. A entidade de serviço deve ser configurada com a Política de acesso ao keyvault para listar e obter chaves e segredos. É o segundo requisito, conforme declarado na minha postagem - Azure DevOps Build Pipeline - usar chaves e segredos do Key Vault .

Olá @ KalyanChanumolu-MSFT alguma atualização? Hoje eu enfrentei o mesmo problema. Não consigo recuperar o segredo do meu KV na etapa do Azure Key Vault em meu pipeline de lançamento (Azure DevOps). Links com IP's acima estão quebrados ... Então, como posso recuperar segredos em meu pipeline? Permitir que serviços confiáveis ​​da Microsoft contornem este firewall? (Sim) - também não ajudou.

Também estou enfrentando esse problema e está claro como a lama sobre quais IPs precisam ser incluídos na lista de permissões. Além disso, isso está abrindo nosso cofre para serviços que não controlamos, então estou muito insatisfeito com essa solução.

A propósito, os artigos mencionados acima dizem que os intervalos de IP podem mudar semanalmente. Sugerir que atualizemos o firewall semanalmente e até mesmo tentarmos acompanhar as mudanças é bastante ridículo.

Estou enfrentando o mesmo problema e colocar IPs na lista de permissões semanalmente não é uma opção.

Seria possível ter um agente auto-hospedado para o Build Pipeline dentro de uma VM, configurar essa VM dentro de uma VNet e permitir seu acesso dentro do Key Vault? Não sou profissional de forma alguma, então quão absurda é essa abordagem?

FWIW, fui inspirado por esta solução aqui: https://www.visualstudiogeeks.com/DevOps/PrivateAzureAseV2AppServiceVstsDeploymentUsingAzureDtl

Adicione-nos à lista. Como pode ser que o ADO não seja um serviço confiável para Key Vaults?

Se você pesquisar os arquivos semanais por devops ou agentes hospedados, não destacará nenhum ips. Quais ips você está usando em https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519 ??? e se você pesquisar por Datacenter, há appservice, devspaces, etc, mas o que se correlaciona com devops e agentes de host?

@ ShaneBala-keyvault, Conforme solicitado, adicionando você a este tópico.

Adicione-nos à lista. Como pode ser que o ADO não seja um serviço confiável para Key Vaults?

Com você lá, procurando mover muitos projetos para AZ Devops, mas este é um problema

+1, isso deve ser corrigido o mais rápido possível. Mesmo que variáveis ​​secretas de pipeline possam ser usadas para lançamentos, gostaria de ter uma única fonte de informações. O valor da variável secreta do pipeline não pode ser visualizado novamente após salvar, portanto, de qualquer maneira que você colocar, as informações precisam ser armazenadas em outro lugar de qualquer maneira.

ASSIM pergunta sobre este assunto:

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

+1 isso é realmente crucial. Algum comentário da Microsoft sobre isso?

@ souravmishra-msft Isso deveria ser reaberto, talvez?

@Ogglas Isso definitivamente deve ser reaberto. Eles devem listar ips ou marcar o serviço para ignorar o Firewall Keyvault do Azure. Eles fazem isso para outros serviços, por que não devops azuis?

+1, mesmo problema aqui

+1

também juntando-se à pilha ... um grande problema para mim também

Como é isso perto ???? os links de links da "solução alternativa" também não funcionam :)

@jsburckhardt - Não tenho certeza de qual solução alternativa você está se referindo, mas você pode revisar minha postagem do blog,
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Precisamos criar um novo problema para isso ou encontrar uma maneira de reabri-lo, @ souravmishra-msft?

@captainbrown , reabri este tópico. Também atualizei o Gerente de Programa internamente mais uma vez, já que a partir do momento em que este tópico foi aberto, o tópico interno foi criado com a Equipe de Produto.

Também estou atribuindo este tópico ao gerente do programa. Pode levar algum tempo para que eles respondam neste tópico, pois não tenho certeza sobre a complexidade que essa mudança pode exigir do lado do produto.

Também melhorei o encadeamento interno que está acontecendo neste encadeamento do github e manterei você atualizado sobre o progresso.

Também gostaria de declarar que corrigi os URLs mencionados em um de meus comentários anteriormente neste tópico. Nesse meio tempo, você também pode querer dar uma olhada neles e nos informar se funcionam para sua solução e, se não, nos atualize sobre isso também.

@ souravmishra-msft muito obrigado por reabrir esta edição. Permitir os intervalos para os serviços devops não funciona para permitir o acesso ao keyvault (talvez os intervalos estejam desatualizados no site) e a lista de sub-redes possíveis é muito longa para adicionar ao controle de acesso à rede no keyvault.

Minha equipe e eu estaremos esperando ansiosamente por notícias do seu gerente de programa

Obrigado por reabrir ... @captainbrown Eu vi o mesmo problema onde a documentação ou o arquivo json com os serviços de ip está definitivamente desatualizado / não documentado corretamente.

Concordo, obrigado por reabrir. Esse é um problema que também gostaríamos de ver resolvido.

@ souravmishra-msft Obrigado, espero que isso seja priorizado em breve.

+1, este também é um problema para nós. Não apenas o acesso do Azure DevOps ao Key-vault, mas também precisamos do pipeline DevOps para gerar alguns arquivos e carregá-los para uma conta de armazenamento protegida por firewall, mas enfrentamos o mesmo problema, que o Azure DevOps não é um serviço confiável e a solução alternativa seria colocar cerca de 250 endereços IP na lista de permissões semanalmente, o que seria muito ruim (além de não ter certeza se há algum limite de quantos endereços IP podem ser adicionados ao firewall da conta de armazenamento). Seria ótimo se isso pudesse ser resolvido!

Atualmente, há uma solução alternativa para esse problema.

Você pode usar um agente auto-hospedado e adicionar os seguintes intervalos IPv4 à lista de permissões do firewall do cofre de chaves. Detalhes aqui: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops

(A equipe do Azure DevOps está ciente desse problema e o trabalho para uma correção permanente está em andamento)

Este recurso está atualmente em visualização.

Aqui está outra solução ... você pode configurar seu próprio vnet com um conjunto de escala.

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

Outro truque ... eu não me aproprio desse truque, alguém me mostrou.
Se você tiver uma conta de devops corporativa, há uma maneira de permitir que os devops leiam os segredos keyvault de sua biblioteca.
Se você tiver uma conta pessoal, isso não funciona.

Você pode abrir o firewall para a rede Azure / 11, configurar a conexão de devops para azure com o keyvault. Configure a biblioteca de variáveis ​​e adicione o segredo. Depois que os segredos forem adicionados, remova a regra de firewall e tente adicionar um segredo. A mensagem de erro vai passar um IP que você pode colocar no firewall. Descobrimos que não mudou em um mês e entendemos que pode mudar. Neste ponto, estamos procurando soluções alternativas como todo mundo. Vou fazer mais testes com compilações e lançamentos, mas isso permite que a GUI Native Devops interaja com Keyvaults diretamente.

Novamente, isso não funciona com uma conta pessoal.

+1 temos um problema semelhante ao usar o AzDO para o servidor SQL via link privado / endpoint.

+1 problema semelhante aqui.

Soluções alternativas são fornecidas aqui. Não é problema com o próprio documento. Esta é uma solução alternativa https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops # por favor-close você também pode postar solicitação de recurso aqui https: // developersercommunity.visualstudio.com/spaces/21/index.html

Solicitação de recurso aqui:

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

1, bata neste problema hoje.

SE a Microsoft for habilitar as Service Tags para Azure DevOps, elas podem ser usadas de alguma forma no Firewall Keyvault? https://devblogs.microsoft.com/devops/new-ip-address-ranges-with-service-tags-for-azure-devops-services/

@ JQUINONES82 Infelizmente, não para agentes hospedados. Do seu link:

A etiqueta de serviço não se aplica a agentes hospedados pela Microsoft.

+1, acertando nos últimos 2 anos

1, bata neste problema hoje.

Está fechado, então como faço para corrigir?

A segurança não é um pedido de recurso, é uma necessidade para qualquer componente da nuvem. Se isso não for corrigido, ele pode ser reaberto? Eu vi uma menção de algo sendo pré-visualizado ... Vou fazer uma pré-visualização. Isso vai atrasar nossa implantação, pois não quero gastar ainda mais dinheiro criando VMs no azul para fazer isso ...

@jsburckhardt - Não tenho certeza de qual solução alternativa você está se referindo, mas você pode revisar minha postagem do blog,
https://blogs.aspnet4you.com/2019/09/20/azure-devops-build-pipeline-use-keys-and-secrets-from-key-vault/

Oi cara, é uma boa solução alternativa. Infelizmente, devido a restrições de segurança. A equipe não tem controle dos IPs permitidos KV / vNet