@DanijelMalik , Obrigado pelo seu feedback. Estamos investigando esta questão e iremos atualizá-lo assim que possível.

@DanijelMalik , poderia nos fornecer a saída do PowerShell para este erro. Que se parecem com isso,
Observação: certifique-se de mascarar áreas confidenciais, como ID de assinatura ou segredos.
{
"status": "Falha",
"erro": {
"code": "ApplicationGatewayKeyVaultSecretException",
"message": "Ocorreu um problema ao acessar e validar os segredos do KeyVault associados ao Application Gateway '/subscriptions/XXXXXXXXXXXXXXXX/resourceGroups/XXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'. Veja os detalhes abaixo:",
"detalhes": [
{
"code": "ApplicationGatewayKeyVaultSecretAccessDenied",
"message": "Acesso negado para KeyVault Secret 'XXXXXXXXXXXXXXXXX' for Application Gateway '/subscriptions/XXXXXXXXXXX/resourceGroups/XXXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'. Certifique-se de que a identidade atribuída ao Application Gateway tem acesso ao KeyVault associado ao segredo. "
}
]
}
}

@DanijelMalik , Só verificando se você tem tempo para ver a resposta anterior.

@DanijelMalik , Como não ouvimos de você, iremos agora encerrar este tópico. Se houver mais perguntas sobre este assunto, marque-me em sua resposta. Teremos o prazer de reabrir a questão e continuar a discussão.

Mesmo problema aqui.

Para mim, isso foi resolvido habilitando a exclusão reversível no cofre de chaves.

Existe um problema sobre este requisito não estar documentado: # 34382

Olá, estou tendo o mesmo problema. O que parece ser o problema é que, embora o keyvault permita o acesso a partir da sub-rede appGw (por meio da folha de configurações de firewalls e redes virtuais na configuração keyvault); e a sub-rede appGw está sendo inserida em New-AzApplicationGateway por meio do argumento -GatewayIpConfigurations, o appGw não parece ser capaz de acessar o keyvault (a identidade também tem direitos de acesso nas políticas de acesso keyvault).

Quando permito o acesso ao keyvault de "todas as redes", parece funcionar bem.

Talvez no processo de criação do appGw, o keyvault esteja sendo acessado antes que o appGw seja configurado com a sub-rede e o keyvault então veja esse acesso de algum lugar diferente da sub-rede?

Estou executando o script do PowerShell localmente, mas meu IP também tem acesso ao cofre da chave, então esse não deve ser o problema.

Eu vejo o mesmo problema

@ SubhashVasarapu-MSFT

Eu tenho o mesmo problema. Estou usando o Azure CLI 2.0.76. Meu gateway de aplicativo e cofre de chaves estão em grupos de recursos diferentes na mesma assinatura. O cofre de chaves tem exclusão reversível habilitada, pode ser acessado de todas as redes e tem uma política de acesso para a identidade atribuída do usuário atribuído ao gateway de aplicativo com a permissão get secrets.

az network application-gateway ssl-cert create -g XXX --gateway-name XXX --name XXX --key-vault-secret-id https://XXX.vault.azure.net/secrets/XXX --debug

resultados em (abreviado)

msrest.http_logger : {
  "status": "Failed",
  "error": {
    "code": "ApplicationGatewayKeyVaultSecretException",
    "message": "Problem occured while accessing and validating KeyVault Secrets associated with Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. See details below:",
    "details": [
      {
        "code": "ApplicationGatewayKeyVaultSecretAccessDenied",
        "message": "Access denied for KeyVault Secret 'https://XXX.vault.azure.net/secrets/XXX' for Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. Make sure that Identity assigned to Application Gateway has access to the KeyVault associated with secret."
      }
    ]
  }
}
msrest.exceptions : Problem occured while accessing and validating KeyVault Secrets associated with Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. See details below:
cli.azure.cli.core.util : Deployment failed. Correlation ID: 623f5539-b652-49fc-9a29-326bcadaa055. Access denied for KeyVault Secret 'https://XXX.vault.azure.net/secrets/XXX' for Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. Make sure that Identity assigned to Application Gateway has access to the KeyVault associated with secret.
Deployment failed. Correlation ID: 623f5539-b652-49fc-9a29-326bcadaa055. Access denied for KeyVault Secret 'https://XXX.vault.azure.net/secrets/XXX' for Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. Make sure that Identity assigned to Application Gateway has access to the KeyVault associated with secret.

Se eu editar o ouvinte HTTP do gateway de aplicativo no Portal do Azure e tentar obter o certificado SSL do cofre de chaves lá, recebo este erro:

Falha ao salvar as alterações de configuração no gateway de aplicativo 'XXX'. Erro: valor inválido para as identidades 'XXX / supplies / Microsoft.ManagedIdentity / userAssignedIdentities / XXX'. As chaves de propriedade 'UserAssignedIdentities' devem ser apenas objetos json vazios, nulos ou a propriedade existente do recurso.

Olá, estou tendo o mesmo problema. O que parece ser o problema é que, embora o keyvault permita o acesso a partir da sub-rede appGw (por meio da folha de configurações de firewalls e redes virtuais na configuração keyvault); e a sub-rede appGw está sendo inserida em New-AzApplicationGateway por meio do argumento -GatewayIpConfigurations, o appGw não parece ser capaz de acessar o keyvault (a identidade também tem direitos de acesso nas políticas de acesso keyvault).

