@DanijelMalik , merci pour vos commentaires. Nous examinons cette requête et vous mettrons à jour dès que possible.

@DanijelMalik , pourrait s'il vous plaît nous fournir la sortie PowerShell pour cette erreur. Qui ressemble à ça,
Remarque: veuillez vous assurer de masquer les zones confidentielles telles que l'identifiant d'abonnement ou les secrets.
{
"status": "Failed",
"Erreur": {
"code": "ApplicationGatewayKeyVaultSecretException",
"message": "Un problème est survenu lors de l'accès et de la validation des secrets KeyVault associés à Application Gateway '/subscriptions/XXXXXXXXXXXXXXXX/resourceGroups/XXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'. Voir les détails ci-dessous:",
"détails": [
{
"code": "ApplicationGatewayKeyVaultSecretAccessDenied",
"message": "Accès refusé pour KeyVault Secret 'XXXXXXXXXXXXXXXXX' pour Application Gateway '/subscriptions/XXXXXXXXXXX/resourceGroups/XXXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'. Assurez-vous que l'identité attribuée à Application Gateway a accès à KeyVault associé au secret. "
}
]
}
}

@DanijelMalik , Je vérifie simplement si vous avez le temps de voir la réponse précédente.

@DanijelMalik , Puisque nous n'avons pas eu de vos nouvelles, nous allons maintenant fermer ce fil. Si vous avez d'autres questions à ce sujet, veuillez m'identifier dans votre réponse. Nous serons heureux de rouvrir la question et de poursuivre la discussion.

Même problème ici.

Pour moi, cela a été résolu en activant la suppression logicielle sur le coffre de clés.

Il existe un problème concernant cette exigence non documentée: # 34382

