@DanijelMalik , Terima kasih atas tanggapan Anda. Kami sedang memeriksa pertanyaan ini dan akan memperbarui Anda sesegera mungkin.

@DanijelMalik , Tolong berikan kami output powershell untuk kesalahan ini. Yang terlihat mirip dengan ini,
Catatan: Harap pastikan untuk menutupi area rahasia seperti ID langganan atau rahasia.
{
"status": "Gagal",
"kesalahan": {
"kode": "ApplicationGatewayKeyVaultSecretException",
"message": "Masalah terjadi saat mengakses dan memvalidasi Rahasia KeyVault yang terkait dengan Application Gateway '/subscriptions/XXXXXXXXXXXXXXXX/resourceGroups/XXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'. Lihat detail di bawah:",
"detail": [
{
"code": "ApplicationGatewayKeyVaultSecretAccessDenied",
"message": "Akses ditolak untuk KeyVault Secret 'XXXXXXXXXXXXXXXXX' untuk Application Gateway '/subscriptions/XXXXXXXXXXX/resourceGroups/XXXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'. Pastikan Identity yang ditetapkan ke Application Gateway memiliki akses ke KeyVault terkait dengan rahasia. "
}
]
}
}

@DanijelMalik , Hanya memeriksa apakah Anda punya waktu untuk melihat tanggapan sebelumnya.

@DanijelMalik , Karena kami belum mendengar kabar dari Anda, sekarang kami akan menutup utas ini. Jika ada pertanyaan lebih lanjut tentang masalah ini, harap tandai saya di balasan Anda. Kami dengan senang hati akan membuka kembali masalah tersebut dan melanjutkan diskusi.

Masalah yang sama di sini.

Bagi saya ini diselesaikan dengan mengaktifkan penghapusan lunak pada brankas kunci.

Ada masalah yang ada tentang persyaratan ini yang tidak didokumentasikan: # 34382

Hai, saya mengalami masalah yang sama. Apa yang tampaknya menjadi masalah adalah bahwa meskipun keyvault memungkinkan akses dari subnet appGw (melalui firewall dan bilah pengaturan jaringan virtual dalam konfigurasi keyvault); dan subnet appGw sedang dimasukkan ke New-AzApplicationGateway melalui argumen -GatewayIpConfigurations, appGw tampaknya tidak dapat mengakses keyvault (identitas juga memiliki hak akses dalam kebijakan akses keyvault).

Ketika saya mengizinkan akses ke keyvault dari "semua jaringan" tampaknya berfungsi dengan baik.

Mungkin dalam proses pembuatan appGw, keyvault sedang diakses sebelum appGw dikonfigurasi dengan subnet dan keyvault kemudian melihat akses ini dari tempat lain selain subnet?

Saya menjalankan skrip PowerShell secara lokal tetapi IP saya memiliki akses ke brankas kunci juga jadi itu seharusnya tidak menjadi masalah.

Saya melihat masalah yang sama

@Subasarapu-MS

Saya memiliki masalah yang sama. Saya menggunakan Azure CLI 2.0.76. Gerbang aplikasi dan brankas kunci saya berada di grup sumber daya yang berbeda dalam langganan yang sama. Kubah kunci mengaktifkan hapus lunak, dapat diakses dari semua jaringan dan memiliki kebijakan akses untuk identitas yang ditetapkan pengguna yang ditetapkan oleh gateway aplikasi dengan izin mendapatkan rahasia.

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

hasil dalam (disingkat)

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.

Jika saya mengedit pendengar HTTP gateway aplikasi di Azure Portal dan mencoba mendapatkan sertifikat SSL dari brankas kunci di sana, saya mendapatkan kesalahan ini:

Gagal menyimpan perubahan konfigurasi ke gateway aplikasi 'XXX'. Kesalahan: Nilai tidak valid untuk identitas 'XXX / provider / Microsoft.ManagedIdentity / userAssignedIdentities / XXX'. Kunci properti 'UserAssignedIdentities' hanya boleh berupa objek json kosong, null, atau properti resource yang ada.

Hai, saya mengalami masalah yang sama. Apa yang tampaknya menjadi masalah adalah bahwa meskipun keyvault memungkinkan akses dari subnet appGw (melalui firewall dan bilah pengaturan jaringan virtual dalam konfigurasi keyvault); dan subnet appGw sedang dimasukkan ke New-AzApplicationGateway melalui argumen -GatewayIpConfigurations, appGw tampaknya tidak dapat mengakses keyvault (identitas juga memiliki hak akses dalam kebijakan akses keyvault).

Ketika saya mengizinkan akses ke keyvault dari "semua jaringan" tampaknya berfungsi dengan baik.

Mungkin dalam proses pembuatan appGw, keyvault sedang diakses sebelum appGw dikonfigurasi dengan subnet dan keyvault kemudian melihat akses ini dari tempat lain selain subnet?

Saya menjalankan skrip PowerShell secara lokal tetapi IP saya memiliki akses ke brankas kunci juga jadi itu seharusnya tidak menjadi masalah.

Ini berhasil juga untuk saya. Hanya perubahan yang saya buat dari kegagalan menjadi sukses adalah mengizinkan semua jaringan

Jika saya mengedit pendengar HTTP gateway aplikasi di Azure Portal dan mencoba mendapatkan sertifikat SSL dari brankas kunci di sana, saya mendapatkan kesalahan ini:

Gagal menyimpan perubahan konfigurasi ke gateway aplikasi 'XXX'. Kesalahan: Nilai tidak valid untuk identitas 'XXX / provider / Microsoft.ManagedIdentity / userAssignedIdentities / XXX'. Kunci properti 'UserAssignedIdentities' hanya boleh berupa objek json kosong, null, atau properti resource yang ada.

@wolfganggo Saya mendapatkan kesalahan yang sama persis. Portal biru saya tampaknya juga macet dalam status kesalahan dan tidak mengizinkan saya melakukan perubahan apa pun. Apakah Anda berhasil memperbaikinya?

Att: @ SubhashVasarapu-MSFT - silakan buka kembali.

Saya mendapatkan masalah yang sama: "_Kunci properti 'UserAssignedIdentities' seharusnya hanya berupa objek json kosong, null atau resource yang ada di property_", dan my - keyvault di grup resource dan vnet yang berbeda. Saya rasa dalam kasus saya, vnet tidak di-peering, jadi tidak ada rute antara instance APIM dan keyvault saat runtime, tetapi Azure Portal UI akan tetap mencantumkan keyvault sebagai tersedia untuk digunakan, dan mengizinkannya ditautkan ke pendengar. Saya akan membuat vnet mengintip sementara untuk melihat apakah itu menyelesaikan masalah sehingga saya dapat menghapus pendengar. Appgw saya saat ini rusak sebagai hasilnya:

UPDATE Ya, itulah masalahnya. Portal Azure akan menunjukkan brankas kunci yang sebenarnya tidak tersedia saat runtime, dan menyimpan pengaturan pendengar akan merusak Appgw Anda. Perbaikan cepat adalah pergi ke keyvault dan untuk sementara membukanya ke "semua jaringan / internet" lalu simpan kembali pendengar Anda. Apa yang Anda lakukan kemudian terserah Anda - salin sertifikat ke keyvault lokal, atau tambahkan peering vnet, atau tambahkan subnet yang hilang. Pada akhirnya portal harus memvalidasi aksesibilitas jaringan antara appgw dan kyvault. Bug.

PEMBARUAN ke-2 Hanya untuk memperjelas: Ini benar-benar BREAKS UI Portal. AppGw TIDAK DAPAT diperbaiki melalui portal. Penyimpanan selanjutnya gagal.

Saya baru saja menemukan kesalahan ini juga di Portal UI. Hapus sementara diaktifkan. Mengizinkan semua jaringan bekerja.

Harap buka kembali, dapat menggunakan daftar putih adalah keamanan yang baik.

@ SubashVasarapu-MSL Silakan buka kembali. Kami sedang menghadapi masalah yang sama. UI portal benar-benar rusak.

Setiap operasi gagal dengan pesan berikut:
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 Apakah Anda hanya perlu menyetel "Izinkan Semua Jaringan" agar AppGw berfungsi kembali? Kami memiliki masalah dengan gejala yang sama, tetapi kami memiliki KeyVault di subnet yang sama, mungkin akar penyebab yang berbeda.

Saya tidak dapat melakukan apa pun menggunakan UI, PowerShell, CLI atau Resource Explorer.

@PgInsight @oising Apakah Anda hanya perlu menyetel "Izinkan Semua Jaringan" agar AppGw berfungsi kembali? Kami memiliki masalah dengan gejala yang sama, tetapi kami memiliki KeyVault di subnet yang sama, mungkin akar penyebab yang berbeda.

Saya tidak dapat melakukan apa pun menggunakan UI, PowerShell, CLI atau Resource Explorer.

Mengatur semua jaringan Izinkan pada KeyVault dan kami juga perlu mengatur bendera Hapus Lunak pada Gudang Kunci menggunakan 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

Saya memiliki masalah yang sama. Namun saya dapat menyelesaikan masalah dengan menghapus sertifikat Key Vault menggunakan PowerShell dan bukan penjelajah sumber daya menggunakan explorer menunjukkan kesalahan di bawah ini:
{
"kesalahan": {
"code": "MissingIdentityIds",
"message": "ID identitas tidak boleh nol atau kosong untuk jenis identitas 'UserAssigned'."
}

}

menggunakan contoh skrip di bawah ini untuk menghapus sertifikat dan pemroses dan gateway aplikasi kembali ke status kerja

hapus pendengar dan sertifikat dari aplikasi gw

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

Simpan perubahan

set-azapplicationgateway -ApplicationGateway $ AppGW

ketika gateway aplikasi keluar dari keadaan gagal, saya memeriksa kebijakan akses dari lemari besi kunci dan melihat bahwa identitas aplikasi gw berada di kategori lain yang bukan "APLIKASI". Saya kira inilah penyebab masalahnya.
Menambahkan identitas lagi ke kebijakan akses dari pengaturan lemari besi kunci dan itu dapat ditampilkan sebagai "APPLICATION". Ini memecahkan masalah saya dan saya dapat menambahkan pendengar dengan sertifikat dari brankas kunci tanpa masalah.

@ SubhashVasarapu-MSFT Ini perlu dibuka kembali. App Gateway seharusnya tidak pernah berakhir dalam keadaan cacat / rusak seperti ini - Saya telah mengalami masalah yang sama lagi. Bagaimana ini bisa ditingkatkan? Ini bukan masalah dokumentasi. Ini adalah masalah kualitas produk.

Untuk meringkas:

Saat mengonfigurasi pendengar untuk menggunakan sertifikat SSL di keyvault jarak jauh, UI portal akan memungkinkan Anda mengonfigurasi pendengar dengan keyvault yang tidak tersedia saat runtime ke appgw karena batasan jaringan (tidak terbuka ke internet, hanya subnet yang dipilih). Setelah Anda melakukan ini, antarmuka portal App Gateway RUSAK untuk semua pendengar.

Saya akan meneruskan ini ke tim masing-masing.

Apa statusnya ini?

Kami telah menemukan salah satu penyebab kesalahan ini dengan PG. Jika Anda memiliki Periode Retensi di KeyVault yang diatur ke sesuatu yang berbeda dari default 90 hari, AppGW melemparkan pesan kesalahan ini bahkan jika Anda telah mengaktifkan soft-delete dan semua jaringan disetel sebagai aksesibilitas. Pembaruan sedang diluncurkan untuk memperbaiki bug ini.

Kapan itu akan diluncurkan? Saya juga mengalami masalah ini dan ini benar-benar masalah besar karena tidak dapat mengonfigurasi atau membuat perubahan apa pun dari Portal setelah Anda mengalaminya.

Pukul saja hari ini. Menemukan utas ini setelah menyetel retensi hapus sementara menjadi 30 hari dan ternyata Anda tidak dapat mengubahnya. Akan senang perbaikan ini diluncurkan.

Saya memiliki masalah yang persis sama bahkan dengan periode retensi default 90 hari .
Baik menjalankan Azure CLI, Powershell, TerraForm, atau Portal, saya selalu mendapatkan kesalahan yang sama: "Masalah terjadi saat mengakses dan memvalidasi Rahasia KeyVault yang terkait dengan Application Gateway ...".

Tiga kali memeriksa identitas dan kebijakan akses, semua sumber daya dalam kelompok sumber daya yang sama di lokasi 'Eropa Barat'

@ CMS-seglo jadi Anda memberi tahu, bahwa Anda memiliki:

• Hapus lunak [x] diaktifkan
• Periode retensi [x] disetel ke default 90 hari
• Jaringan [x] disetel ke semua jaringan
• [x] dan identitas appgw dikonfigurasi dengan benar

dan Anda masih mendapatkan kesalahan ini?

@ mark-szabo Saya telah mencentang semua kotak centang itu. Dan template ARM memberi saya kesalahan:

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

Properti diatur seperti ini:

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

Parameternya adalah:

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

EDIT:

Bahkan ketika saya mengubah ARM ke sertifikat ssl itu sendiri dengan data mentah. Properti identitas masih menampilkan kesalahan yang sama.

Ada solusi untuk itu?

@ mark-szabo terima kasih atas balasan Anda, saya dapat meninjau kembali seluruh penyiapan dengan pandangan yang baru dan menemukan satu hal, di mana konfigurasi saya berbeda: KeyVault Firewall disetel ke "Titik akhir pribadi dan jaringan yang dipilih", tetapi dengan "Izinkan layanan Microsoft tepercaya untuk melewati firewall ini?" diatur ke diaktifkan.
Ketika saya mengizinkan "Semua jaringan", saya berhasil membuat pendengar https di portal dengan sertifikat SSL dari KeyVault. Jadi sepertinya masih ada masalah dengan batasan jaringan.

@ CMS-seglo yup, ini adalah masalah yang diketahui, dilacak di sini: https://github.com/MicrosoftDocs/azure-docs/issues/48866

@kszymanski Apa yang Anda setel untuk 'certificateSecretUrl'? 'some-id' di url Anda haruslah 'versi' dari objek sertifikat di KeyVault. Sayangnya, ini tidak dikembalikan oleh 'daftar sertifikat az keyvault --vault-name ...' atau oleh 'Get-AzKeyVaultSecret' atau 'Get-AzKeyVaultCertificate' di Powershell, tetapi ditampilkan di Portal saat Anda melihat sertifikat di KeyVault .

Saya mengalami kesalahan menyesatkan yang sama yang Anda sebutkan di atas, karena sertifikat 'rusak' telah dibuat. Setelah saya menemukan id yang benar, itu berhasil.

@kszymanski Apa yang Anda setel untuk 'certificateSecretUrl'? 'some-id' di url Anda haruslah 'versi' dari objek sertifikat di KeyVault. Sayangnya, ini tidak dikembalikan oleh 'daftar sertifikat az keyvault --vault-name ...' atau oleh 'Get-AzKeyVaultSecret' atau 'Get-AzKeyVaultCertificate' di Powershell, tetapi ditampilkan di Portal saat Anda melihat sertifikat di KeyVault .

Saya mengalami kesalahan menyesatkan yang sama yang Anda sebutkan di atas, karena sertifikat 'rusak' telah dibuat. Setelah saya menemukan id yang benar, itu berhasil.

Itu dikaburkan di sini. Saya menyetel id dari portal, saya sudah mencoba Pengenal Sertifikat dan Pengenal Rahasia tidak berhasil dalam kedua kasus tersebut. Juga seperti yang disebutkan, bahkan sertifikat pengaturan dengan data mentah dan kata sandi (referensi Key Vault yang benar-benar dihapus) tidak mengubah kesalahan yang masih sama. Jadi saya pikir mungkin ada masalah dengan penetapan Identitas daripada URL sertifikat kubah kunci.