Quando permito o acesso ao keyvault de "todas as redes", parece funcionar bem.

Talvez no processo de criação do appGw, o keyvault esteja sendo acessado antes que o appGw seja configurado com a sub-rede e o keyvault então veja esse acesso de algum lugar diferente da sub-rede?

Estou executando o script do PowerShell localmente, mas meu IP também tem acesso ao cofre da chave, então esse não deve ser o problema.

Isso funcionou para mim também. A única mudança que fiz do fracasso ao sucesso foi permitir todas as redes

Se eu editar o ouvinte HTTP do gateway de aplicativo no Portal do Azure e tentar obter o certificado SSL do cofre de chaves lá, recebo este erro:

Falha ao salvar as alterações de configuração no gateway de aplicativo 'XXX'. Erro: valor inválido para as identidades 'XXX / supplies / Microsoft.ManagedIdentity / userAssignedIdentities / XXX'. As chaves de propriedade 'UserAssignedIdentities' devem ser apenas objetos json vazios, nulos ou a propriedade existente do recurso.

@wolfganggallo Estou recebendo exatamente o mesmo erro. Meu portal azul também parece estar travado em um estado de erro e não me permite fazer nenhuma alteração. Você conseguiu consertar isso?

Atenção: @ SubhashVasarapu-MSFT - reabra.

Estou recebendo o mesmo problema: "_As chaves de propriedade 'UserAssignedIdentities' devem ser apenas objetos json vazios, nulos ou a propriedade existente do recurso_" e my - keyvault em um grupo de recursos e vnet diferentes. Acho que no meu caso as vnets não têm peering, portanto, não há rota entre a instância APIM e o keyvault em tempo de execução, mas a IU do Portal do Azure ainda listará o keyvault como disponível para uso e permitirá que ele seja vinculado ao ouvinte. Vou criar um peering de vnet temporário para ver se resolve o problema para que eu possa remover o ouvinte. Meu Appgw está quebrado atualmente como resultado:

ATUALIZAÇÃO Sim, esse é o problema. O Portal do Azure mostrará os cofres de chaves que não estão realmente disponíveis no tempo de execução e salvar as configurações do ouvinte interromperá seu Appgw. A solução rápida é ir para o keyvault e abri-lo temporariamente em "todas as redes / internet" e salvar novamente o ouvinte. O que você faz então é com você - copiar o certificado para um keyvault local, ou adicionar um peering de vnet, ou adicionar a sub-rede ausente. Em última análise, o portal deve validar a acessibilidade de rede entre appgw e kyvault. Erro.

2ª ATUALIZAÇÃO Só para ficar claro: Isso QUEBRA completamente a IU do Portal. AppGw NÃO PODE ser corrigido no portal. Os salvamentos subsequentes falham.

Acabei de encontrar esse erro também na IU do Portal. A exclusão reversível está ativada. Permitir que todas as redes funcionassem.

Abra novamente, poder usar a lista de permissões é uma boa segurança.

@ SubhashVasarapu-MSFT Abra novamente. Estamos lidando com um problema semelhante. A interface do usuário do portal está completamente corrompida.

Todas as operações falham com a seguinte mensagem:
Set-AzApplicationGateway : Either Data or KeyVaultSecretId must be specified for Certificate '/subscriptions/********-****-****-****-************/resourceGroups/**-***-ApplicationGateway-RG/providers/Microsoft.Network/ applicationGateways/**-***-Shared-WAF/sslCertificates/wildcard2022' in Application Gateway.

@PgInsight @oising Você só precisa definir "Permitir todas as redes" para fazer o AppGw funcionar novamente? Temos um problema com os mesmos sintomas, mas temos o KeyVault na mesma sub-rede, possivelmente uma causa raiz diferente.

Não consigo fazer nada usando UI, PowerShell, CLI ou Resource Explorer.

@PgInsight @oising Você só precisa definir "Permitir todas as redes" para fazer o AppGw funcionar novamente? Temos um problema com os mesmos sintomas, mas temos o KeyVault na mesma sub-rede, possivelmente uma causa raiz diferente.

Não consigo fazer nada usando UI, PowerShell, CLI ou Resource Explorer.

Definir todas as redes Permitir no KeyVault e também precisamos definir o sinalizador Soft Delete no Key Vault usando o cmd PowerShell.

($resource = Get-AzureRmResource -ResourceId (Get-AzureRmKeyVault -VaultName "YOUR-VAULT-NAME").ResourceId).Properties | Add-Member -MemberType "NoteProperty" -Name "enableSoftDelete" -Value "true"

Set-AzureRmResource -resourceid $resource.ResourceId -Properties $resource.Properties

Eu tive o mesmo problema. No entanto, consegui resolver o problema removendo o certificado do Key Vault usando o PowerShell e não o explorador de recursos usando o explorer. O erro abaixo foi mostrado:
{
"erro": {
"code": "MissingIdentityIds",
"message": "Os ids de identidade não devem ser nulos ou vazios para o tipo de identidade 'UserAssigned'."
}

}

usou o script de exemplo abaixo para remover o certificado e o ouvinte e o gateway do aplicativo voltou ao estado de funcionamento

excluir ouvinte e certificado do aplicativo gw

