Secret Names do not support special characters
In order for our organization to fully adopt Azure Key Vault for managing passwords and secrets we need to be able to support at a minimum allowing _ (underscrores) and other special characters in the naming convention as we have hundreds of names that contain underscores in them such as account_test, account_prd, etc..
Reading through the documentation online I can't find any technical reason as to why special characters aren't supported but this is a show stopper at this point for us until this is added/supported.
Andrew Sears commented
With AKS and some Linux distros having issues with "-" in environment variable names, it is important that underscores be available in Key Vault secret names to match their environment variable names and ensure consistency.
This has been an issue for a number of years, is there a roadmap for addressing this?
Descriptions of key vault keys & secrets, tagging, and alternate key lookup names for metadata which would support special characters would be very useful.
Rian Finnegan commented
FYI if you want underscores for ASP Net Core sections, then you can use '--' instead
Justin King commented
As an FYI for those stuck, I've seen a few companies get around this by making two variables: a username and password. It doubles the number of entries but it's usable and gets around the limitation.
Still ... have my upvote.
Landin Marqus (SEIT) commented
This is a major limitation for us as well. This needs to be fixed asap.
Clément Fleury commented
This is a major limitation that needs to be fixed !
I don't even understand why this limitation exist and is not documented !
We really need to fix this limitation.
Anson Goldade commented
We're attempting to make our application agnostic of whether configuration information injected at runtime is coming from environment variables or Key Vault. This allows us to be resilient to changes in the decision about where that information is best stored and managed. Environment variables don't allow separating words with a `-` and Key Vault doesn't allow separating words with a `_`. Therefore our goal of being agnostic can't be achieved unless we get rid of word separators and make the names hard to decipher. Not sure what the value of the constraint was, but I can tell you that the consequences of the constraint are frustration.
Jan Lund Christensen commented
I agree. I need the underscores. It would be very nice to be able to use KV Secrets for Terraform using the TF_VAR_ convention.
Agree. We have account including periods. Please fix limitation
Sage McEnery commented
Agreed. We are trying to standardize our Azure DevOps Release Variables to store all Secrets in KeyVault. The lack of support for Underscores makes this approach impossible for us to fully adhere to since the Variable replacements will not work since most of the variables we need replacements for have underscores in their names.
Microsoft, This is a big problem for us. At a minimum, support the allowed logins for current Microsoft products. " / @ _ "
Matias Osca commented
Same here, we really need to be able to store simple characters such as: @, \, _
Darren Whanger commented
Agree....we have lots of names with underscores and periods and I see no technical reason why this needs to be the case. I would like to see more than alphanumeric and dashes be supported. I understand that this needs to be http accessible, but http supports more than alphanumeric plus dash. Please standardize this via http url encoding guidelines....thanks.
Grzegorz Rusin commented
adding some other characters like . or : would allow to create namespace like names... which in turn would allow better organization of keys
Agree with OP, a lot of configuration names have periods and underscores. This drawback of keyvault is unnecessarily complicating our implementation!