Saya akhirnya harus mengunggah sertifikat dan kata sandi secara manual alih-alih menggunakan KeyVault karena saya tidak dapat mengaktifkan KeyVault. Namun, jika Anda melakukannya dari portal setelah mendapatkan kesalahan ini, Anda perlu membuat Gateway Aplikasi baru seperti yang disebutkan orang lain. Anda tidak akan dapat menyesuaikan gateway yang salah karena alasan tertentu.

Jadi seperti yang Anda lihat, saya membuatnya terus-menerus dari template ARM. Dan melakukan perubahan secara manual setelah dibuat btw. kemudian di portal saya dapat menetapkan identitas dan sertifikat ini tanpa masalah.

@kylehayes itu tidak sepenuhnya benar. Ya, Anda tidak dapat mengeluarkannya dari status gagal dari portal saat ini, tetapi Anda dapat melakukannya dari PowerShell atau CLI.

Misalnya. hapus pemroses, aturan, dan sertifikat yang gagal dan perbarui 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

Saya memiliki masalah yang sama dengan KV baru dengan firewall jaringan yang dikonfigurasi. Sebagai tes setelah saya mematikan Firewall itu melemparkan kesalahan dalam penerapan ARM. Saya juga setuju bahwa ini perlu berfungsi karena klien saya ingin mengunci KV.

1. Masih ada masalah dengan periode hapus sementara (retensi) non-90 hari. Dalam kasus ini, kesalahannya adalah "_Kunci properti 'UserAssignedIdentities' hanya boleh berupa objek json kosong, null atau properti yang ada sumber https://resources.azure.com/ untuk ini.

2. Bidang manajemen App GW menggunakan beberapa IP acak dalam Azure DC untuk mengakses KV. Lihat https://github.com/MicrosoftDocs/azure-docs/issues/48866. Sebagai solusinya, Anda dapat menemukan IP dari log audit KV (OMS atau akun penyimpanan) dan menambahkannya ke daftar yang diizinkan alih-alih mengizinkan semua jaringan. Sayangnya, tidak ada jaminan bahwa IP akan tetap sama. Selain itu, Anda harus selalu menyimpan IP ini dalam daftar karena setiap perubahan dalam konfigurasi App GW akan membangun kembali seluruh objek konfigurasi.

Jadi, untuk memperbaiki GW Aplikasi yang "rusak", dari portal, Anda harus:

1. Pastikan periode penghapusan lunak KV adalah 90 hari
2. Firewall KV dinonaktifkan
3. melakukan tindakan pengelolaan apa pun di portal yang akan memicu pembaruan objek konfigurasi GW Aplikasi

Sayangnya, Anda masih harus menggunakan PS untuk membersihkan objek konfigurasi dari tautan ke sertifikat di KV karena objek sertifikat tidak diekspos di UI portal.

Seluruh kisah integrasi KV / AppGW ini harus diuji lebih baik sebelum dirilis.

Kami mengalami gejala yang sama ("Kunci properti 'UserAssignedIdentities' hanya boleh berupa objek json kosong, null atau properti sumber daya yang ada."), Periode penghapusan sementara kami adalah 90 hari dan firewall terbuka. Kami memiliki KV dalam grup sumber daya "persisten" dengan tumpukan aplikasi dalam grup sementara. Merobek tumpukan DEV seminggu yang lalu dan mencoba untuk menahannya kembali (melalui ARM) dan proses gagal di Gateway Aplikasi, yang berarti kami tidak dapat melakukan pengembangan apa pun hingga ini berfungsi lagi.

Saya juga menghadapi masalah yang sama saat menerapkan dari templat ARM, saya tetap menghapus lunak selama 90 hari dan firewall terbuka untuk semua jaringan, tetapi masih menghadapi masalah yang sama. Ini berfungsi dari portal tetapi tidak dari templat ARM.
. Kunci properti 'UserAssignedIdentities' hanya boleh berupa objek json kosong, null, atau properti resource yang ada.

Ini adalah ketiga kalinya appgateway yang sama pergi ke la-la-land. Tidak dapat berhenti dan atau memperbarui:
{
"kesalahan": {
"code": "MissingIdentityIds",
"message": "ID identitas tidak boleh nol atau kosong untuk jenis identitas 'UserAssigned'."
}
}

Sejujurnya. Saya menyerah karena tidak stabil.

Pada Kamis, 23 Apr 2020 pukul 15.46 pererap01 [email protected] menulis:

Ini adalah ketiga kalinya appgateway yang sama pergi ke la-la-land. Tidak bisa berhenti dan
atau perbarui:
{
"kesalahan": {
"code": "MissingIdentityIds",
"message": "ID identitas tidak boleh nol atau kosong untuk 'UserAssigned'
Jenis Identitas."
}
}

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/33157#issuecomment-618624144 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ABD32Z2KPUY7KBFNPTCVMA3ROCLJ3ANCNFSM4HXFRP4A
.

kami harus berdiri satu sama lain dan menggunakan ini karena yang asli bersisik! Saya punya tiket dengan MS tentang masalah ini ... mari kita lihat apakah ini akan diselesaikan kali ini?

@ SubhashVasarapu-MSFT apakah ada cara untuk membuat daftar pemblokir potensial mengapa hal ini tidak konsisten? Mungkin akar penyebab / batasannya.

Akan lebih baik jika kita mendapatkan apa status saat ini dengan perbaikan.

Seperti orang lain di utas ini, saya juga mendapat kesalahan:

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