Salut, je rencontre le même problème. Ce qui semble être le problème, c'est que bien que le keyvault autorise l'accès à partir du sous-réseau appGw (via la lame de paramètres de pare-feu et de réseaux virtuels dans la configuration de keyvault); et le sous-réseau appGw est entré dans New-AzApplicationGateway via l'argument -GatewayIpConfigurations, l'appGw ne semble pas pouvoir accéder au keyvault (l'identité a également des droits d'accès dans les stratégies d'accès au keyvault).

Lorsque j'autorise l'accès au keyvault à partir de "tous les réseaux", cela semble fonctionner correctement.

Peut-être que dans le processus de création appGw, le keyvault est accessible avant que l'appGw ne soit configuré avec le sous-réseau et que le keyvault voit alors cet accès depuis un autre endroit que le sous-réseau?

J'exécute le script PowerShell localement mais mon adresse IP a également accès au coffre de clés, donc cela ne devrait pas être le problème.

Je vois le même problème

@ SubhashVasarapu-MSFT

J'ai le même problème. J'utilise Azure CLI 2.0.76. Ma passerelle d'application et mon coffre de clés se trouvent dans différents groupes de ressources dans le même abonnement. Le coffre de clés a la suppression logicielle activée, peut être accédé à partir de tous les réseaux et dispose d'une stratégie d'accès pour l'identité attribuée à l'utilisateur attribué à la passerelle d'application avec l'autorisation d'obtenir des 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

résultats en (abrégé)

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 je modifie l'écouteur HTTP de la passerelle d'application dans Azure Portal et que j'essaie d'obtenir le certificat SSL à partir du coffre de clés, j'obtiens cette erreur:

Échec de l'enregistrement des modifications de configuration de la passerelle d'application «XXX». Erreur: valeur non valide pour les identités «XXX / fournisseurs / Microsoft.ManagedIdentity / userAssignedIdentities / XXX». Les clés de propriété 'UserAssignedIdentities' ne doivent être que des objets json vides, null ou la propriété de ressource existante.

Salut, je rencontre le même problème. Ce qui semble être le problème, c'est que bien que le keyvault autorise l'accès à partir du sous-réseau appGw (via la lame de paramètres de pare-feu et de réseaux virtuels dans la configuration de keyvault); et le sous-réseau appGw est entré dans New-AzApplicationGateway via l'argument -GatewayIpConfigurations, l'appGw ne semble pas pouvoir accéder au keyvault (l'identité a également des droits d'accès dans les stratégies d'accès au keyvault).

Lorsque j'autorise l'accès au keyvault à partir de "tous les réseaux", cela semble fonctionner correctement.

Peut-être que dans le processus de création appGw, le keyvault est accessible avant que l'appGw ne soit configuré avec le sous-réseau et que le keyvault voit alors cet accès depuis un autre endroit que le sous-réseau?

J'exécute le script PowerShell localement mais mon adresse IP a également accès au coffre de clés, donc cela ne devrait pas être le problème.

Cela a fonctionné pour moi aussi. Le seul changement que j'ai fait de l'échec au succès était d'autoriser tous les réseaux

Si je modifie l'écouteur HTTP de la passerelle d'application dans Azure Portal et que j'essaie d'obtenir le certificat SSL à partir du coffre de clés, j'obtiens cette erreur:

Échec de l'enregistrement des modifications de configuration de la passerelle d'application «XXX». Erreur: valeur non valide pour les identités «XXX / fournisseurs / Microsoft.ManagedIdentity / userAssignedIdentities / XXX». Les clés de propriété 'UserAssignedIdentities' ne doivent être que des objets json vides, null ou la propriété de ressource existante.

@wolfganggallo J'obtiens exactement la même erreur. Mon portail Azure semble également être bloqué dans un état d'erreur et ne me laisse pas apporter de modifications. Avez-vous réussi à résoudre ce problème?

Att: @ SubhashVasarapu-MSFT - veuillez rouvrir.

Je "reçois le même problème:" _Les clés de propriété 'UserAssignedIdentities' ne doivent être que des objets json vides, null ou la ressource existante property_ ", et my - keyvault dans un groupe de ressources et un vnet différents. Je pense que dans mon cas, les vnets ne sont pas appairés, il n'y a donc pas de route entre l'instance APIM et le keyvault au moment de l'exécution, mais l'interface utilisateur du portail Azure répertorie toujours le keyvault comme disponible à utiliser et lui permet d'être lié à l'écouteur. Je vais créer un l'homologation temporaire du réseau virtuel pour voir si cela résout le problème afin que je puisse supprimer l'écouteur. Mon Appgw est actuellement interrompu en conséquence:

MISE À JOUR Oui, c'est le problème. Le portail Azure vous montrera les coffres de clés qui ne sont pas réellement disponibles au moment de l'exécution, et l'enregistrement des paramètres de l'écouteur interrompra votre Appgw. La solution rapide consiste à accéder au coffre de clés et à l'ouvrir temporairement à «tous les réseaux / Internet», puis à réenregistrer votre auditeur. Ce que vous faites alors dépend de vous - copiez le certificat dans un keyvault local, ou ajoutez un peering de réseau virtuel, ou ajoutez le sous-réseau manquant. En fin de compte, le portail devrait valider l'accessibilité du réseau entre appgw et kyvault. Punaise.

2ème MISE À

Je viens de frapper cette erreur également dans l'interface utilisateur du portail. La suppression logicielle est activée. Permettre à tous les réseaux de contourner a fonctionné.

Veuillez rouvrir, pouvoir utiliser la liste blanche est une bonne sécurité.

@ SubhashVasarapu-MSFT Veuillez rouvrir. Nous faisons face à un même problème similaire. L'interface utilisateur du portail est complètement cassée.

Toutes les opérations échouent avec le message suivant:
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 Avez-vous seulement besoin de définir "Autoriser tous les réseaux" pour que l'AppGw fonctionne à nouveau? Nous avons un problème avec les mêmes symptômes, mais nous avons le KeyVault dans le même sous-réseau, peut-être une cause racine différente.

Je ne peux rien faire avec l'interface utilisateur, PowerShell, la CLI ou l'Explorateur de ressources.

@PgInsight @oising Avez-vous seulement besoin de définir "Autoriser tous les réseaux" pour que l'AppGw fonctionne à nouveau? Nous avons un problème avec les mêmes symptômes, mais nous avons le KeyVault dans le même sous-réseau, peut-être une cause racine différente.

Je ne peux rien faire avec l'interface utilisateur, PowerShell, la CLI ou l'Explorateur de ressources.

La définition de tous les réseaux Autoriser sur le KeyVault et nous devions également définir l'indicateur de suppression logicielle sur le Key Vault à l'aide de 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

J'ai eu le même problème. Cependant, j'ai pu résoudre le problème en supprimant le certificat Key Vault à l'aide de PowerShell et non l'explorateur de ressources à l'aide de l'explorateur a montré l'erreur ci-dessous:
{
"Erreur": {
"code": "MissingIdentityIds",
"message": "Les identifiants d'identité ne doivent pas être nuls ou vides pour le type d'identité 'UserAssigned'."
}

}

utilisé l'exemple de script ci-dessous pour supprimer le certificat et l'écouteur et la passerelle d'application est revenue en état de fonctionnement

supprimer l'écouteur et le certificat de l'application gw

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

Sauvegarder les modifications

set-azapplicationgateway -ApplicationGateway $ AppGW

lorsque la passerelle d'application était hors d'état d'échec, j'ai vérifié la politique d'accès du coffre de clés et j'ai vu que l'identité de l'application gw était dans une autre catégorie qui n'est pas "APPLICATION". Je suppose que c'était la cause du problème.
L'identité a de nouveau été ajoutée à la stratégie d'accès à partir du paramètre de coffre-fort de clés et elle a pu s'afficher en tant que «APPLICATION». Cela a résolu le problème pour moi et j'ai pu ajouter un auditeur avec cert depuis le coffre de clés sans problèmes.

@ SubhashVasarapu-MSFT Ceci doit être rouvert. L'App Gateway ne devrait jamais se retrouver dans un état désactivé / cassé comme celui-ci - j'ai à nouveau rencontré le même problème. Comment cela peut-il être escaladé? Ce n'est pas un problème de documentation. Il s'agit d'un problème de qualité du produit.

Résumer:

Lors de la configuration d'un écouteur pour utiliser un certificat SSL dans un keyvault distant, l'interface utilisateur du portail vous permettra de configurer l'écouteur avec un keyvault qui n'est pas disponible au moment de l'exécution sur l'appgw en raison de restrictions réseau (non ouvert à Internet, sous-réseaux sélectionnés uniquement). Une fois cette opération effectuée, l'interface du portail App Gateway est CASSÉE pour tous les écouteurs.

Je transmettrai cela à l'équipe respective.

Quel est le statut de cela?

Nous avons trouvé l'une des causes de cette erreur avec le PG. Si vous aviez la période de rétention sur le KeyVault définie sur quelque chose de différent des 90 jours par défaut, AppGW lançait ce message d'erreur même si vous aviez activé la suppression logicielle et que tout le réseau était défini comme accessibilité. La mise à jour est en cours de déploiement pour corriger ce bogue.

Quand sera-t-il déployé? J'ai également rencontré ce problème et c'est vraiment un gros problème de ne pas pouvoir configurer ou apporter des modifications à partir de Portal une fois que vous l'avez rencontré.

Frappez ça aujourd'hui. Vous avez trouvé ce fil de discussion après avoir défini la rétention de la suppression réversible sur 30 jours et constaté que vous ne pouvez pas le modifier. J'adorerais ce correctif à déployer.

J'ai exactement le même problème, même avec la période de conservation par défaut de 90 jours .
Que vous exécutiez Azure CLI, Powershell, TerraForm ou Portal, j'obtiens toujours la même erreur: «Un problème est survenu lors de l'accès et de la validation des secrets KeyVault associés à Application Gateway…».

Triple vérifié les politiques d'identité et d'accès, toutes les ressources dans le même groupe de ressources à l'emplacement «Europe de l'Ouest»

@ CMS-seglo donc vous dites que vous avez:

• [x] suppression réversible activée
• [x] période de conservation définie sur 90 jours par défaut
• [x] réseau défini sur tout réseau
• [x] et identité appgw correctement configurées

et vous obtenez toujours cette erreur?

@ mark-szabo J'ai toutes ces cases à cocher. Et le modèle ARM me lance une erreur:

"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 propriété est définie comme ceci:

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

Les paramètres sont:

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

ÉDITER:

Même lorsque j'ai changé ARM en son propre certificat SSL avec des données brutes. La propriété d'identité génère toujours la même erreur.

Une solution à cela?

@ mark-szabo merci pour votre réponse, j'ai pu revoir toute la configuration avec un regard neuf et j'ai trouvé un point où ma configuration était différente: le pare-feu KeyVault était réglé sur "Point de terminaison privé et réseaux sélectionnés", mais avec "Autoriser les services Microsoft de confiance à contourner ce pare-feu?" réglé sur activé.
Lorsque j'ai autorisé "Tous les réseaux", j'ai pu créer avec succès un écouteur https dans le portail avec un certificat SSL de KeyVault. Il semble donc qu'il y ait toujours un problème avec les restrictions de réseau.

@ CMS-seglo yup, c'est un problème connu, suivi ici: https://github.com/MicrosoftDocs/azure-docs/issues/48866

@kszymanski Qu'avez-vous défini pour 'certificateSecretUrl'? «some-id» dans votre URL doit être la «version» de l'objet de certificat dans KeyVault. Malheureusement, cela n'est renvoyé ni par 'az keyvault certificate list --vault-name ...' ni par 'Get-AzKeyVaultSecret' ou 'Get-AzKeyVaultCertificate' dans Powershell, mais s'affiche dans le portail lorsque vous regardez le certificat dans KeyVault .

J'ai eu la même erreur trompeuse que vous avez mentionnée ci-dessus, car un certificat «cassé» a été créé. Une fois que j'ai trouvé le bon identifiant, cela a fonctionné.

@kszymanski Qu'avez-vous défini pour 'certificateSecretUrl'? «some-id» dans votre URL doit être la «version» de l'objet de certificat dans KeyVault. Malheureusement, cela n'est renvoyé ni par 'az keyvault certificate list --vault-name ...' ni par 'Get-AzKeyVaultSecret' ou 'Get-AzKeyVaultCertificate' dans Powershell, mais s'affiche dans le portail lorsque vous regardez le certificat dans KeyVault .

J'ai eu la même erreur trompeuse que vous avez mentionnée ci-dessus, car un certificat «cassé» a été créé. Une fois que j'ai trouvé le bon identifiant, cela a fonctionné.

Il est obscurci ici. Je mets un identifiant à partir du portail, j'ai essayé à la fois l'identifiant de certificat et l'identifiant secret sans succès dans les deux cas. De plus, comme mentionné, même la configuration du certificat avec des données brutes et un mot de passe (références Key Vault totalement supprimées) ne change rien, toujours la même erreur. Je pense donc que cela pourrait être un problème avec l'attribution d'identité plutôt que l'URL du certificat de coffre-fort de clé.

J'ai finalement dû télécharger manuellement le certificat et le mot de passe au lieu d'utiliser KeyVault car je ne pouvais pas faire fonctionner le KeyVault. Cependant, si vous le faites à partir du portail une fois que vous obtenez cette erreur, vous devez créer une nouvelle Application Gateway comme quelqu'un d'autre l'a mentionné. Vous ne pourrez pas ajuster votre passerelle erronée pour une raison quelconque.

Donc, comme vous pouvez le voir, je le crée encore et encore à partir du modèle ARM. Et faire le changement manuellement après sa création btw. puis dans le portail, je peux attribuer cette identité et certifier sans aucun problème.

@kylehayes ce n'est pas tout à fait correct. Oui, vous ne pouvez pas le sortir de l'état d'échec du portail actuellement, mais vous pouvez le faire à partir de PowerShell ou de la CLI.

Par exemple. supprimez l'auditeur, la règle et le certificat ayant échoué et mettez à jour le 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

J'ai eu le même problème avec un nouveau KV avec un pare-feu réseau configuré. En tant que test après avoir éteint le pare-feu, il a jeté l'erreur dans le déploiement ARM. Je suis également d'accord que cela doit fonctionner car mon client veut verrouiller le KV.

1. Il existe toujours un problème avec la période de suppression réversible (rétention) non-90 jours. Dans ce cas, l'erreur est "_Les clés de propriété 'UserAssignedIdentities' ne doivent être que des objets json vides, null ou la propriété de ressource existante._ " (BTW, il y a une faute de frappe dans ce message d'erreur.) La solution de contournement consiste à définir la propriété de l'objet KV 'softDeleteRetentionInDays' à 90. Vous pouvez utiliser https://resources.azure.com/ pour cela.

2. Le plan de gestion App GW utilise des adresses IP aléatoires dans Azure DC pour accéder à KV. Voir https://github.com/MicrosoftDocs/azure-docs/issues/48866. Pour contourner ce problème, vous pouvez trouver l'adresse IP à partir des journaux d'audit KV (OMS ou compte de stockage) et l'ajouter à la liste autorisée au lieu d'autoriser tous les réseaux. Malheureusement, rien ne garantit que l'adresse IP restera la même. En outre, vous devez conserver cette adresse IP dans la liste tout le temps, car toute modification de la configuration App GW reconstruit l'ensemble de l'objet de configuration.

Donc, pour réparer l'application GW "cassée", à partir du portail, vous devez:

1. Assurez-vous que la période de suppression logicielle KV est de 90 jours
2. Le pare-feu KV est désactivé
3. effectuer toute action de gestion dans le portail qui déclenchera la mise à jour de l'objet de configuration App GW

Malheureusement, vous devrez toujours utiliser PS pour nettoyer l'objet de configuration des liens vers les certificats dans le KV, car les objets cert ne sont pas exposés dans l'interface utilisateur du portail.

Toute cette histoire d'intégration KV / AppGW devait être mieux testée avant d'être publiée.

Nous avons rencontré le même symptôme ("Les clés de propriété 'UserAssignedIdentities' ne doivent être que des objets json vides, null ou la propriété de ressource existante."), Notre période de suppression logicielle est de 90 jours et le pare-feu est ouvert. Nous avons KV dans un groupe de ressources "persistant" avec la pile d'applications dans un groupe transitoire. Déchiré la pile DEV il y a une semaine et essayé de la remettre en place (via ARM) et le processus échoue sur Application Gateway, ce qui signifie que nous ne pouvons pas faire de développement tant que cela ne fonctionne pas à nouveau.

Je suis également confronté au même problème lors du déploiement à partir du modèle ARM, j'ai gardé la suppression logicielle pendant 90 jours et le pare-feu ouvert pour tous les réseaux, mais toujours confronté au même problème.Il fonctionne à partir du portail mais pas du modèle ARM.
. Les clés de propriété 'UserAssignedIdentities' ne doivent être que des objets json vides, null ou la propriété de ressource existante.

C'est la troisième fois que le même appgateway se rend à la-la-land. Impossible d'arrêter et ou de mettre à jour:
{
"Erreur": {
"code": "MissingIdentityIds",
"message": "Les identifiants d'identité ne doivent pas être nuls ou vides pour le type d'identité 'UserAssigned'."
}
}

Pour être honnête. J'ai abandonné car c'est instable.

Le jeu.23 avril 2020 à 15:46 pererap01 [email protected] a écrit:

C'est la troisième fois que le même appgateway se rend à la-la-land. Je ne peux pas m'arrêter et
ou mettre à jour:
{
"Erreur": {
"code": "MissingIdentityIds",
"message": "Les identifiants d'identité ne doivent pas être nuls ou vides pour 'UserAssigned'
Type d'identité."
}
}

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/33157#issuecomment-618624144 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ABD32Z2KPUY7KBFNPTCVMA3ROCLJ3ANCNFSM4HXFRP4A
.

nous avons dû en tenir un autre et l'utiliser car l'original est floconneux! J'ai un ticket avec MS concernant ce problème ... voyons si ça va être résolu cette fois?

@ SubhashVasarapu-MSFT existe-t-il un moyen de lister les bloqueurs potentiels pourquoi une telle incohérence se produit? Peut être la cause principale / limitation.

Ce serait encore mieux si nous obtenions l'état actuel du correctif.

Comme d'autres dans ce fil, j'ai moi aussi une erreur:

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

Dans la stratégie d'accès du coffre de clés, j'ai activé toutes les autorisations de clé, de secret et de certificat pour l'identité gérée utilisée par Azure Gateway. Je suis sûr que c'est exagéré, mais après avoir essayé un mélange d'autres autorisations, j'ai été frustré et j'ai tout activé. Ensuite, l'erreur a disparu.

PS e2e TLS lors de l'utilisation d'un certificat provisionné dans le cloud est un scénario très courant. En tant que nouveau venu sur Azure, je suis très déçu que ce ne soit pas encore une expérience raffinée.

J'ai essayé de récupérer des secrets et des certificats de KeyVault sur mon cluster via Application Gateway, ce qui fait échouer mon application car elle ne peut pas s'authentifier auprès de KV et cela entraîne une erreur de passerelle incorrecte.

ID de connexion "0HM0BI3H5TUJP", ID de demande "0HM0BI3H5 TUJP: 00000001 ": une exception non
ID de connexion "0HM0BI3H5TUNQ", ID de demande "0HM0BI3H5 TUNQ: 00000002 ": une exception non

J'obtiens ces erreurs sur mes journaux du pod qui essaie de récupérer le secret.

My KeyVault a la suppression réversible activée avec par défaut 90 jours définis comme période de rétention et la mise en réseau définie sur tous les réseaux. Mon identité de passerelle d'application est également configurée correctement sur le coffre-fort. Quelqu'un sait-il où je me trompe?

J'ai travaillé avec un ingénieur de MS
Voici le résumé de ce que j'ai découvert

1. Supprimez tous les certificats associés aux écouteurs Appgateway. Suppression de tous les certificats installés par appgateway
   à vérifier: PS
   az network application-gateway ssl-cert list -g (groupe de ressources) --gateway-name (nom de la passerelle)
   si ce qui suit apparaît
   "keyVaultSecretId": null,
   le cert est installé sur appgateway et la plupart être dissocié
2. Une fois que le certificat est absent de l'appgateway, associez le certificat du coffre de clés et cela devrait fonctionner

J'ai travaillé avec un ingénieur de MS
Voici le résumé de ce que j'ai découvert

1. Supprimez tous les certificats associés aux écouteurs Appgateway. Suppression de tous les certificats installés par appgateway
   à vérifier: PS
   az network application-gateway ssl-cert list -g (groupe de ressources) --gateway-name (nom de la passerelle)
   si ce qui suit apparaît
   "keyVaultSecretId": null,
   le cert est installé sur appgateway et la plupart être dissocié
2. Une fois que le certificat est absent de l'appgateway, associez le certificat du coffre de clés et cela devrait fonctionner

ce n'est pas le cas dans mon scénario car l'ensemble du groupe de ressources, passerelle d'application incluse, a été détruit et recréé, mais ce problème persiste.

Ensuite, je suppose qu'il y a un problème avec le coffre de clés et la façon dont il communique avec l'apgateway ...
Avez-vous jeté un œil au gestionnaire de ressources et exécuté une demande d'obtention - vous pourriez obtenir une meilleure gestion des erreurs et / ou exécuter en mode débogage

Je ne touche pas le Key Vault lui-même pour le moment afin que le support MS puisse le voir dans son état actuel.

D'où est généré le message d'erreur? Est-ce la version 2 avec WAF activé?

Oui, V2 WAF. L'erreur sort d'ARM. Exécuté à partir d'un agent Windows hébergé par ADO à l'aide de l'interface de ligne de commande AZ

az group deployment create --debug --mode Complete

Remarque: le modèle ARM inclut la pile entière, le VNET, les machines virtuelles, l'APG, etc. Avec Key Vault et d'autres persistent dans un groupe de ressources distinct.

Ah ok….

De: Continuous Delivery Automation Framework [email protected]
Envoyé: Lundi 8 juin 2020 13 h 01
À: MicrosoftDocs / azure-docs [email protected]
Cc: Perera, Priyantha, Arvato SCS [email protected] ; Commentaire [email protected]
Objet: Re: [MicrosoftDocs / azure-docs] Application Gateway: l'intégration avec Key Vault ne fonctionne pas (# 33157)

Oui, V2 WAF. L'erreur sort d'ARM. Exécuté à partir d'un agent Windows hébergé par ADO à l'aide de l'interface de ligne de commande AZ

déploiement de groupe az create --debug --mode Complete

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F33157%23issuecomment-640855594&docs = 02% 7C01% 7C% 7C742cf0b3589c42d4021508d80be6b732% 7C1ca8bd943c974fc68955bad266b43f0b% 7C0% 7C0% 7C637272432826294946 & sdata = qdtJwYk5QV8evtt8Bp% 2B1% 2Bn7lkz5ebEG% 2BCMAfdQVmSS4% 3D et réservé = 0 , ou désabonnement https://eur02.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FAF2ZC6CPCTZUSOKGAT7F523RVU7RBANCNFSM4HXFRP4A & data = 02% 7C01% 7C% 7C742cf0b3589c42d4021508d80be6b732% 7C1ca8bd943c974fc68955bad266b43f0b% 7C0% 7C0% 7C637272432826304943 & sdata = TgPtoOi5neDLlb% 2B0hk% 2BEULQyZSUFV8fy4deb9RgUsKk% 3D et réservé = 0 .

@ pererap01
vous utilisez "--mode Complete" - cela supprime potentiellement les ressources "cachées" non définies dans le modèle.
En outre, l'utilisateur / principal de service qui exécute le déploiement doit avoir la capacité de lire le MSI qui sera utilisé WAF pour accéder à KV si ce MSI ne fait pas partie du déploiement.

@gaikovoi , je pense que cette référence était pour moi. Nous utilisons le même ARM et la même exécution sur 3 environnements et ils ont tous bien fonctionné. L'environnement DEV était démoli chaque vendredi et recréé chaque lundi afin que l'équipe ait un nouvel environnement sur lequel travailler tout au long de la semaine (nous faisions parfois un démontage / standup ad hoc si l'un des DEV faisait un gâchis). Une semaine, cela ne s'est tout simplement pas produit, bien qu'aucun autre aspect du déploiement n'ait changé.

@cdaf il y a eu un problème ARM aujourd'hui
Résolu: RCA - Azure Resource Manager - Échecs de création ou de suppression de ressources

Quoi qu'il en soit, parfois, les déploiements ARM échouent sans raison valable. Il est généralement corrigé par réexécution du pipeline AzDO.

@gaikovoi , oui, ARM peut être très capricieux (surtout si vous essayez de déployer APIM via ARM), mais ce n'est pas le cas ici, il a été réessayé près de 30 fois (par différentes personnes essayant de le diagnostiquer)

Salut à tous. J'ai créé un compte juste pour répondre à cela parce que c'était tellement frustrant. Pour tous ceux qui comme moi, ne peuvent pas ou ne veulent pas définir le KeyVault sur tous les réseaux ... j'ai trouvé une solution de contournement. Si vous accédez à l'Explorateur de ressources et supprimez ce qui suit, votre App Gateway devrait à nouveau être heureuse.

1. Supprimer l'objet d'identité
2. Supprimer le certificat qui a causé l'échec sous sslCertificates
3. Supprimer toutes les occurrences de votre auditeur défaillant
4. METTEZ vos modifications

Cela a immédiatement provoqué une mise à jour de mon App Gateway et l'a mis dans un état de provisionnement sain. Certes, j'étais trop épuisé / frustré par le processus pour essayer de faire l'intégration KeyVault, alors j'ai simplement téléchargé le certificat directement sur App Gateway et cela a bien fonctionné. L'intégration KeyVault doit vraiment être corrigée par Microsoft ...

Anywho, j'espère que cela aide quelqu'un.

À votre santé.

Juste pour faire écho à tout ce qui précède. Ce problème est définitivement toujours présent dans Azure et me souffle honnêtement.

Après avoir ajouté une identité gérée pour gérer les autorisations pour un certificat générique ACHETÉ DE AZURE, puis après toutes les étapes documentées pour ajouter ce certificat à la passerelle, une erreur se produit toujours indiquant que l'identité n'a pas accès au coffre-fort. Vérifiez à la fois le coffre-fort et le certificat pour vous assurer qu'il y a effectivement accès, ce qu'il fait. Décidez de promouvoir les autorisations de simple lecture seule au propriétaire pour voir si cela résout le problème et rencontrez une erreur concernant les verrous sur le certificat générique.

Ainsi, non seulement je ne peux pas ajouter le certificat via la méthode Key Vault, mais j'essaie maintenant de nettoyer des éléments ou de modifier les autorisations de l'identité après avoir essayé plusieurs configurations, je ne peux même pas supprimer l'identité d'Azure sans supprimer le verrou «Supprimer» activé le certificat générique acheté par le client. Honnêtement, la méthode la plus simple que j'ai trouvée ici est d'exporter le certificat, d'ajouter un mot de passe au fichier .pfx et enfin de le re-télécharger lors de la création de la passerelle. Tout cela a été fait via l'interface graphique, dans l'espoir de produire un modèle ARM correct à utiliser lors de l'approvisionnement via Terraform. Encore cassé.

Cela semble être une chose assez fondamentale qu'Azure est simplement heureuse d'ignorer.

Quel cauchemar absolu - je ne peux pas croire que plus d'un an de commentaires et de problèmes et que cela ne soit toujours pas résolu. Notre coffre-fort de clés était ouvert à tous les réseaux, les suppressions logicielles ont été activées et définies sur 90 jours, et la première tentative de liaison des deux a bloqué la passerelle.

C'est vraiment un produit très cassé. 😠

Pareil ici. Comment cela peut-il être un problème ouvert pendant plus d'un an. C'est horrible d'utiliser App Gateway WAF v2.
Quand cela sera-t-il corrigé?

Encore une chose! Dans mon cas, il semble s'agir de l'intégration réseau de keyvault. Le portail ne vérifie certainement pas cela et échoue avec une erreur de clé de propriété aléatoire (pas une erreur interdite comme vous vous attendez). Quelqu'un peut-il confirmer si l'activation des points de terminaison du service VNET pour Microsoft.Keyvault sur le sous-réseau de la passerelle permettrait à cette intégration de fonctionner avec KeyVault FW activé?

Tentative de "Renouveler ou modifier" un certificat préexistant téléchargé sur GW + Utiliser PAAS KV avec FW activé + IPWhitelist activé

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.

(sur le même auditeur ci-dessus) Tentative de "Renouveler ou modifier" un certificat préexistant téléchargé sur GW + Utiliser PAAS KV avec FW DÉSACTIVÉ

• SUCCÈS

_Sur un autre auditeur_
Tentative de "Renouveler ou modifier" un certificat préexistant téléchargé sur GW + Utiliser PAAS KV avec FW DÉSACTIVÉ

• SUCCÈS

Salut à tous. J'ai créé un compte juste pour répondre à cela parce que c'était tellement frustrant. Pour tous ceux qui comme moi, ne peuvent pas ou ne veulent pas définir le KeyVault sur tous les réseaux ... j'ai trouvé une solution de contournement. Si vous accédez à l'Explorateur de ressources et supprimez ce qui suit, votre App Gateway devrait à nouveau être heureuse.

1. Supprimer l'objet d'identité
2. Supprimer le certificat qui a causé l'échec sous sslCertificates
3. Supprimer toutes les occurrences de votre auditeur défaillant
4. METTEZ vos modifications

Cela a immédiatement provoqué une mise à jour de mon App Gateway et l'a mis dans un état de provisionnement sain. Certes, j'étais trop épuisé / frustré par le processus pour essayer de faire l'intégration KeyVault, alors j'ai simplement téléchargé le certificat directement sur App Gateway et cela a bien fonctionné. L'intégration KeyVault doit vraiment être corrigée par Microsoft ...

Anywho, j'espère que cela aide quelqu'un.

À votre santé.

Dans la même situation !. J'ajouterai le certificat directement et n'utiliserai pas KeyVault, car je dois également restreindre Key Vault aux sous-réseaux
A bientôt, Rui

Bosse! C'est également un problème avec Terraform. Si le pare-feu est activé sur le KV, l'approvisionnement AppGW échoue.

J'ai déjà essayé beaucoup de choses:

• Sur le KV allumé
  
  
  
  • Azure Resource Manager pour le déploiement de modèles
  
  
  • Autoriser les services Microsoft de confiance à contourner ce pare-feu?
  
  
• Point de terminaison de service sur le sous-réseau AppGW et ajout du réseau sur le KV FW
• Ajout du publicIP de l'AppGW au KV FW

... Aucun d'eux ne fonctionne. La seule solution consiste à désactiver le pare-feu sur le coffre de clés.

Avoir également ce problème. Enquêtez s'il vous plaît!

Encore une chose! Dans mon cas, il semble s'agir de l'intégration réseau de keyvault. Le portail ne vérifie certainement pas cela et échoue avec une erreur de clé de propriété aléatoire (pas une erreur interdite comme vous vous attendez). Quelqu'un peut-il confirmer si l'activation des points de terminaison du service VNET pour Microsoft.Keyvault sur le sous-réseau de la passerelle permettrait à cette intégration de fonctionner avec KeyVault FW activé?

Tentative de "Renouveler ou modifier" un certificat préexistant téléchargé sur GW + Utiliser PAAS KV avec FW activé + IPWhitelist activé

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.

(sur le même auditeur ci-dessus) Tentative de "Renouveler ou modifier" un certificat préexistant téléchargé sur GW + Utiliser PAAS KV avec FW DÉSACTIVÉ

* SUCCESS

_Sur un autre auditeur_
Tentative de "Renouveler ou modifier" un certificat préexistant téléchargé sur GW + Utiliser PAAS KV avec FW DÉSACTIVÉ

* SUCCESS

Cela ne semble pas fonctionner pour moi. J'ai également essayé de nombreuses combinaisons. La seule solution était de désactiver entièrement mon pare-feu KV.

Cela semble être le cas pour moi aussi; seule la désactivation complète du pare-feu keyvault rend cela possible.

Même problème pour moi aussi ... comment cela ne peut-il pas encore être résolu?

Je ne comprends pas - nous venons de rencontrer cela aussi. Quelle est la bonne configuration ici ??

Après avoir ouvert un ticket avec le support Azure, j'ai reçu leur réponse officielle:
«Comme expliqué au cours de notre conversation, Application Gateway ne prend actuellement pas en charge l'intégration avec Key Vault si Key Vault n'est pas configuré pour autoriser l'accès aux« points de terminaison publics (tous les réseaux) ».
Nous travaillons actuellement en interne avec les équipes nécessaires pour prendre en charge toutes les configurations réseau sur Key Vault en ce qui concerne l'intégration avec Application Gateway.

La documentation officielle à ce sujet est à venir. "

@lonevvolf Vous pouvez ouvrir le coffre de clés sur tous les réseaux, lier le certificat SSL avec une identité gérée à vos écouteurs, puis pare-feu le coffre de clés (ou le verrouiller sur un réseau virtuel.) Appgw continuera à fonctionner avec le certificat ssl _cached_, mais quand vous remplacez le certificat dans le keyvault avant son expiration, appgw ne pourra pas revenir au certificat renouvelé. Donc, vous devez faire attention à cela. Mais oui, c'est cassé.

@Microsoft Pouvons-nous obtenir une mise à jour sur ce problème, s'il vous plaît? Il n'est toujours pas résolu et oblige les clients Azure de votre entreprise à exposer Key Vault à tous les réseaux. Cela fait plus d'un an que cela a été signalé, beaucoup de temps pour le mettre sur la feuille de route.

Comme expliqué au cours de notre conversation, Application Gateway ne prend actuellement pas en charge l'intégration avec Key Vault si Key Vault n'est pas configuré pour autoriser l'accès «Public Endpoints (tous les réseaux)».
Nous travaillons actuellement en interne avec les équipes nécessaires pour prendre en charge toutes les configurations réseau sur Key Vault en ce qui concerne l'intégration avec Application Gateway.

En outre, cette restriction doit être documentée quelque part. Pouvons-nous insérer cette déclaration dans la documentation MSFT quelque part?

Par exemple, ce document doit contenir cette déclaration: https://docs.microsoft.com/en-us/azure/application-gateway/key-vault-certs

@oising comme vous l'avez mentionné "Vous pouvez ouvrir le coffre de clés à tous les réseaux, lier le certificat SSL avec une identité gérée à vos écouteurs, puis pare-feu le coffre de clés (ou le verrouiller sur un réseau virtuel.) Appgw continuera à fonctionner avec le certificat SSL mis en cache . "

Az cli prend-il en charge cette fonctionnalité? pouvons-nous créer un écouteur http dans App Gateway avec SSL cert (en le tirant des certificats de coffre-fort de clés) en utilisant az cli? Si tel est le cas, veuillez fournir la commande az cli. Merci d'avance.

@lonevvolf Vous pouvez ouvrir le coffre de clés sur tous les réseaux, lier le certificat SSL avec une identité gérée à vos écouteurs, puis pare-feu le coffre de clés (ou le verrouiller sur un réseau virtuel.) Appgw continuera à fonctionner avec le certificat ssl _cached_, mais quand vous remplacez le certificat dans le keyvault avant son expiration, appgw ne pourra pas revenir au certificat renouvelé. Donc, vous devez faire attention à cela. Mais oui, c'est cassé.

Hmm. Que faire si vous désactivez le pare-feu Key Vault avant d'installer le certificat renouvelé, puis le rallumez par la suite? L'AGW verrait-il le changement et saisirait-il le nouveau certificat assez rapidement pendant que le pare-feu est en panne? Je travaille actuellement sur une fonction Azure avec une minuterie pour gérer le renouvellement du certificat dans Key Vault à l'aide de certbot / Let's Encrypt. Je devrais pouvoir écrire quelques commandes az pour désactiver et réactiver le pare-feu Key Vault pendant que le certificat est mis à jour dans Key Vault.

C'est idiot que tout cela soit même nécessaire. : /

Quelqu'un sait-il s'il existe un plan pour prendre en charge FW sur le coffre de clés -> "Point de terminaison privé et réseaux sélectionnés"?

Ajout d'un autre commentaire pour faire écho aux sentiments des autres. Ce problème est très frustrant, car exposer tous les réseaux pour Key Vault n'est souvent pas une solution pour de nombreuses organisations. Je rencontre cela en utilisant Terraform et je dois actuellement le contourner. Un correctif de @microsoft serait génial.

Pareil pour moi, nous ne pouvons pas avoir de kv ou appgw ouvert à Internet, et nous ne pouvons pas utiliser la fonctionnalité autant que nous le souhaitons. : /

Avoir le même problème aujourd'hui. :(

Une autre option viable pour les personnes en colère contre la lutte avec appgw est d'utiliser Azure Frontdoor (il s'agit essentiellement d'un appgw réduit), mais cela ne fonctionne que sur les réseaux publics (pas de réseaux virtuels) - il peut générer automatiquement des certificats SSL publics.

Nous travaillons activement à permettre à AppGW de fonctionner avec KeyVaults configuré pour autoriser uniquement les points de terminaison privés et sélectionner l'accès au réseau. Conformément à la suggestion de @jmcshane , nous avons mis à jour la documentation pour inclure une note importante dans la section «Comment fonctionne l'intégration» concernant cette limitation. Nous mettrons à jour ce fil ainsi que les documents une fois qu'AppGW sera en mesure de prendre en charge toutes les configurations KeyVault.

@skinlayers qui pourraient fonctionner - ne le saura pas tant que vous ne l'aurez pas essayé!

J'ai pu résoudre ce problème en suivant les étapes suivantes:

• Supprimer le profil ssl-cert existant à l'aide de az network application-gateway ssl-cert remove
• Désactivez temporairement le pare-feu et autorisez l'accès depuis tous les réseaux
• Liez à nouveau le certificat à partir d'Azure Key Vault (j'ai vérifié deux fois que toutes les autorisations d'identité de service étaient correctes).
• Désactivez à nouveau l'accès de tous les réseaux

Tout fonctionne bien

REMARQUE: la solution de contournement ci-dessus n'est pas recommandée. Microsoft nous a alerté que depuis que cette méthode a été utilisée et que le pare-feu a été réactivé, les futures opérations d'autoscaling sur Application Gateway échoueront ! Cela nécessite vraiment un correctif complet de Microsoft.