$ AppGw = Get-AzApplicationGateway -Name "app-gw-ssl-key" -ResourceGroupName "lab"
Remove-AzApplicationGatewayHttpListener -ApplicationGateway $ AppGw -Name "https"
Remove-AzApplicationGatewaySslCertificate -ApplicationGateway $ AppGW -Name "victor-cer"

salvar mudanças

set-azapplicationgateway -ApplicationGateway $ AppGW

quando o gateway de aplicativo estava fora do estado de falha, verifiquei a política de acesso do cofre de chaves e vi que a identidade do aplicativo gw estava em outra categoria que não é "APLICATIVO". Acho que essa foi a causa do problema.
Adicionada a identidade novamente à política de acesso da configuração do cofre de chaves e ela pôde ser exibida como "APLICATIVO". Isso resolveu o problema para mim e fui capaz de adicionar ouvinte com certificado do cofre de chaves sem problemas.

@ SubhashVasarapu-MSFT Isso precisa ser reaberto. O App Gateway nunca deve terminar em um estado desabilitado / quebrado como este - eu tive o mesmo problema novamente. Como isso pode ser escalado? Este não é um problema de documentação. Este é um problema de qualidade do produto.

Para resumir:

Ao configurar um ouvinte para usar um certificado SSL em um keyvault remoto, a IU do portal permitirá que você configure o ouvinte com um keyvault que está indisponível em tempo de execução para o appgw devido a restrições de rede (não aberto para internet, apenas sub-redes selecionadas). Depois de fazer isso, a interface do portal do App Gateway é QUEBRADA para todos os ouvintes.

Vou levar isso adiante para a respectiva equipe.

Qual é a situação disso?

Encontramos uma das causas desse erro com o PG. Se você tinha o período de retenção no KeyVault definido como algo diferente do padrão de 90 dias, AppGW estava lançando essa mensagem de erro mesmo se você tivesse a exclusão reversível habilitada e toda a rede definida como acessibilidade. A atualização está sendo lançada atualmente para corrigir esse bug.

Quando será lançado? Eu também encontrei esse problema e é realmente um grande problema não ser capaz de configurar ou fazer qualquer alteração no Portal depois de encontrá-lo.

Basta acertar isso hoje. Encontrei este tópico após definir a retenção de exclusão reversível para 30 dias e descobrir que não é possível alterá-lo Adoraria que essa correção fosse implementada.

Tenho exatamente o mesmo problema, mesmo com o período de retenção padrão de 90 dias .
Quer esteja executando a CLI do Azure, Powershell, TerraForm ou Portal, sempre recebo o mesmo erro: "Ocorreu um problema ao acessar e validar os segredos do KeyVault associados ao Gateway de aplicativo ...".

Verificação tripla das políticas de identidade e acesso, todos os recursos no mesmo grupo de recursos no local 'Europa Ocidental'

@ CMS-seglo então você está dizendo, que você tem:

• [x] exclusão reversível habilitada
• [x] período de retenção definido para o padrão de 90 dias
• [x] rede definida para toda a rede
• [x] e identidade appgw configurada corretamente

e você ainda está recebendo este erro?

@ mark-szabo Eu marquei todas as caixas de seleção. E o modelo ARM está gerando um erro:

"Invalid value for the identities '/subscriptions/<sub-id>/resourceGroups/wb-all-rg-commons/providers/Microsoft.ManagedIdentity/userAssignedIdentities/wb-application-gateway-identity'. The 'UserAssignedIdentities' property keys should only be empty json objects, null or the resource exisiting property."

A propriedade é definida assim:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
           "[parameters('gatewayIdentityId')]": {
                 "principalId": "[parameters('identityObjectId')]",
                 "clientId": "[parameters('identityClientId')]"
            }
     }
}

Os parâmetros são:

New-AzResourceGroupDeployment -Name "Gateway" `
        -ResourceGroupName "wb-devtest-core" `
        -TemplateFile './arm_templates/appgateway.azrm.json' `
        -TemplateParameterObject @{ `
            certificateSecretUrl    = "https://my-key-vault.vault.azure.net/secrets/some-name/some-id"; `
            certificateName         = "certNamel"; `
            gatewayIdentityId       = "/subscriptions/sub-id/resourceGroups/wb-all-rg-commons/providers/Microsoft.ManagedIdentity/userAssignedIdentities/wb-application-gateway-identity"; `
            identityClientId        = "id-here"; `
            identityObjectId        = "objIdHere";

EDITAR:

Mesmo quando mudei o ARM para seu próprio certificado SSL com dados brutos. A propriedade de identidade ainda gera o mesmo erro.

Alguma solução para isso?

@ mark-szabo obrigado por sua resposta, eu fui capaz de revisar toda a configuração novamente com um novo par de olhos e encontrei um ponto, onde minha configuração era diferente: o Firewall KeyVault foi definido como "Endpoint privado e redes selecionadas", mas com "Permitir que serviços confiáveis ​​da Microsoft contornem este firewall?" definido como ativado.
Quando eu permiti "Todas as redes", pude criar com sucesso um ouvinte https no portal com um certificado SSL do KeyVault. Portanto, parece que ainda há um problema com as restrições de rede.

@ CMS-seglo yup, é um problema conhecido, rastreado aqui: https://github.com/MicrosoftDocs/azure-docs/issues/48866

