Secrets using key-vault is broken: performing CreateOrUpdate: unexpected │ status 400 (400 Bad Request) with error

[davidkarlsen]

Please provide us with the following information:

This issue is a: (mark with an x)

• [x] bug report -> please search issues before submitting
• [ ] documentation issue or request
• [ ] regression (a behavior that used to work and stopped in a new release)

Issue description

Accessing secrets backed with keyvault fails with:

│ updating Container App (Subscription:
│ "xxxx"
│ Resource Group Name: "sre-bs-test-nore-rg"
│ Container App Name: "backstage"): performing CreateOrUpdate: unexpected
│ status 400 (400 Bad Request) with error:
│ InvalidParameterValueInContainerTemplate: The following field(s) are either
│ invalid or missing. Field 'configuration.secrets' is invalid with details:
│ 'Invalid value: "postgres-password": Unable to get value using Managed
│ identity
│ /subscriptions/xxxx/resourceGroups/sre-bs-test-nore-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sre-bs-test-nore-uai
│ for secret postgres-password. Error: unable to fetch secret
│ 'postgres-password' using Managed identity
│ '/subscriptions/xxxx/resourceGroups/sre-bs-test-nore-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/sre-bs-test-nore-uai'';.
╵

some facts:

• container-apps environment is assigned UMI
• container-app is assigned same UMI + additional UMI (in order to be able to pull from ACR)
• container-apps environment uses an infra-subnet, and is using a Consumption profile
• the container-apps environment can use the UMI to fetch certificates for custom domain-suffix just fine
• the UMI has Key Vault Secrets User role scoped to the whole KV
• KV uses RBAC-model
• KV is using private-endpoint, same vnet
• Access to KV from container-apps subnet is not blocked by NSG
• KV also has "Allow trusted Microsoft services to bypass this firewall"
• it fails if I use a versioned or non-versioned secret
• subnet where container apps runs also has service-endpoints for: Microsoft.AzureActiveDirectory and Microsoft.KeyVault - but the latter should not have any effect in this case due to the private-endpoint

Steps to reproduce

1. create according to bug
2. see it fail

Expected behavior [What you expected to happen.] should fetch secret

Actual behavior [What actually happened.] See description

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context

fails using portal or terraform

[davidkarlsen]

Are there any grown-ups at home here at all?

[howang-ms]

Sorry for the delay. We have investigated this issue, and it is related to validate code cannot process the secret with large expiration date. We will fix the issue ASAP. In the meantime, you can choose a nearer expiration date for your secret as a workaround.

[anthonychu]

Fix has been deployed.