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 accounttest, accountprd, 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.
We need all special characters available in the name... @, -, _, \, /, .
Should be a default description/notes field. Not having to add tags every time.
There is always a limitation when a product costs so little. This will never be able to replace any password manager when it is delivered half baked.
Sean Li commented
I'm a PM on the Spring on Azure team. In addition to special characters (dot and underscore), I'd like to ask for case sensitivity support. Spring is case sensitive when binding configuration using the @Value annotation. Today we are mapping everything to lower cases but it's causing some issues.
Alternatively it would be great if you could remap the keyvault secrets without dots and underscores to variables in the variable group UI.
mysecret in keyvault
Link keyvault to variable group, add mysecret as My.Secret
reference $(My.Secret) in YAML template
DeJulia, Michael commented
Links to Azure DevOps from key vaults require key mappings if underscores are not supported.
Another request for underscore and dot characters
Łukasz Sobczyk commented
I understand there are requirements on secret names based on web interfaces.
But please create coherent set of forbidden and allowed characters for cloud based solutions.
And coherent case sensitivity behavior of cloud resources.
As it is each resource has different naming restrictions and it is a pain to migrate data/config between resources.
Especially names that are entered by user/instance admin then use different resources with shaded string identifiers.
It feels like dos file naming restrictions - don't use any special characters and care about small size limits.
This leads to very poor name readability on medium size data sets and maintenance issues on bigger sets.
In this particular case i don't understand why is underscore "_" not allowed as secret name.
Also can't we get some endpoints that internally use
to allow full utf-8 support of secret names without dealing with weird names in http?
Currently +, / and = used in base64 are not allowed and secrets are case insensitive, so it cannot be implemented on client side.
And some tool support would be needed to make that convention readable.
Pedro Carvalho commented
. (dot) should be permitted as well!
Shreedhar Thimmegowda commented
Yes _ (underscore) should be permitted. If - (hyphen) is supported why not _ ? Practically we use env variable like DB_NAME not DB-NAME.
Pedro Luis Carvalho commented
Please let Secret names have . since a lot of config files use that.
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 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.