@kszymanski O que você definiu para o 'certificateSecretUrl'? 'some-id' em seu url deve ser a 'versão' do objeto de certificado no KeyVault. Infelizmente, isso não foi retornado por 'az keyvault certificate list --vault-name ...' nem por 'Get-AzKeyVaultSecret' ou 'Get-AzKeyVaultCertificate' no Powershell, mas é exibido no Portal quando você olha o certificado no KeyVault .

Eu tive o mesmo erro enganoso que você mencionou acima, porque um certificado 'quebrado' foi criado. Depois que descobri a id correta, funcionou.

@kszymanski O que você definiu para o 'certificateSecretUrl'? 'some-id' em seu url deve ser a 'versão' do objeto de certificado no KeyVault. Infelizmente, isso não foi retornado por 'az keyvault certificate list --vault-name ...' nem por 'Get-AzKeyVaultSecret' ou 'Get-AzKeyVaultCertificate' no Powershell, mas é exibido no Portal quando você olha o certificado no KeyVault .

Eu tive o mesmo erro enganoso que você mencionou acima, porque um certificado 'quebrado' foi criado. Depois que descobri a id correta, funcionou.

Está ofuscado aqui. Estou definindo uma id do portal, tentei o Identificador de certificado e o Identificador secreto sem sorte em ambos os casos. Além disso, como mencionado, até mesmo definir o certificado com dados brutos e senha (referências do Key Vault totalmente removidas) não está mudando nada ainda é o mesmo erro. Portanto, acho que pode ser um problema com a atribuição de identidade, em vez do URL de certificado do cofre de chaves.

Por fim, tive que carregar manualmente o certificado e a senha em vez de usar o KeyVault porque não consegui fazer o KeyVault funcionar. No entanto, se você estiver fazendo isso a partir do portal depois de receber esse erro, será necessário criar um novo gateway de aplicativo como outra pessoa mencionou. Você não conseguirá ajustar seu gateway com erro por algum motivo.

Como você pode ver, estou criando isso continuamente a partir do modelo ARM. E fazer alterações manualmente depois de criado btw. então no portal posso atribuir esta identidade e certificado sem problemas.

@kylehayes isso não está totalmente correto. Sim, você não pode tirá-lo do estado de falha do portal atualmente, mas pode fazer isso do PowerShell ou da CLI.

Por exemplo. exclua o ouvinte, regra e certificado com falha e atualize o GW.

$AppGw = Get-AzApplicationGateway -Name "<name>" -ResourceGroupName "<rg_name>"
Remove-AzApplicationGatewayHttpListener -ApplicationGateway $AppGw -Name "<listener_name>"
Remove-AzApplicationGatewayRequestRoutingRule -ApplicationGateway $AppGW -Name "<rule_name>"
Remove-AzApplicationGatewaySslCertificate -ApplicationGateway $AppGW -Name "<cert_name>"
Set-AzApplicationGateway -ApplicationGateway $AppGW

Tive o mesmo problema com um novo KV com um firewall de rede configurado. Como teste depois que desliguei o Firewall ele lançou o erro na implantação do ARM. Também concordo que isso precisa funcionar, pois meu cliente deseja bloquear o KV.

1. Ainda há um problema com o período de exclusão reversível (retenção) de não 90 dias. Nesse caso, o erro é "_As chaves de propriedade 'UserAssignedIdentities' devem ser apenas objetos json vazios, nulos ou a propriedade existente do recurso._ " (A propósito, há um erro de digitação nesta mensagem de erro.) A solução alternativa é definir a propriedade do objeto KV 'softDeleteRetentionInDays' a 90. Você pode usar https://resources.azure.com/ para isso.

2. O plano de gerenciamento do aplicativo GW usa alguns IPs aleatórios no Azure DC para acessar KV. Consulte https://github.com/MicrosoftDocs/azure-docs/issues/48866. Como solução alternativa, você pode encontrar o IP dos registros de auditoria KV (OMS ou conta de armazenamento) e adicioná-lo à lista de permissões em vez de permitir todas as redes. Infelizmente, não há garantia de que o IP permanecerá o mesmo. Além disso, você deve manter esse IP na lista o tempo todo, pois qualquer alteração na configuração do App GW reconstrói todo o objeto de configuração.

Então, para consertar o App GW "quebrado" do portal, você deve:

1. Certifique-se de que o período de exclusão reversível de KV seja de 90 dias
2. O firewall KV está desativado
3. realizar qualquer ação de gerenciamento no portal que irá acionar a atualização do objeto de configuração do App GW

Infelizmente, você ainda terá que usar PS para limpar o objeto de configuração dos links para certificados no KV, pois os objetos de certificado não são expostos na IU do portal.

Toda essa história de integração KV / AppGW teve que ser mais bem testada antes de ser lançada.

Encontramos o mesmo sintoma ("As chaves de propriedade 'UserAssignedIdentities' devem ser apenas objetos json vazios, nulos ou a propriedade existente do recurso."), Nosso período de exclusão reversível é de 90 dias e o firewall está aberto. Temos KV em um grupo de recursos "persistente" com a pilha de aplicativos em um grupo temporário. Destruiu a pilha de DEV há uma semana e tentei retê-la (via ARM) e o processo falhou no gateway de aplicativo, o que significa que não podemos fazer nenhum desenvolvimento até que funcione novamente.

