@DanijelMalik , Gracias por tus comentarios. Estamos analizando esta consulta y lo actualizaremos lo antes posible.

@DanijelMalik , podría proporcionarnos la salida de PowerShell para este error. Que se parecen a esto,
Nota: asegúrese de enmascarar áreas confidenciales como la identificación de suscripción o secretos.
{
"status": "Fallido",
"error": {
"código": "ApplicationGatewayKeyVaultSecretException",
"message": "Ocurrió un problema al acceder y validar los secretos de KeyVault asociados con Application Gateway '/subscriptions/XXXXXXXXXXXXXXXX/resourceGroups/XXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'. Consulte los detalles a continuación:",
"detalles": [
{
"code": "ApplicationGatewayKeyVaultSecretAccessDenied",
"message": "Acceso denegado para KeyVault Secret 'XXXXXXXXXXXXXXXXX' para Application Gateway '/subscriptions/XXXXXXXXXXX/resourceGroups/XXXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'. Asegúrese de que la identidad asignada a Application Gateway tenga acceso a KeyVault Gateway asociado con el secreto ".
}
]
}
}

@DanijelMalik , Solo comprobando si tienes tiempo para ver la respuesta anterior.

@DanijelMalik , dado que no hemos tenido noticias

El mismo problema aquí.

Para mí, esto se resolvió habilitando la eliminación suave en la bóveda de claves.

Existe un problema por el que este requisito no está documentado: # 34382

Hola, estoy experimentando el mismo problema. Lo que parece ser el problema es que aunque el keyvault permite el acceso desde la subred appGw (a través de la hoja de configuración de Firewalls y redes virtuales en la configuración de keyvault); y la subred appGw se ingresa a New-AzApplicationGateway a través del argumento -GatewayIpConfigurations, la appGw no parece poder acceder a la bóveda de claves (la identidad también tiene derechos de acceso en las políticas de acceso de la bóveda de claves).

Cuando permito el acceso a la bóveda de claves desde "todas las redes", parece funcionar bien.

¿Quizás en el proceso de creación de appGw se accede a la bóveda de claves antes de que la aplicaciónGw esté configurada con la subred y la bóveda de claves ve este acceso desde otro lugar que no sea la subred?

Estoy ejecutando el script de PowerShell localmente, pero mi IP también tiene acceso a la bóveda de claves, por lo que ese no debería ser el problema.

Veo el mismo problema

@ SubhashVasarapu-MSFT

Tengo el mismo problema. Estoy usando Azure CLI 2.0.76. Mi puerta de enlace de aplicaciones y el almacén de claves están en diferentes grupos de recursos en la misma suscripción. La bóveda de claves tiene habilitada la eliminación suave, se puede acceder desde todas las redes y tiene una política de acceso para la identidad asignada al usuario asignado a la puerta de enlace de la aplicación con el permiso de obtención de secretos.

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