Dalam kebijakan akses kubah kunci, saya mengaktifkan semua izin kunci, rahasia, dan sertifikat untuk identitas terkelola yang digunakan oleh Azure Gateway. Saya yakin ini berlebihan tetapi setelah mencoba campuran izin lain saya menjadi frustrasi dan hanya mengaktifkan semuanya. Setelah itu kesalahannya hilang.

PS e2e TLS saat menggunakan sertifikat yang disediakan cloud adalah skenario yang sangat umum. Sebagai pendatang baru di Azure, saya sangat kecewa karena ini belum merupakan pengalaman yang bagus.

Saya telah mencoba untuk mengambil rahasia dan sertifikat dari KeyVault ke cluster saya melalui Application Gateway yang gagal aplikasi saya karena tidak dapat mengautentikasi ke KV dan itu menghasilkan kesalahan Gateway Buruk.

ID koneksi "0HM0BI3H5TUJP", ID permintaan "0HM0BI3H5 TUJP: 00000001 ": Aplikasi tidak dapat menangani pengecualian.
ID koneksi "0HM0BI3H5TUNQ", ID permintaan "0HM0BI3H5 TUNQ: 00000002 ": Pengecualian yang tidak tertangani muncul oleh aplikasi.

Saya mendapatkan kesalahan ini di log pod saya yang mencoba mengambil rahasia.

My KeyVault mengaktifkan penghapusan lunak dengan default 90 hari ditetapkan sebagai periode retensi dan Jaringan disetel ke semua jaringan. Identitas Gerbang Aplikasi saya juga dikonfigurasi dengan benar ke Vault. Apakah ada yang tahu di mana kesalahan saya?

Saya telah bekerja dengan seorang Engineer dari MS
Ini ringkasan dari apa yang saya temukan

1. Hapus semua sertifikat yang diasosiasikan dengan pendengar Appgateway. Pada dasarnya menghapus semua sertifikat yang diinstal appgateway
   untuk memeriksa: PS
   az network application-gateway ssl-cert list -g (resource group) --gateway-name (nama gateway)
   jika yang berikut ini muncul
   "keyVaultSecretId": null,
   sertifikat terinstal di appgateway dan sebagian besar akan dipisahkan
2. Setelah sertifikat hilang dari appgateway, kaitkan sertifikat dari brankas kunci dan seharusnya berfungsi

Saya telah bekerja dengan seorang Engineer dari MS
Ini ringkasan dari apa yang saya temukan

1. Hapus semua sertifikat yang diasosiasikan dengan pendengar Appgateway. Pada dasarnya menghapus semua sertifikat yang diinstal appgateway
   untuk memeriksa: PS
   az network application-gateway ssl-cert list -g (resource group) --gateway-name (nama gateway)
   jika yang berikut ini muncul
   "keyVaultSecretId": null,
   sertifikat terinstal di appgateway dan sebagian besar akan dipisahkan
2. Setelah sertifikat hilang dari appgateway, kaitkan sertifikat dari brankas kunci dan seharusnya berfungsi

ini tidak terjadi dalam skenario saya karena seluruh Resource Group, termasuk gateway aplikasi, telah dihancurkan dan dibuat ulang, tetapi masalah ini terus berlanjut.

Kemudian asumsi saya adalah ada masalah dengan Key vault dan bagaimana cara berkomunikasi dengan apgateway ...
Sudahkah Anda melihat pengelola sumber daya dan menjalankan permintaan get- Anda mungkin mendapatkan penanganan kesalahan yang lebih baik dan atau menjalankan dalam mode debug

Saya tidak menyentuh Key Vault itu sendiri saat ini sehingga dukungan MS dapat melihatnya dalam keadaan saat ini.

Dari manakah pesan kesalahan dihasilkan? Apakah ini versi 2 dengan WAF diaktifkan?

Ya, V2 WAF. Kesalahan keluar dari ARM. Dieksekusi dari Agen Windows yang dihosting ADO menggunakan AZ CLI

az group deployment create --debug --mode Complete

Catatan: template ARM menyertakan seluruh tumpukan, VNET, VM, APG, dll. Dengan Key Vault dan persisten lainnya dalam grup sumber daya terpisah.

Ah ok….