Também estou enfrentando o mesmo problema ao implantar a partir do modelo ARM, mantive soft delete como 90 dias e firewall aberto para todas as redes, mas ainda enfrentando o mesmo problema. Funciona a partir do portal, mas não do modelo ARM.
. As chaves de propriedade 'UserAssignedIdentities' devem ser apenas objetos json vazios, nulos ou a propriedade existente do recurso.

Esta é a terceira vez que o mesmo appgateway foi para la-la-land. Não consigo parar e / ou atualizar:
{
"erro": {
"code": "MissingIdentityIds",
"message": "Os ids de identidade não devem ser nulos ou vazios para o tipo de identidade 'UserAssigned'."
}
}

Para ser honesto. Desisti porque é instável.

Na quinta-feira, 23 de abril de 2020 às 15:46 pererap01 [email protected] escreveu:

Esta é a terceira vez que o mesmo appgateway foi para la-la-land. Não consigo parar e
ou atualização:
{
"erro": {
"code": "MissingIdentityIds",
"message": "Os ids de identidade não devem ser nulos ou vazios para 'UserAssigned'
Tipo de Identidade."
}
}

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/33157#issuecomment-618624144 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABD32Z2KPUY7KBFNPTCVMA3ROCLJ3ANCNFSM4HXFRP4A
.

tivemos que levantar outro e usar este porque o original é esquisito! Eu tenho um tíquete com a MS sobre esse problema ... vamos ver se isso será resolvido desta vez?

@ SubhashVasarapu-MSFT há uma maneira de listar os potenciais bloqueadores por que essa inconsistência está acontecendo? Pode ser a causa / limitação raiz.

Seria ainda melhor se obtivéssemos o status atual com a correção.

Como outros neste tópico, também recebi um erro:

Failed to save configuration changes to application gateway <REDACTED>. Error: Either Data or KeyVaultSecretId must be specified for Certificate <REDACTED>...

Na política de acesso do cofre de chaves, habilitei todas as permissões de chave, segredo e certificado para a identidade gerenciada usada pelo Gateway do Azure. Tenho certeza de que isso é um exagero, mas depois de tentar uma combinação de outras permissões, fiquei frustrado e apenas habilitei tudo. Depois disso, o erro foi embora.

PS e2e TLS ao usar um certificado provisionado em nuvem é um cenário supercomum. Como um recém-chegado ao Azure, estou muito desapontado por ainda não ser uma experiência polida.

Tenho tentado obter segredos e certificados do KeyVault para o meu cluster por meio do gateway de aplicativo, o que falha em meu aplicativo, pois não consegue autenticar em KV e isso resulta em um erro de gateway inválido.

ID de conexão "0HM0BI3H5TUJP", ID de solicitação "0HM0BI3H5 TUJP: 00000001 ": Uma exceção não tratada foi lançada pelo aplicativo.
ID de conexão "0HM0BI3H5TUNQ", ID de solicitação "0HM0BI3H5 TUNQ: 00000002 ": uma exceção não tratada foi lançada pelo aplicativo.

Recebo esses erros em meus registros do pod que está tentando buscar o segredo.

Meu KeyVault tem exclusão reversível habilitada com 90 dias padrão definido como período de retenção e rede definida para todas as redes. Minha identidade de gateway de aplicativo também está configurada corretamente no Vault. Alguém sabe onde estou errando?

Tenho trabalhado com um engenheiro de MS
Este é o resumo do que descobri

1. Exclua todos os certificados associados aos ouvintes do Appgateway. Removendo basicamente todos os certificados instalados do appgateway
   para verificar: PS
   Lista de certificados SSL do gateway de rede az -g (grupo de recursos) - nome do gateway (nome do gateway)
   se o seguinte aparecer
   "keyVaultSecretId": null,
   o cert está instalado no appgateway e a maioria pode ser desassociado
2. Assim que o certificado estiver faltando no appgateway, associe o certificado do cofre da chave e ele deve funcionar

Tenho trabalhado com um engenheiro de MS
Este é o resumo do que descobri

1. Exclua todos os certificados associados aos ouvintes do Appgateway. Removendo basicamente todos os certificados instalados do appgateway
   para verificar: PS
   Lista de certificados SSL do gateway de rede az -g (grupo de recursos) - nome do gateway (nome do gateway)
   se o seguinte aparecer
   "keyVaultSecretId": null,
   o cert está instalado no appgateway e a maioria pode ser desassociado
2. Assim que o certificado estiver faltando no appgateway, associe o certificado do cofre da chave e ele deve funcionar

este não é o caso em meu cenário, pois todo o Grupo de Recursos, incluindo o gateway de aplicativo, foi destruído e recriado, mas o problema continua.

Então, presumo que haja um problema com o cofre da chave e como ele se comunica com o apgateway ...
Você deu uma olhada no gerenciador de recursos e executou uma solicitação get - você pode obter um melhor tratamento de erros e / ou executar no modo de depuração

Não estou tocando no Key Vault no momento, para que o suporte da MS possa vê-lo em seu estado atual.

De onde é gerada a mensagem de erro? É a versão 2 com WAF habilitado?

Sim, V2 WAF. O erro vem do ARM. Executado a partir de um Agente Windows hospedado ADO usando AZ CLI

az group deployment create --debug --mode Complete