da como resultado (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.

Si edito el oyente HTTP de la puerta de enlace de la aplicación en Azure Portal e intento obtener el certificado SSL desde el almacén de claves, aparece este error:

No se pudieron guardar los cambios de configuración en la puerta de enlace de la aplicación 'XXX'. Error: valor no válido para las identidades 'XXX / proveedores / Microsoft.ManagedIdentity / userAssignedIdentities / XXX'. Las claves de propiedad 'UserAssignedIdentities' solo deben ser objetos json vacíos, nulos o la propiedad existente del recurso.

Hola, estoy experimentando el mismo problema. Lo que parece ser el problema es que aunque el keyvault permite el acceso desde la subred appGw (a través de la hoja de configuración de Firewalls y redes virtuales en la configuración de keyvault); y la subred appGw se ingresa a New-AzApplicationGateway a través del argumento -GatewayIpConfigurations, la appGw no parece poder acceder a la bóveda de claves (la identidad también tiene derechos de acceso en las políticas de acceso de la bóveda de claves).

Cuando permito el acceso a la bóveda de claves desde "todas las redes", parece funcionar bien.

¿Quizás en el proceso de creación de appGw se accede a la bóveda de claves antes de que la aplicaciónGw esté configurada con la subred y la bóveda de claves ve este acceso desde otro lugar que no sea la subred?

Estoy ejecutando el script de PowerShell localmente, pero mi IP también tiene acceso a la bóveda de claves, por lo que ese no debería ser el problema.

Esto funcionó para mí también. El único cambio que hice del fracaso al éxito fue permitir que todas las redes

Si edito el oyente HTTP de la puerta de enlace de la aplicación en Azure Portal e intento obtener el certificado SSL desde el almacén de claves, aparece este error:

No se pudieron guardar los cambios de configuración en la puerta de enlace de la aplicación 'XXX'. Error: valor no válido para las identidades 'XXX / proveedores / Microsoft.ManagedIdentity / userAssignedIdentities / XXX'. Las claves de propiedad 'UserAssignedIdentities' solo deben ser objetos json vacíos, nulos o la propiedad existente del recurso.

@wolfganggallo Recibo exactamente el mismo error. Mi portal azul parece estar bloqueado en un estado de error ahora también y no me permite hacer ningún cambio. ¿Conseguiste arreglar esto?

Att: @ SubhashVasarapu-MSFT - vuelva a abrir.

"Tengo el mismo problema:" _Las claves de propiedad 'UserAssignedIdentities' solo deben ser objetos json vacíos, nulos o el recurso existente propiedad_ ", y my - keyvault en un grupo de recursos diferente y vnet. Creo que en mi caso las redes virtuales no están emparejados, por lo que no hay una ruta entre la instancia de APIM y el keyvault en tiempo de ejecución, pero la interfaz de usuario de Azure Portal seguirá enumerando el keyvault como disponible para su uso y permitirá que se vincule al oyente. Voy a crear un emparejamiento temporal de vnet para ver si resuelve el problema para que pueda eliminar el oyente. Mi Appgw está actualmente roto como resultado:

ACTUALIZAR Sí, ese es el problema. El Portal de Azure le mostrará las bóvedas de claves que en realidad no están disponibles en tiempo de ejecución y guardar la configuración del oyente romperá su Appgw. La solución rápida es ir a la bóveda de claves y abrirla temporalmente en "todas las redes / Internet" y luego volver a guardar su oyente. Lo que haga entonces depende de usted: copie el certificado en un almacén de claves local, o agregue un emparejamiento de vnet o agregue la subred que falta. En última instancia, el portal debería validar la accesibilidad de la red entre appgw y kyvault. Insecto.

2ª ACTUALIZACIÓN Para que quede claro: Esto ROMPE por completo la interfaz de usuario del Portal. AppGw NO SE PUEDE arreglar en el portal. Las siguientes partidas guardadas fallan.

Acabo de encontrar este error también en la interfaz de usuario del portal. La eliminación suave está habilitada. Permitir que todas las redes funcionen.

Vuelva a abrir, poder utilizar la lista blanca es una buena seguridad.

@ SubhashVasarapu-MSFT Vuelva a abrir. Estamos lidiando con un mismo problema similar. La interfaz de usuario del portal está completamente rota.

Todas las operaciones fallan con el siguiente mensaje:
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 ¿Solo necesita configurar "Permitir todas las redes" para que AppGw vuelva a funcionar? Tenemos un problema con los mismos síntomas, pero tenemos KeyVault en la misma subred, posiblemente una causa raíz diferente.

No puedo hacer nada usando UI, PowerShell, CLI o Resource Explorer.

@PgInsight @oising ¿Solo necesita configurar "Permitir todas las redes" para que AppGw vuelva a funcionar? Tenemos un problema con los mismos síntomas, pero tenemos KeyVault en la misma subred, posiblemente una causa raíz diferente.

No puedo hacer nada usando UI, PowerShell, CLI o Resource Explorer.

Configurando todas las redes Permitir en KeyVault y también necesitábamos configurar el indicador Soft Delete en Key Vault usando PowerShell cmd.

($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

Tuve el mismo problema. Sin embargo, pude resolver el problema eliminando el certificado de Key Vault usando PowerShell y no el explorador de recursos usando el explorador mostró el siguiente error:
{
"error": {
"code": "MissingIdentityIds",
"message": "Los ID de identidad no deben ser nulos o vacíos para el tipo de identidad 'UserAssigned'".
}

}

usó el siguiente script de muestra para eliminar el certificado y el oyente y la puerta de enlace de la aplicación volvió al estado de trabajo

eliminar oyente y certificado de la aplicación gw

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

guardar cambios

set-azapplicationgateway -ApplicationGateway $ AppGW

cuando la puerta de enlace de la aplicación estaba fuera del estado fallido, verifiqué la política de acceso de la bóveda de claves y vi que la identidad de la aplicación gw estaba en otra categoría que no es "APLICACIÓN". Supongo que esta fue la causa del problema.
Se agregó la identidad nuevamente a la política de acceso desde la configuración de la bóveda de claves y se pudo mostrar como "APLICACIÓN". Esto me resolvió el problema y pude agregar un oyente con certificado desde el almacén de claves sin problemas.

@ SubhashVasarapu-MSFT Esto necesita ser reabierto. La puerta de enlace de la aplicación nunca debería terminar en un estado deshabilitado / roto como este; he vuelto a tener el mismo problema. ¿Cómo se puede escalar esto? Este no es un problema de documentación. Este es un problema de calidad del producto.

Para resumir:

Al configurar un oyente para usar un certificado SSL en un depósito de claves remoto, la interfaz de usuario del portal le permitirá configurar el oyente con un depósito de claves que no está disponible en el tiempo de ejecución para la aplicación debido a restricciones de red (no abierto a Internet, solo subredes seleccionadas). Después de hacer esto, la interfaz del portal de App Gateway está ROTO para todos los oyentes.

Llevaré esto adelante al equipo respectivo.

¿Cuál es el estado de esto?

Hemos encontrado una de las causas de este error con el PG. Si tenía el Período de retención en KeyVault configurado en algo diferente a los 90 días predeterminados, AppGW mostraba este mensaje de error incluso si tenía habilitada la eliminación temporal y toda la red configurada como accesibilidad. La actualización se está implementando actualmente para corregir este error.

¿Cuándo se lanzará? También me encontré con este problema y realmente es un gran problema no poder configurar o realizar ningún cambio desde el Portal una vez que lo haya encontrado.

Solo golpea esto hoy. Encontré este hilo después de configurar la retención de eliminación suave en 30 días y descubrir que no puede cambiarlo. Me encantaría implementar esta solución.

Tengo exactamente el mismo problema incluso con el período de retención predeterminado de 90 días .
Ya sea que ejecute Azure CLI, Powershell, TerraForm o Portal, siempre aparece el mismo error: "Se produjo un problema al acceder y validar los secretos de KeyVault asociados con Application Gateway ...".

Verificó tres veces las políticas de identidad y acceso, todos los recursos en el mismo grupo de recursos en la ubicación 'Europa Occidental'

@ CMS-seglo por lo que está diciendo, que tiene:

• [x] eliminación automática habilitada
• [x] período de retención establecido en los 90 días predeterminados
• [x] redes configuradas para todas las redes
• [x] y la identidad de appgw configuradas correctamente

y sigues recibiendo este error?

@ mark-szabo Tengo todas las casillas marcadas. Y la plantilla ARM me arroja un error:

"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."

La propiedad se establece así:

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

Los parámetros son:

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:

Incluso cuando cambié ARM a su propio certificado ssl con datos sin procesar. La propiedad de identidad todavía arroja el mismo error.

¿Alguna solución a eso?

@ mark-szabo, gracias por su respuesta, pude repasar toda la configuración nuevamente con un par de ojos nuevos y encontré un punto en el que mi configuración era diferente: KeyVault Firewall estaba configurado como "Extremo privado y redes seleccionadas", pero con "¿Permitir que los servicios de Microsoft de confianza eludan este firewall?" establecido en habilitado.
Cuando permití "Todas las redes", pude crear con éxito un oyente https en el portal con un certificado SSL de KeyVault. Parece que todavía hay un problema con las restricciones de la red.

@ CMS-seglo sí, es un problema conocido, que se rastrea aquí: https://github.com/MicrosoftDocs/azure-docs/issues/48866

@kszymanski ¿Qué configuró para el 'certificateSecretUrl'? 'some-id' en su url debe ser la 'versión' del objeto de certificado en KeyVault. Desafortunadamente, esto no lo devuelve 'az keyvault certificate list --vault-name ...' ni por 'Get-AzKeyVaultSecret' o 'Get-AzKeyVaultCertificate' en Powershell, pero se muestra en el Portal cuando mira el certificado en KeyVault .

Tuve el mismo error engañoso que mencionaste anteriormente, porque se creó un certificado 'roto'. Una vez que descubrí la identificación correcta, funcionó.

@kszymanski ¿Qué configuró para el 'certificateSecretUrl'? 'some-id' en su url debe ser la 'versión' del objeto de certificado en KeyVault. Desafortunadamente, esto no lo devuelve 'az keyvault certificate list --vault-name ...' ni por 'Get-AzKeyVaultSecret' o 'Get-AzKeyVaultCertificate' en Powershell, pero se muestra en el Portal cuando mira el certificado en KeyVault .

Tuve el mismo error engañoso que mencionaste anteriormente, porque se creó un certificado 'roto'. Una vez que descubrí la identificación correcta, funcionó.

Está ofuscado aquí. Estoy configurando una identificación desde el portal, probé tanto el Identificador de certificado como el Identificador secreto sin suerte en ambos casos. Además, como se mencionó, incluso configurar el certificado con datos sin procesar y contraseña (referencias de Key Vault totalmente eliminadas) no cambia nada, sigue siendo el mismo error. Así que creo que podría ser un problema con la asignación de identidad en lugar de la URL del certificado del almacén de claves.

Finalmente tuve que cargar manualmente el certificado y la contraseña en lugar de usar KeyVault porque no pude hacer que KeyVault funcionara. Sin embargo, si lo está haciendo desde el portal una vez que recibe este error, debe crear una puerta de enlace de aplicación nueva como mencionó otra persona. No podrá ajustar su puerta de enlace con errores por alguna razón.

Como puede ver, lo estoy creando una y otra vez desde la plantilla ARM. Y hacer cambios manualmente después de que se crea por cierto. luego en el portal puedo asignar esta identidad y certificar sin ningún problema.

@kylehayes eso no es del todo correcto. Sí, no puede sacarlo del estado fallido del portal actualmente, pero puede hacerlo desde PowerShell o la CLI.

P.ej. elimine el oyente, la regla y el certificado fallidos y actualice 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

Tuve el mismo problema con un nuevo KV con un firewall de red configurado. Como prueba, después de apagar el Firewall, arrojó el error en la implementación de ARM. Yo también estoy de acuerdo en que esto debe funcionar ya que mi cliente quiere bloquear el KV.

1. Todavía hay un problema con el período de eliminación (retención) suave que no es de 90 días. En este caso, el error es "_Las claves de propiedad 'UserAssignedIdentities' solo deben ser objetos json vacíos, nulos o la propiedad existente del recurso https://resources.azure.com/ para esto.

2. El plano de administración de App GW usa algunas direcciones IP aleatorias dentro de Azure DC para acceder a KV. Consulte https://github.com/MicrosoftDocs/azure-docs/issues/48866. Como solución alternativa, puede buscar la IP en los registros de auditoría de KV (OMS o cuenta de almacenamiento) y agregarla a la lista de permitidos en lugar de permitir todas las redes. Desafortunadamente, no hay garantía de que la propiedad intelectual se mantenga igual. Además, debe mantener esta IP en la lista todo el tiempo porque cualquier cambio en la configuración de la aplicación GW reconstruye todo el objeto de configuración.

Entonces, para reparar la aplicación GW "rota", desde el portal, debe:

1. Asegúrese de que el período de eliminación suave de KV sea de 90 días
2. El cortafuegos KV está desactivado
3. realizar cualquier acción de gestión en el portal que active la actualización del objeto de configuración de App GW

Desafortunadamente, aún tendrá que usar PS para limpiar el objeto de configuración de los enlaces a los certificados en el KV, ya que los objetos de los certificados no están expuestos en la interfaz de usuario del portal.

Toda esta historia de integración de KV / AppGW tuvo que probarse mejor antes de ser lanzada.

Hemos encontrado el mismo síntoma ("Las claves de propiedad 'UserAssignedIdentities' solo deben ser objetos json vacíos, nulos o la propiedad existente del recurso"), nuestro período de eliminación suave es de 90 días y el firewall está abierto. Tenemos KV en un grupo de recursos "persistente" con la pila de aplicaciones en un grupo transitorio. Rompió la pila DEV hace una semana e intenté volver a ponerla en pie (a través de ARM) y el proceso falla en Application Gateway, lo que significa que no podemos hacer ningún desarrollo hasta que esto funcione nuevamente.

También me enfrento al mismo problema al implementar desde la plantilla ARM, mantuve la eliminación suave como 90 días y el firewall abierto para todas las redes, pero aún tengo el mismo problema. Funciona desde el portal pero no desde la plantilla ARM.
. Las claves de propiedad 'UserAssignedIdentities' solo deben ser objetos json vacíos, nulos o la propiedad existente del recurso.

Esta es la tercera vez que la misma appgateway llega a la-la-land. No puedo detener o actualizar:
{
"error": {
"code": "MissingIdentityIds",
"message": "Los ID de identidad no deben ser nulos o vacíos para el tipo de identidad 'UserAssigned'".
}
}

Sinceramente. Me di por vencido porque es inestable.

El jueves 23 de abril de 2020 a las 3:46 p.m. pererap01 [email protected] escribió:

Esta es la tercera vez que la misma appgateway llega a la-la-land. No puedo parar y
o actualizar:
{
"error": {
"code": "MissingIdentityIds",
"message": "Los ID de identidad no deben ser nulos ni estar vacíos para 'UserAssigned'
Tipo de identidad."
}
}

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/33157#issuecomment-618624144 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/ABD32Z2KPUY7KBFNPTCVMA3ROCLJ3ANCNFSM4HXFRP4A
.

¡Tuvimos que levantar otro y usar esto porque el original es escamoso! Tengo un boleto con MS con respecto a este problema ... veamos si se resuelve esta vez.

@ SubhashVasarapu-MSFT ¿hay alguna manera de enumerar los bloqueadores potenciales por qué está sucediendo tal inconsistencia? Puede ser la causa raíz / limitación.

Sería incluso mejor si obtenemos cuál es el estado actual con la solución.

Como otros en este hilo, yo también recibí un error:

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

En la política de acceso del almacén de claves, habilité todos los permisos de claves, secretos y certificados para la identidad administrada que usa Azure Gateway. Estoy seguro de que esto es excesivo, pero después de probar una combinación de otros permisos, me frustré y habilité todo. Luego, el error desapareció.

PS e2e TLS mientras se usa un certificado aprovisionado en la nube es un escenario muy común. Como recién llegado a Azure, estoy muy decepcionado de que esta no sea una experiencia pulida todavía.

He estado tratando de obtener secretos y certificados de KeyVault en mi clúster a través de Application Gateway, lo que falla mi aplicación ya que no puede autenticarse en KV y eso da como resultado un error de Bad Gateway.

Id. De conexión "0HM0BI3H5TUJP", Id. De solicitud "0HM0BI3H5 TUJP: 00000001 ": la aplicación lanzó una excepción no controlada.
Id. De conexión "0HM0BI3H5TUNQ", Id. De solicitud "0HM0BI3H5 TUNQ: 00000002 ": la aplicación lanzó una excepción no controlada.

Recibo estos errores en mis registros del módulo que está tratando de recuperar el secreto.

Mi KeyVault tiene habilitada la eliminación temporal con 90 días predeterminados establecidos como período de retención y Redes configuradas para todas las redes. My App Gateway Identity también está configurada correctamente en Vault. ¿Alguien sabe dónde me equivoco?

He estado trabajando con un ingeniero de MS
Este es el resumen de lo que he descubierto.

1. Elimine cualquier certificado asociado con los escuchas de Appgateway. Básicamente, eliminar todos los certificados instalados de appgateway
   para comprobar: PS
   az network application-gateway ssl-cert list -g (grupo de recursos) --gateway-name (nombre de la puerta de enlace)
   si aparece lo siguiente
   "keyVaultSecretId": nulo,
   el certificado está instalado en appgateway y la mayoría se desvincula
2. Una vez que falta el certificado de la puerta de enlace de la aplicación, asocie el certificado de la bóveda de claves y debería funcionar

He estado trabajando con un ingeniero de MS
Este es el resumen de lo que he descubierto.

1. Elimine cualquier certificado asociado con los escuchas de Appgateway. Básicamente, eliminar todos los certificados instalados de appgateway
   para comprobar: PS
   az network application-gateway ssl-cert list -g (grupo de recursos) --gateway-name (nombre de la puerta de enlace)
   si aparece lo siguiente
   "keyVaultSecretId": nulo,
   el certificado está instalado en appgateway y la mayoría se desvincula
2. Una vez que falta el certificado de la puerta de enlace de la aplicación, asocie el certificado de la bóveda de claves y debería funcionar

este no es el caso en mi escenario, ya que todo el grupo de recursos, incluida la puerta de enlace de la aplicación, ha sido destruido y recreado, pero este problema continúa.

Entonces mi suposición es que hay un problema con Key vault y cómo se comunica con la apgateway ...
¿Ha echado un vistazo al administrador de recursos y ha ejecutado una solicitud de obtención? Es posible que obtenga un mejor manejo de errores o se ejecute en modo de depuración

No estoy tocando el Key Vault en este momento para que el soporte de MS pueda verlo en su estado actual.

¿De dónde se genera el mensaje de error? ¿Es la versión 2 con WAF habilitado?

Sí, V2 WAF. El error sale de ARM. Ejecutado desde un agente de Windows alojado en ADO utilizando AZ CLI

az group deployment create --debug --mode Complete

Nota: la plantilla ARM incluye la pila completa, VNET, VM, APG, etc. Con Key Vault y otros persisten en un grupo de recursos separado.

Ah está bien….

De: Marco de automatización de entrega continua [email protected]
Enviado: Lunes 8 de junio de 2020 1:01 PM
Para: MicrosoftDocs / azure-docs [email protected]
Cc: Perera, Priyantha, Arvato SCS [email protected] ; Comentario [email protected]
Asunto: Re: [MicrosoftDocs / azure-docs] Application Gateway: la integración con Key Vault no funciona (# 33157)

Sí, V2 WAF. El error sale de ARM. Ejecutado desde un agente de Windows alojado en ADO utilizando AZ CLI

implementación de grupo az crear --debug --mode Complete

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en 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 y sdata = qdtJwYk5QV8evtt8Bp% 2B1% 2Bn7lkz5ebEG% 2BCMAfdQVmSS4% 3D y reservado = 0 , o darse de baja https://eur02.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FAF2ZC6CPCTZUSOKGAT7F523RVU7RBANCNFSM4HXFRP4A y datos = 02% 7C01% 7C% 7C742cf0b3589c42d4021508d80be6b732% 7C1ca8bd943c974fc68955bad266b43f0b% 7C0% 7C0% 7C637272432826304943 y sdata = TgPtoOi5neDLlb% 2B0hk% 2BEULQyZSUFV8fy4deb9RgUsKk% 3D y reservado = 0 .

@ pererap01
está utilizando "--mode Complete": esto potencialmente elimina los recursos "ocultos" no definidos en la plantilla.
Además, el usuario / principal de servicio que ejecuta la implementación debe tener la capacidad de leer MSI que se utilizará WAF para acceder a KV si este MSI no es parte de la implementación.

@gaikovoi , creo que esa referencia fue para mí. Usamos el mismo ARM y ejecución en 3 entornos y todos funcionaron bien. El entorno de DEV se derribaba cada viernes y se recreaba cada lunes para que el equipo tuviera un entorno fresco en el que trabajar durante la semana (a veces hacíamos un desmontaje / standup ad-hoc si uno de los DEV hacía un lío). Una semana simplemente no apareció, aunque ningún otro aspecto del despliegue había cambiado.

@cdaf hubo un problema de ARM hoy
Resuelto: RCA - Azure Resource Manager - Fallos al crear o eliminar recursos

De todos modos, a veces, las implementaciones de ARM fallan sin una razón significativa. Por lo general, se soluciona volviendo a ejecutar la tubería AzDO.

@gaikovoi , sí, ARM puede ser muy temperamental (especialmente si intenta implementar APIM a través de ARM), sin embargo, ese no es el caso aquí, se ha reintentado casi 30 veces (por diferentes personas que intentan diagnosticarlo)

Hola a todos. Creé una cuenta solo para responder a esto porque era muy frustrante. Para cualquiera que como yo, no pueda o no quiera configurar KeyVault en Todas las redes ... encontré una solución. Si va al Explorador de recursos y elimina lo siguiente, su App Gateway debería volver a estar feliz.

1. Eliminar el objeto de identidad
2. Eliminar el certificado que provocó el error en sslCertificates
3. Elimina todas las apariciones de tu oyente fallido
4. PON tus cambios

Esto provocó de inmediato una actualización de mi App Gateway y la puso en un estado de aprovisionamiento saludable. Es cierto que estaba demasiado agotado / frustrado por el proceso para intentar hacer la integración de KeyVault, así que simplemente cargué el certificado directamente en App Gateway y funcionó bien. La integración de KeyVault realmente necesita ser reparada por Microsoft ...

De todos modos, espero que ayude a alguien.

Salud.

Solo para hacerme eco de todo lo anterior. Este problema definitivamente todavía está presente en Azure y honestamente me deja boquiabierto.

Después de agregar una identidad administrada para administrar permisos para un certificado comodín COMPRADO DE AZURE, luego de seguir todos los pasos documentados para agregar este certificado a la puerta de enlace, se sigue produciendo un error que indica que la identidad no tiene acceso a la bóveda. Verifique tanto la bóveda como el certificado para asegurarse de que realmente tenga acceso, lo cual es cierto. Decide promover los permisos de simple lectura a propietario para ver si esto soluciona el problema y muestra un error relacionado con bloqueos en el certificado comodín.

Entonces, no solo no puedo agregar el certificado a través del método de Key Vault, sino que ahora intento limpiar elementos o cambiar los permisos de identidad después de probar múltiples configuraciones, ni siquiera puedo eliminar la identidad de Azure sin quitar el bloqueo "Eliminar" en el certificado comodín que compró el cliente. Honestamente, el método más simple que he encontrado aquí es exportar el certificado, agregar una contraseña al archivo .pfx y finalmente volver a cargarlo durante la creación del Gateway. Todo esto se hizo a través de la GUI, con la esperanza de producir una plantilla ARM correcta para usar durante el aprovisionamiento a través de Terraform. Todavía roto.

Esto parece algo bastante fundamental que Azure simplemente ignora.

Qué pesadilla absoluta: no puedo creer que más de un año de comentarios y problemas y esto aún no se haya solucionado. Nuestra bóveda de claves estaba abierta a todas las redes, las eliminaciones suaves se habilitaron y configuraron en 90 días, y el primer intento de vincular las dos cerró la puerta de enlace.

Este es realmente un producto muy dañado. 😠

Igual que aquí. ¿Cómo puede ser esto un tema abierto durante más de 1 año? Es horrible usar App Gateway WAF v2.
¿Cuándo se va a arreglar esto?

¡Sigue siendo una cosa! En mi caso, parece ser la integración de la red keyvault. El portal definitivamente no verifica eso y falla con un error de claves de propiedad aleatorio (no es un error prohibido como era de esperar). ¿Alguien puede confirmar si habilitar los puntos finales del servicio VNET para Microsoft.Keyvault en la subred de la puerta de enlace permitiría que esta integración funcione con KeyVault FW habilitado?

Intentó "Renovar o editar" un certificado preexistente cargado en GW + Usar PAAS KV con 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.

(en el mismo oyente anterior) Se intentó "Renovar o editar" un certificado preexistente cargado en GW + Usar PAAS KV con FW DISABLED

• ÉXITO

_En un oyente diferente_
Intentó "Renovar o editar" un certificado preexistente cargado en GW + Usar PAAS KV con FW DISABLED

• ÉXITO

Hola a todos. Creé una cuenta solo para responder a esto porque era muy frustrante. Para cualquiera que como yo, no pueda o no quiera configurar KeyVault en Todas las redes ... encontré una solución. Si va al Explorador de recursos y elimina lo siguiente, su App Gateway debería volver a estar feliz.

1. Eliminar el objeto de identidad
2. Eliminar el certificado que provocó el error en sslCertificates
3. Elimina todas las apariciones de tu oyente fallido
4. PON tus cambios

Esto provocó de inmediato una actualización de mi App Gateway y la puso en un estado de aprovisionamiento saludable. Es cierto que estaba demasiado agotado / frustrado por el proceso para intentar hacer la integración de KeyVault, así que simplemente cargué el certificado directamente en App Gateway y funcionó bien. La integración de KeyVault realmente necesita ser reparada por Microsoft ...

De todos modos, espero que ayude a alguien.

Salud.

¡En la misma situación !. Agregaré el certificado directamente y no usaré KeyVault, ya que también tengo que restringir Key Vault a subredes
Saludos, Rui

¡Bache! Esto también es un problema al usar Terraform. Si el firewall está encendido en el KV, el aprovisionamiento de AppGW falla.

Ya probé muchas cosas:

• En el KV encendido
  
  
  
  • Azure Resource Manager para la implementación de plantillas
  
  
  • ¿Permitir que los servicios de Microsoft de confianza eludan este firewall?
  
  
• Service Endpoint en la subred AppGW y agregando la red en el KV FW
• Adición de la IP pública de AppGW a KV FW

... Ninguno de ellos funciona. La única solución es deshabilitar el firewall en el almacén de claves.

También tengo este problema. ¡Por favor investiga!

¡Sigue siendo una cosa! En mi caso, parece ser la integración de la red keyvault. El portal definitivamente no verifica eso y falla con un error de claves de propiedad aleatorio (no es un error prohibido como era de esperar). ¿Alguien puede confirmar si habilitar los puntos finales del servicio VNET para Microsoft.Keyvault en la subred de la puerta de enlace permitiría que esta integración funcione con KeyVault FW habilitado?

Intentó "Renovar o editar" un certificado preexistente cargado en GW + Usar PAAS KV con 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.

(en el mismo oyente anterior) Se intentó "Renovar o editar" un certificado preexistente cargado en GW + Usar PAAS KV con FW DISABLED

* SUCCESS

_En un oyente diferente_
Intentó "Renovar o editar" un certificado preexistente cargado en GW + Usar PAAS KV con FW DISABLED

* SUCCESS

No parece funcionar para mí. También probé muchas combinaciones. La única solución fue desactivar por completo mi cortafuegos KV también.

Este parece ser el caso también para mí; solo deshabilitar completamente el firewall de Keyvault hace que esto funcione.

El mismo problema para mí también ... ¿cómo no se puede resolver esto todavía?

No lo entiendo, también nos encontramos con esto. ¿Cuál es la configuración adecuada aquí?

Después de abrir un ticket con el soporte de Azure, recibí su respuesta oficial:
"Como se explicó durante nuestra conversación, Application Gateway actualmente no es compatible con la integración con Key Vault si Key Vault no está configurado para permitir el acceso a" Puntos finales públicos (todas las redes) ".
Actualmente estamos trabajando internamente con los equipos necesarios para admitir todas las configuraciones de red en Key Vault con respecto a la integración con Application Gateway.

Próximamente se publicará la documentación oficial al respecto ".

@lonevvolf Puede abrir la bóveda de claves a todas las redes, vincular el certificado SSL con una identidad administrada a sus oyentes y luego bloquear la bóveda de claves (o bloquearla en una red virtual). Si reemplaza el certificado en el almacén de claves antes de que caduque, appgw no podrá transferirse al certificado renovado. Entonces, debes tener cuidado con eso. Pero sí, está roto.

@Microsoft ¿Podemos obtener una actualización sobre este tema, por favor? Aún no se ha resuelto y obliga a sus clientes empresariales de Azure a tener Key Vault expuesto a todas las redes. Ha pasado más de un año desde que se informó esto, tiempo de sobra para ponerlo en la hoja de ruta.

Como se explicó durante nuestra conversación, Application Gateway actualmente no es compatible con la integración con Key Vault si Key Vault no está configurado para permitir el acceso de “Puntos finales públicos (todas las redes)”.
Actualmente estamos trabajando internamente con los equipos necesarios para admitir todas las configuraciones de red en Key Vault con respecto a la integración con Application Gateway.

Además, esta restricción debe documentarse en alguna parte. ¿Podemos incluir esta declaración en la documentación de MSFT en algún lugar?

Por ejemplo, este documento debe tener esa declaración: https://docs.microsoft.com/en-us/azure/application-gateway/key-vault-certs

@oising como mencionaste "Puede abrir la bóveda de claves a todas las redes, vincular el certificado SSL con una identidad administrada a sus oyentes y luego bloquear la bóveda de claves (o bloquearla en una vnet). Appgw continuará funcionando con el certificado ssl en caché . "

¿Az cli es compatible con esta función? ¿Podemos crear un oyente http en la puerta de enlace de la aplicación con ssl cert (extrayéndolo de los certificados de key vault) usando az cli? Si es así, puede proporcionar el comando az cli. gracias por adelantado.

@lonevvolf Puede abrir la bóveda de claves a todas las redes, vincular el certificado SSL con una identidad administrada a sus oyentes y luego bloquear la bóveda de claves (o bloquearla en una red virtual). Si reemplaza el certificado en el almacén de claves antes de que caduque, appgw no podrá transferirse al certificado renovado. Entonces, debes tener cuidado con eso. Pero sí, está roto.

Hmm. ¿Qué sucede si apaga el firewall de Key Vault antes de instalar el certificado renovado y luego lo vuelve a encender? ¿Vería el AGW el cambio y obtendría el nuevo certificado lo suficientemente rápido mientras el firewall no funciona? Actualmente estoy trabajando en una función de Azure con un temporizador para manejar la renovación del certificado en Key Vault usando certbot / Let's Encrypt. Debería poder escribir algunos comandos az para deshabilitar y volver a habilitar el firewall de Key Vault mientras el certificado se actualiza en Key Vault.

Es una tontería que algo de esto sea necesario. : /

¿Alguien sabe si hay algún plan para admitir FW en el almacén de claves -> "Punto final privado y redes seleccionadas"?

Agregar otro comentario para hacer eco de los sentimientos de los demás. Este problema es muy frustrante, ya que exponer todas las redes para Key Vault a menudo no es una solución para muchas organizaciones. Me estoy encontrando con esto usando Terraform y actualmente tengo que solucionarlo. Una solución de @microsoft sería increíble.

Lo mismo para mí, no podemos tener un kv o appgw abierto a Internet, y no podemos usar la función tanto como queramos. : /

Tener el mismo problema hoy. :(

Otra opción viable para las personas cabreadas con la lucha con appgw es usar Azure Frontdoor (básicamente es una appgw reducida) pero solo funciona en redes públicas (no vnets): puede generar automáticamente certificados SSL de cara al público.

Estamos trabajando activamente para permitir que AppGW funcione con KeyVaults configurado para permitir solo puntos finales privados y acceso a redes seleccionadas. Según la sugerencia de @jmcshane , hemos actualizado los documentos para incluir una nota importante en la sección "Cómo funciona la integración" con respecto a esta limitación. Actualizaremos este hilo, así como los documentos, una vez que AppGW pueda admitir todas las configuraciones de KeyVault.

@skinlayers que podrían funcionar, ¡no lo sabrán hasta que lo pruebes!

Pude solucionar esto siguiendo los siguientes pasos:

• Elimine el perfil ssl-cert existente mediante az network application-gateway ssl-cert remove
• Deshabilite el firewall temporalmente y permita el acceso desde todas las redes.
• Vuelva a vincular el certificado desde la bóveda de claves azul (verifiqué dos veces que todos los permisos de identidad del servicio estaban bien).
• Deshabilitar el acceso desde todas las redes nuevamente

Todo funciona bien

NOTA: No se recomienda la solución alternativa anterior. Microsoft nos ha alertado de que, dado que se utilizó este método y se volvió a habilitar el firewall, las futuras operaciones de ajuste de escala automático en Application Gateway fallarán . Esto realmente necesita una solución completa de Microsoft.