Dari: Kerangka Kerja Otomasi Pengiriman Berkelanjutan [email protected]
Dikirim: Senin, 8 Juni 2020 13:01
Kepada: MicrosoftDocs / azure-docs [email protected]
Cc: Perera, Priyantha, Arvato SCS [email protected] ; Komentar [email protected]
Subjek: Re: [MicrosoftDocs / azure-docs] Gerbang Aplikasi: Integrasi dengan Key Vault tidak berfungsi (# 33157)

Ya, V2 WAF. Kesalahan keluar dari ARM. Dieksekusi dari Agen Windows yang dihosting ADO menggunakan AZ CLI

penyebaran grup az buat --debug --mode Selesai

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di 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 & dicadangkan = 0 , atau berhenti berlangganan 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 & dilindungi = 0 .

@ pererap01
Anda menggunakan "--mode Complete" - ini berpotensi menghapus sumber daya 'tersembunyi "yang tidak ditentukan dalam template.
Selain itu, prinsip pengguna / layanan yang menjalankan penerapan harus memiliki kemampuan untuk membaca MSI yang akan digunakan WAF untuk mengakses KV jika MSI ini bukan bagian dari penerapan.

@gaikovoi , saya pikir referensi itu untuk saya. Kami menggunakan ARM dan eksekusi yang sama pada 3 lingkungan dan semuanya bekerja dengan baik. Lingkungan DEV dirobohkan setiap hari Jumat dan dibuat ulang setiap hari Senin sehingga tim memiliki lingkungan baru untuk dikerjakan sepanjang minggu (kami terkadang melakukan pembongkaran / standup ad-hoc jika salah satu DEV membuat kekacauan). Satu minggu itu tidak muncul, meskipun tidak ada aspek lain dari penerapan yang berubah.

@cdaf ada masalah ARM hari ini
Terselesaikan: RCA - Azure Resource Manager - Kegagalan membuat atau menghapus sumber daya

Bagaimanapun, terkadang, penerapan ARM gagal tanpa alasan yang berarti. Ini biasanya diperbaiki oleh pipeline AzDO re-runnig.

@gaikovoi , ya, ARM bisa sangat temperamental (terutama jika Anda mencoba dan menerapkan APIM melalui ARM), namun bukan itu masalahnya di sini, ini telah dicoba ulang hampir 30 kali (oleh orang yang berbeda mencoba mendiagnosisnya)

Halo semua. Saya membuat akun hanya untuk menanggapi ini karena itu sangat membuat frustrasi. Bagi siapa pun yang menyukai saya, tidak dapat atau tidak ingin mengatur KeyVault ke Semua Jaringan ... Saya menemukan solusi. Jika Anda pergi ke Resource Explorer dan menghapus berikut ini, itu akan membuat App Gateway Anda senang lagi.

1. Hapus objek identitas
2. Hapus sertifikat yang menyebabkan kegagalan pada sslCertificates
3. Hapus semua kemunculan pendengar Anda yang gagal
4. Taruh perubahan Anda

Ini segera menyebabkan pembaruan App Gateway saya dan membuatnya dalam status penyediaan yang sehat. Diakui saya terlalu lelah / frustrasi dengan proses untuk mencoba membuat integrasi KeyVault jadi saya hanya mengunggah sertifikat langsung ke App Gateway dan itu berfungsi dengan baik. Integrasi KeyVault benar-benar perlu diperbaiki oleh Microsoft ...

Siapa pun, semoga bisa membantu seseorang.

Bersulang.

Hanya untuk menggemakan semua hal di atas. Masalah ini pasti masih ada di Azure dan sejujurnya mengejutkan saya.

Setelah menambahkan identitas yang dikelola untuk mengelola izin untuk sertifikat wildcard PURCHASED FROM AZURE, lalu mengikuti semua langkah terdokumentasi untuk menambahkan sertifikat ini ke gateway, kesalahan masih terjadi yang menunjukkan bahwa identitas tidak memiliki akses ke vault. Periksa baik vault maupun sertifikat untuk memastikan bahwa ia memang memiliki akses, dan memang demikian. Putuskan untuk mempromosikan izin dari hanya baca sederhana ke pemilik untuk melihat apakah ini memperbaiki masalah, dan tekan kesalahan terkait kunci pada sertifikat karakter pengganti.

Jadi saya tidak hanya tidak dapat menambahkan sertifikat melalui metode Key Vault, tetapi sekarang mencoba untuk membersihkan item atau mengubah izin identitas setelah mencoba beberapa konfigurasi, saya bahkan tidak dapat menghapus identitas dari Azure tanpa menghapus kunci "Hapus" pada sertifikat wildcard yang dibeli klien. Sejujurnya, metode paling sederhana yang saya temukan di sini adalah mengekspor sertifikat, menambahkan kata sandi ke file .pfx dan akhirnya mengunggahnya kembali selama pembuatan Gateway. Ini semua dilakukan melalui GUI, dengan harapan dapat menghasilkan template ARM yang benar untuk digunakan selama penyediaan melalui Terraform. Masih rusak.

Ini sepertinya hal yang cukup mendasar yang dengan senang hati diabaikan oleh Azure.

Sungguh mimpi buruk yang mutlak - Saya tidak percaya bahwa lebih dari setahun umpan balik dan masalah dan ini masih belum diperbaiki. Kubah kunci kami terbuka untuk semua jaringan, penghapusan lunak diaktifkan dan disetel ke 90 hari, dan upaya pertama untuk menghubungkan keduanya menghentikan gateway.

Ini benar-benar produk yang rusak parah. 😠

Sama disini. Bagaimana ini bisa menjadi masalah terbuka selama 1 + tahun. Mengerikan sekali menggunakan App Gateway WAF v2.
Kapan ini akan diperbaiki?

Masih ada! Dalam kasus saya, ini tampaknya merupakan integrasi jaringan keyvault. Portal pasti tidak memeriksanya dan gagal dengan kesalahan kunci properti acak (bukan kesalahan terlarang seperti yang Anda harapkan). Adakah yang bisa mengonfirmasi jika mengaktifkan titik akhir Layanan VNET untuk Microsoft.Keyvault di subnet gateway akan memungkinkan integrasi ini bekerja dengan KeyVault FW diaktifkan?

Mencoba "Memperpanjang atau mengedit" sertifikat yang sudah ada yang diunggah ke GW + Gunakan PAAS KV dengan FW aktif + Daftar Putih IP diaktifkan

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.

(pada pendengar yang sama di atas) Mencoba "Memperpanjang atau mengedit" sertifikat yang sudah ada yang diunggah ke GW + Gunakan PAAS KV dengan FW NONAKTIF

• KEBERHASILAN

_Pada pendengar yang berbeda_
Mencoba "Memperpanjang atau mengedit" sertifikat yang sudah ada yang diunggah ke GW + Gunakan PAAS KV dengan FW NONAKTIF

• KEBERHASILAN

Halo semua. Saya membuat akun hanya untuk menanggapi ini karena itu sangat membuat frustrasi. Bagi siapa pun yang menyukai saya, tidak dapat atau tidak ingin mengatur KeyVault ke Semua Jaringan ... Saya menemukan solusi. Jika Anda pergi ke Resource Explorer dan menghapus berikut ini, itu akan membuat App Gateway Anda senang lagi.

1. Hapus objek identitas
2. Hapus sertifikat yang menyebabkan kegagalan pada sslCertificates
3. Hapus semua kemunculan pendengar Anda yang gagal
4. Taruh perubahan Anda

Ini segera menyebabkan pembaruan App Gateway saya dan membuatnya dalam status penyediaan yang sehat. Diakui saya terlalu lelah / frustrasi dengan proses untuk mencoba membuat integrasi KeyVault jadi saya hanya mengunggah sertifikat langsung ke App Gateway dan itu berfungsi dengan baik. Integrasi KeyVault benar-benar perlu diperbaiki oleh Microsoft ...

Siapa pun, semoga bisa membantu seseorang.

Bersulang.

Dalam situasi yang sama !. Saya akan menambahkan sertifikat secara langsung dan tidak menggunakan KeyVault, karena saya juga harus membatasi Key Vault ke subnet
Bersulang, Rui

Menabrak! Ini masih menjadi masalah saat menggunakan Terraform juga. Jika Firewall dihidupkan di KV, penyediaan AppGW gagal.

Sudah mencoba banyak hal:

• Di KV dihidupkan
  
  
  
  • Azure Resource Manager untuk penerapan template
  
  
  • Izinkan layanan Microsoft tepercaya untuk melewati firewall ini?
  
  
• Layanan Endpoint di subnet AppGW dan menambahkan jaringan di KV FW
• Menambahkan publicIP AppGW ke KV FW

... Tak satu pun dari mereka berhasil. Satu-satunya solusi adalah menonaktifkan firewall di brankas kunci.

Juga mengalami masalah ini. Tolong investigasi!

Masih ada! Dalam kasus saya, ini tampaknya merupakan integrasi jaringan keyvault. Portal pasti tidak memeriksanya dan gagal dengan kesalahan kunci properti acak (bukan kesalahan terlarang seperti yang Anda harapkan). Adakah yang bisa mengonfirmasi jika mengaktifkan titik akhir Layanan VNET untuk Microsoft.Keyvault di subnet gateway akan memungkinkan integrasi ini bekerja dengan KeyVault FW diaktifkan?

Mencoba "Memperpanjang atau mengedit" sertifikat yang sudah ada yang diunggah ke GW + Gunakan PAAS KV dengan FW aktif + Daftar Putih IP diaktifkan

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.

(pada pendengar yang sama di atas) Mencoba "Memperpanjang atau mengedit" sertifikat yang sudah ada yang diunggah ke GW + Gunakan PAAS KV dengan FW NONAKTIF

* SUCCESS

_Pada pendengar yang berbeda_
Mencoba "Memperpanjang atau mengedit" sertifikat yang sudah ada yang diunggah ke GW + Gunakan PAAS KV dengan FW NONAKTIF

* SUCCESS

Sepertinya tidak berhasil untuk saya. Saya juga mencoba banyak kombinasi. Satu-satunya solusi adalah menonaktifkan firewall KV saya sepenuhnya.

Sepertinya ini juga yang terjadi pada saya; hanya menonaktifkan firewall keyvault sepenuhnya yang membuat ini berfungsi.

Masalah yang sama untuk saya juga ... bagaimana ini belum bisa diselesaikan?

Saya tidak mengerti - kami baru saja mengalami ini juga. Apa konfigurasi yang tepat di sini ??

Setelah membuka tiket dengan dukungan Azure, saya telah menerima jawaban resmi mereka:
"Seperti yang dijelaskan selama percakapan kita, Gateway Aplikasi saat ini tidak mendukung integrasi dengan Key Vault jika Key Vault tidak dikonfigurasi untuk mengizinkan akses" Titik Akhir Publik (semua jaringan) ".
Kami saat ini bekerja secara internal dengan tim yang diperlukan untuk mendukung semua konfigurasi jaringan di Key Vault sehubungan dengan integrasi dengan Application Gateway.

Dokumentasi resmi tentang ini akan datang. "

@lonevvolf Anda dapat membuka keyvault ke semua jaringan, mengikat SSL Cert dengan identitas terkelola ke pendengar Anda dan kemudian mem-firewall keyvault (atau menguncinya ke vnet.) Appgw akan terus bekerja dengan sertifikat _cached_ ssl, tetapi kemudian ketika Anda mengganti sertifikat di keyvault sebelum kadaluwarsa, appgw tidak akan dapat dialihkan ke sertifikat yang diperbarui. Jadi, Anda harus berhati-hati tentang itu. Tapi ya, itu rusak.

@Microsoft Bisakah kami mendapatkan pembaruan tentang masalah ini? Masalah ini masih belum terselesaikan dan memaksa pelanggan Azure perusahaan Anda agar Vault Kunci diekspos ke Semua Jaringan. Sudah lebih dari setahun sejak laporan ini dilaporkan, banyak waktu untuk meletakkannya di peta jalan.

Seperti yang dijelaskan selama percakapan kita, Gateway Aplikasi saat ini tidak mendukung integrasi dengan Key Vault jika Key Vault tidak dikonfigurasi untuk mengizinkan akses "Titik Akhir Publik (semua jaringan)".
Kami saat ini bekerja secara internal dengan tim yang diperlukan untuk mendukung semua konfigurasi jaringan di Key Vault sehubungan dengan integrasi dengan Application Gateway.

Selain itu, pembatasan ini perlu didokumentasikan di suatu tempat. Bisakah kita memasukkan pernyataan ini ke dalam dokumentasi MSFT di suatu tempat?

Misalnya, dokumen ini harus memiliki pernyataan itu: https://docs.microsoft.com/en-us/azure/application-gateway/key-vault-certs

@oising seperti yang Anda sebutkan "Anda dapat membuka keyvault ke semua jaringan, mengikat SSL Cert dengan identitas terkelola ke pendengar Anda dan kemudian mem-firewall keyvault (atau menguncinya ke vnet.) Appgw akan terus bekerja dengan sertifikat ssl yang di-cache . "

Apakah az cli mendukung fitur ini? dapatkah kita membuat pendengar http di gerbang Aplikasi dengan sertifikat ssl (menariknya dari sertifikat kubah kunci) menggunakan az cli? Jika demikian, bisakah Anda memberikan perintah az cli. Terima kasih sebelumnya.

@lonevvolf Anda dapat membuka keyvault ke semua jaringan, mengikat SSL Cert dengan identitas terkelola ke pendengar Anda dan kemudian mem-firewall keyvault (atau menguncinya ke vnet.) Appgw akan terus bekerja dengan sertifikat _cached_ ssl, tetapi kemudian ketika Anda mengganti sertifikat di keyvault sebelum kadaluwarsa, appgw tidak akan dapat dialihkan ke sertifikat yang diperbarui. Jadi, Anda harus berhati-hati tentang itu. Tapi ya, itu rusak.

Hmm. Bagaimana jika Anda mematikan firewall Key Vault sebelum memasang sertifikat yang diperbarui, dan kemudian menyalakannya kembali setelah itu? Akankah AGW melihat perubahan tersebut, dan mengambil sertifikat baru dengan cukup cepat saat firewall mati? Saat ini saya mengerjakan Fungsi Azure dengan timer untuk menangani pembaruan sertifikat di Key Vault menggunakan certbot / Let's Encrypt. Saya seharusnya dapat membuat skrip beberapa az perintah untuk menonaktifkan dan mengaktifkan kembali firewall Key Vault saat sertifikat diperbarui di Key Vault.

Konyol sekali bahwa semua ini perlu. : /

Adakah yang tahu jika ada rencana untuk mendukung FW pada lemari besi kunci -> "Titik akhir pribadi dan jaringan yang dipilih"?

Menambahkan komentar lain untuk menggemakan sentimen orang lain. Masalah ini sangat menjengkelkan, karena mengekspos semua jaringan untuk Key Vault sering kali bukan merupakan solusi bagi banyak organisasi. Saya mengalami ini menggunakan Terraform dan saat ini saya harus mengatasinya. Perbaikan dari @microsoft akan luar biasa.

Sama untuk saya, kami tidak dapat membuka kv atau appgw internet, dan tidak dapat menggunakan fitur tersebut sebanyak yang kami inginkan. : /

Mengalami masalah yang sama hari ini. :(

Opsi lain yang layak untuk orang-orang yang kesal dengan perjuangan dengan appgw adalah dengan menggunakan Azure Frontdoor (pada dasarnya ini adalah appgw yang dipangkas) tetapi hanya berfungsi di jaringan publik (tanpa vnet) - itu dapat membuat otomatis sertifikat SSL yang dihadapi publik.

Kami secara aktif bekerja untuk mengizinkan AppGW bekerja dengan KeyVaults yang disetel untuk hanya mengizinkan titik akhir pribadi dan akses jaringan tertentu. Sesuai saran @jmcshane , kami telah memperbarui dokumen untuk menyertakan catatan penting di bawah bagian "Bagaimana integrasi bekerja" terkait batasan ini. Kami akan memperbarui utas ini serta dokumennya setelah AppGW dapat mendukung semua konfigurasi KeyVault.

@skinlayers yang bisa bekerja - tidak akan tahu sampai Anda mencobanya!

Saya dapat memperbaikinya dengan mengikuti langkah-langkah selanjutnya:

• Hapus profil ssl-cert yang ada menggunakan aplikasi-gateway jaringan az ssl-cert remove
• Nonaktifkan firewall untuk sementara dan izinkan akses dari semua jaringan
• Ikat sertifikat lagi dari kubah kunci biru (Saya memeriksa dua kali bahwa semua izin identitas layanan baik-baik saja).
• Nonaktifkan akses dari semua jaringan lagi

Semuanya bekerja dengan baik

CATATAN: Solusi di atas tidak disarankan. Microsoft telah memberi tahu kami bahwa sejak metode ini digunakan, dan firewall diaktifkan lagi, operasi penskalaan otomatis di masa mendatang pada Application Gateway akan gagal ! Ini benar-benar membutuhkan perbaikan penuh dari Microsoft.