Nota: o modelo ARM inclui a pilha inteira, VNET, VMs, APG, etc. Com Key Vault e outros persistem em um grupo de recursos separado.

Ah ok….

De: Continuous Delivery Automation Framework [email protected]
Enviado: segunda-feira, 8 de junho de 2020 13:01
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Perera, Priyantha, Arvato SCS [email protected] ; Comentário [email protected]
Assunto: Re: [MicrosoftDocs / azure-docs] Gateway de aplicativo: A integração com o Key Vault não funciona (# 33157)

Sim, V2 WAF. O erro vem do ARM. Executado a partir de um Agente Windows hospedado ADO usando AZ CLI

criação de implantação de grupo az --debug --mode completo

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F33157%23issuecomment-640855594&data = 02% 7C01% 7C% 7C742cf0b3589c42d4021508d80be6b732% 7C1ca8bd943c974fc68955bad266b43f0b% 7C0% 7C0% & 7C637272432826294946 sdata = qdtJwYk5QV8evtt8Bp% 2B1% 2Bn7lkz5ebEG% 2BCMAfdQVmSS4% 3D & reservados = 0 , ou de cancelamento https://eur02.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% & 2FAF2ZC6CPCTZUSOKGAT7F523RVU7RBANCNFSM4HXFRP4A dados = 02% 7C01% 7C% 7C742cf0b3589c42d4021508d80be6b732% 7C1ca8bd943c974fc68955bad266b43f0b% 7C0% 7C0% & 7C637272432826304943 sdata = TgPtoOi5neDLlb% 2B0hk% 2BEULQyZSUFV8fy4deb9RgUsKk% 3D & reservados = 0 .

@ pererap01
você está usando "--mode Complete" - isso remove potencialmente recursos 'ocultos "não definidos no modelo.
Além disso, o usuário / principal de serviço que executa a implantação deve ter a capacidade de ler o MSI que será usado WAF para acessar o KV se este MSI não fizer parte da implantação.

@gaikovoi , acho que essa referência era para mim. Usamos o mesmo ARM e execução em 3 ambientes e todos funcionaram bem. O ambiente DEV era demolido todas as sextas-feiras e recriado todas as segundas-feiras para que a equipe tivesse um ambiente novo para trabalhar durante a semana (às vezes fazíamos uma demolição / montagem ad-hoc se um dos DEV fizesse uma bagunça). Uma semana simplesmente não apareceu, embora nenhum outro aspecto da implantação tenha mudado.

@cdaf houve um problema de ARM hoje
Resolvido: RCA - Azure Resource Manager - Falhas ao criar ou excluir recursos

De qualquer forma, às vezes, as implantações ARM estão falhando sem motivo significativo. Geralmente é consertado pela reexecução do pipeline AzDO.

@gaikovoi , sim, o ARM pode ser muito temperamental (especialmente se você tentar implantar o APIM via ARM), mas não é o caso aqui, ele foi tentado novamente cerca de 30 vezes (por diferentes pessoas tentando diagnosticar)

Olá a todos. Eu criei uma conta apenas para responder a isso porque era muito frustrante. Para quem gosta de mim, não pode ou não quer definir o KeyVault para todas as redes ... Eu encontrei uma solução alternativa. Se você acessar o Explorador de Recursos e excluir o seguinte, isso deve deixar seu App Gateway feliz novamente.

1. Exclua o objeto de identidade
2. Exclua o certificado que causou a falha em sslCertificates
3. Exclua todas as ocorrências de seu ouvinte com falha
4. COLOQUE suas mudanças

Isso causou imediatamente uma atualização do meu App Gateway e o colocou em um estado de provisionamento íntegro. Admito que estava muito esgotado / frustrado com o processo para tentar fazer a integração do KeyVault, então apenas carreguei o certificado diretamente no App Gateway e funcionou bem. A integração do KeyVault realmente precisa ser corrigida pela Microsoft ...

De qualquer forma, espero que ajude alguém.

Felicidades.

Apenas para repetir todas as opções acima. Esse problema definitivamente ainda está presente no Azure e, honestamente, me impressiona.

Depois de adicionar uma identidade gerenciada para gerenciar permissões para um certificado curinga COMPRADO DO AZURE e seguir todas as etapas documentadas para adicionar esse certificado ao gateway, ainda ocorre um erro indicando que a identidade não tem acesso ao cofre. Verifique o cofre e o certificado para garantir que ele de fato tenha acesso, o que tem. Decida promover as permissões de simples somente leitura para proprietário para ver se isso corrige o problema e acerte um erro relacionado aos bloqueios no certificado curinga.

Portanto, não posso apenas não adicionar o certificado por meio do método Key Vault, mas agora tentando limpar itens ou alterar as permissões da identidade depois de tentar várias configurações, não consigo nem mesmo remover a identidade do Azure sem remover o bloqueio "Excluir" o certificado curinga que o cliente adquiriu. Honestamente, o método mais simples que encontrei aqui é exportar o certificado, adicionar uma senha ao arquivo .pfx e, finalmente, carregá-lo novamente durante a criação do Gateway. Isso tudo foi feito por meio da GUI, na esperança de produzir um modelo ARM correto para usar durante o provisionamento via Terraform. Ainda quebrado.

Isso parece uma coisa bastante básica que o Azure fica feliz em ignorar.

Que pesadelo absoluto - não posso acreditar que mais de um ano de feedback e problemas e isso ainda não foi corrigido. Nosso cofre de chaves foi aberto para todas as redes, exclusões suaves foram habilitadas e definidas para 90 dias, e a primeira tentativa de vincular os dois bloqueou o gateway.

Este é realmente um produto muito danificado. 😠

O mesmo aqui. Como isso pode ser um problema aberto por mais de 1 ano. É horrível usar o App Gateway WAF v2.
Quando isso será consertado?

Ainda uma coisa! No meu caso, parece ser a integração de rede keyvault. O portal definitivamente não verifica isso e falha com um erro de chave de propriedade aleatória (um erro não proibido como você esperaria). Alguém pode confirmar se a ativação dos pontos de extremidade do serviço VNET para Microsoft.Keyvault na sub-rede do gateway permitiria que essa integração funcionasse com o KeyVault FW ativado?

Tentativa de "Renovar ou editar" um certificado pré-existente carregado para GW + Use PAAS KV com FW habilitado + IPWhitelist habilitado

Invalid value for the identities '/subscriptions/{sub-id}/resourcegroups/{rg-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{uami-name}'. The 'UserAssignedIdentities' property keys should only be empty json objects, null or the resource exisiting property.

(no mesmo ouvinte acima) Tentativa de "Renovar ou editar" um certificado pré-existente carregado no GW + Usar PAAS KV com FW DESATIVADO

• SUCESSO

_Em um ouvinte diferente_
Tentativa de "Renovar ou editar" um certificado pré-existente carregado no GW + Usar PAAS KV com FW DESATIVADO

• SUCESSO

Olá a todos. Eu criei uma conta apenas para responder a isso porque era muito frustrante. Para quem gosta de mim, não pode ou não quer definir o KeyVault para todas as redes ... Eu encontrei uma solução alternativa. Se você acessar o Explorador de Recursos e excluir o seguinte, isso deve deixar seu App Gateway feliz novamente.

1. Exclua o objeto de identidade
2. Exclua o certificado que causou a falha em sslCertificates
3. Exclua todas as ocorrências de seu ouvinte com falha
4. COLOQUE suas mudanças

Isso causou imediatamente uma atualização do meu App Gateway e o colocou em um estado de provisionamento íntegro. Admito que estava muito esgotado / frustrado com o processo para tentar fazer a integração do KeyVault, então apenas carreguei o certificado diretamente no App Gateway e funcionou bem. A integração do KeyVault realmente precisa ser corrigida pela Microsoft ...

De qualquer forma, espero que ajude alguém.

Felicidades.

Na mesma situação !. Adicionarei o certificado diretamente e não usarei o KeyVault, pois também tenho que restringir o Key Vault a sub-redes
Saúde, Rui

Colisão! Isso ainda é um problema com o Terraform. Se o Firewall estiver ativado no KV, o provisionamento AppGW falhará.

Já tentei muitas coisas:

• No KV ligado
  
  
  
  • Azure Resource Manager para implantação de modelo
  
  
  • Permitir que serviços confiáveis ​​da Microsoft contornem este firewall?
  
  
• Endpoint de serviço na sub-rede AppGW e adição da rede no KV FW
• Adicionando o IP público do AppGW ao KV FW

... Nenhum deles funciona. A única solução é desabilitar o firewall no cofre de chaves.

Também tendo esse problema. Investigue por favor!

Ainda uma coisa! No meu caso, parece ser a integração de rede keyvault. O portal definitivamente não verifica isso e falha com um erro de chave de propriedade aleatória (um erro não proibido como você esperaria). Alguém pode confirmar se a ativação dos pontos de extremidade do serviço VNET para Microsoft.Keyvault na sub-rede do gateway permitiria que essa integração funcionasse com o KeyVault FW ativado?

Tentativa de "Renovar ou editar" um certificado pré-existente carregado para GW + Use PAAS KV com FW habilitado + IPWhitelist habilitado

Invalid value for the identities '/subscriptions/{sub-id}/resourcegroups/{rg-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{uami-name}'. The 'UserAssignedIdentities' property keys should only be empty json objects, null or the resource exisiting property.

(no mesmo ouvinte acima) Tentativa de "Renovar ou editar" um certificado pré-existente carregado no GW + Usar PAAS KV com FW DESATIVADO

* SUCCESS

_Em um ouvinte diferente_
Tentativa de "Renovar ou editar" um certificado pré-existente carregado no GW + Usar PAAS KV com FW DESATIVADO

* SUCCESS

Não parece funcionar para mim. Também tentei muitas combinações. A única solução foi desabilitar totalmente meu firewall KV também.

Este parece ser o caso também para mim; apenas desabilitar totalmente o firewall keyvault faz isso funcionar.

O mesmo problema para mim também ... como isso ainda não pode ser resolvido?

Eu não entendo - nós apenas corremos para isso também. Qual é a configuração adequada aqui ??

Depois de abrir um tíquete com o suporte do Azure, recebi sua resposta oficial:
"Conforme explicado durante nossa conversa, o Gateway de Aplicativo atualmente não oferece suporte à integração com o Key Vault se o Key Vault não estiver configurado para permitir o acesso a“ Endpoints públicos (todas as redes) ”.
No momento, estamos trabalhando internamente com as equipes necessárias para oferecer suporte a todas as configurações de rede no Key Vault com relação à integração com o Gateway de Aplicativo.

A documentação oficial sobre isso está disponível. "

@lonevvolf Você pode abrir o keyvault para todas as redes, vincular o certificado SSL com uma identidade gerenciada para seus ouvintes e, em seguida, firewall do keyvault (ou bloqueá-lo para uma vnet.) Appgw continuará a trabalhar com o certificado _cached_ ssl, mas quando você substituir o certificado no keyvault antes que ele expire, o appgw não será capaz de passar para o certificado renovado. Então, você tem que ter cuidado com isso. Mas sim, está quebrado.

@Microsoft Podemos obter uma atualização sobre este problema, por favor? Ainda não foi resolvido e força seus clientes corporativos do Azure a ter o Key Vault exposto a todas as redes. Já se passou mais de um ano desde que isso foi relatado, tempo suficiente para colocá-lo no roteiro.

Conforme explicado durante nossa conversa, o Gateway de Aplicativo atualmente não oferece suporte à integração com o Key Vault se o Key Vault não estiver configurado para permitir o acesso a “Endpoints públicos (todas as redes)”.
No momento, estamos trabalhando internamente com as equipes necessárias para oferecer suporte a todas as configurações de rede no Key Vault com relação à integração com o Gateway de Aplicativo.

Além disso, essa restrição precisa ser documentada em algum lugar. Podemos colocar essa declaração na documentação da MSFT em algum lugar?

Por exemplo, este documento deve ter a seguinte declaração: https://docs.microsoft.com/en-us/azure/application-gateway/key-vault-certs

@oising como você mencionou "Você pode abrir o keyvault para todas as redes, vincular o certificado SSL com uma identidade gerenciada a seus ouvintes e, em seguida, colocar um firewall no keyvault (ou bloqueá-lo em uma vnet). Appgw continuará a funcionar com o certificado SSL armazenado em cache . "

O az cli oferece suporte a esse recurso? podemos criar ouvinte http no gateway de aplicativo com certificado SSL (puxando-o de certificados de cofre de chaves) usando az cli? Em caso afirmativo, forneça o comando az cli. desde já, obrigado.

@lonevvolf Você pode abrir o keyvault para todas as redes, vincular o certificado SSL com uma identidade gerenciada para seus ouvintes e, em seguida, firewall do keyvault (ou bloqueá-lo para uma vnet.) Appgw continuará a trabalhar com o certificado _cached_ ssl, mas quando você substituir o certificado no keyvault antes que ele expire, o appgw não será capaz de passar para o certificado renovado. Então, você tem que ter cuidado com isso. Mas sim, está quebrado.

Hmm. E se você desativasse o firewall do Key Vault antes de instalar o certificado renovado e, em seguida, ativasse-o novamente depois? O AGW veria a mudança e pegaria o novo certificado com rapidez suficiente enquanto o firewall estava desativado? Atualmente, estou trabalhando em uma função do Azure com um cronômetro para lidar com a renovação do certificado no Key Vault usando certbot / Let's Encrypt. Devo ser capaz de fazer um script de alguns comandos az para desativar e reativar o firewall do Key Vault enquanto o certificado é atualizado no Key Vault.

É bobagem que tudo isso seja mesmo necessário. : /

Alguém sabe se existe algum plano para oferecer suporte a FW no cofre de chaves -> "Endpoint privado e redes selecionadas"?

Adicionando outro comentário para ecoar os sentimentos dos outros. Esse problema é muito frustrante, pois expor todas as redes para o Key Vault muitas vezes não é uma solução para muitas organizações. Estou enfrentando isso usando o Terraform e, no momento, estou tendo que contornar isso. Uma correção da @microsoft seria incrível.

O mesmo para mim, não podemos ter um kv ou appgw aberto para internet e não podemos usar o recurso tanto quanto queremos. : /

Tendo o mesmo problema hoje. :(

Outra opção viável para pessoas irritadas com a luta com appgw é usar o Azure Frontdoor (é basicamente um appgw reduzido), mas ele só funciona em redes públicas (sem vnets) - pode gerar automaticamente certificados SSL públicos voltados para o público.

Estamos trabalhando ativamente para permitir que AppGW funcione com KeyVaults definidos para permitir apenas endpoints privados e acesso à rede selecionada. Conforme a sugestão de @jmcshane , atualizamos os documentos para incluir uma observação importante na seção "Como funciona a integração" com relação a essa limitação. Atualizaremos este tópico e também os documentos assim que o AppGW for capaz de oferecer suporte a todas as configurações do KeyVault.

@skinlayers que podem funcionar - não saberão até que você experimente!

Consegui corrigir isso seguindo as próximas etapas:

• Remova o perfil ssl-cert existente usando az network application-gateway ssl-cert remove
• Desative o firewall temporariamente e permita o acesso de todas as redes
• Vincule o certificado novamente do cofre de chaves azure (verifiquei duas vezes se todas as permissões de identidade de serviço estavam corretas).
• Desative o acesso de todas as redes novamente

Tudo funcionando bem

NOTA: A solução alternativa acima não é recomendada. A Microsoft nos alertou que, como esse método foi usado e o firewall foi habilitado novamente, as futuras operações de escalonamento automático no Gateway de Aplicativo falharão ! Isso realmente precisa de uma correção completa da Microsoft.