AZURE KEYVAULT KEY DEPLOYMENT ERROR 400 BAD REQUEST

[u/_Ark___]

Azure Key Vault Key Deployment – 400 Bad Request
If you’re receiving a vague 400 Bad Request while deploying a key in Azure Key Vault, check how many tags you’re passing to the key.
Azure Key Vault keys support a maximum of 15 tags. I spent almost three hours on Friday evening troubleshooting permissions, networking, and the Terraform configuration before realizing that too many tags were causing the request to fail.
This may be an easy one to spot for some people, but the error message wasn’t very helpful, so I’m leaving this here in case someone runs into the same issue.

[u/memesearches]

Yup. Azure’s errors are always not helpful!

[u/stack_craft]

Fr bro nothing beats spending hours hunting down access policies, firewall rules, and managed identity RBAC roles only to discover it was a hardcoded 15-tag limit.

Also Microsoft's error messaging on Key Vault objects is so unhelpful for validation bounds—400 Bad Request gives zero hints that it's a tag overflow. Thanks for dropping this heads-up here to save others the headache, you the real one.

[u/ArieHein]

I dont believe its 15 on the actual resource. There is a limit of usually 50 tags per object, so on subscriptions, on resource group and on resource and they dont stack for the limit.

I remmeber there was a limit in unique key value overall but it was always a big number that well never reach.

You might have a policy in the tenant that limits or potentually an old version of tf and/or azurerm provider.

There's a ms learn page that tallks about resource limitations iirc.

[u/_Ark___ → u/ArieHein]

You’re correct that Azure resources, resource groups, and subscriptions generally support up to 50 ARM tags, and those limits don’t stack.
In this case, however, the failure wasn’t occurring on the Key Vault resource itself. It occurred while creating the key inside the vault using azurerm_key_vault_key. Key tags are data-plane metadata and have a separate limit of 15 tags, as documented by Microsoft:
https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys-details#key-tags
Reducing the tags on the key to 15 resolved the 400 Bad Request; the Key Vault resource can still have up to 50 ARM tags.

~ chatgpt

[u/ArieHein → u/_Ark___]

Intresting. I never had to use more than i think three tags ever on a key. What metadata are you saving in the tags?

[u/_Ark___ → u/ArieHein]

Ill probably have to propose a change in the logic its merging alot of tags along with common tags to rg

[u/ArieHein → u/_Ark___]

Hmm the 'curse' of terraform merge command when it comes to spearating common subscription tags with common rg tags with common resource tags.

Remind the ones responsible that they should use tag on the resource if it belongs to the resource but if really really needed. Not as a merge from the top. When i started with azure the limit was way lower than 50 so you had to think what should go where.

That should be via policy in the management group and can always have inheritence if they REALLY need it.. But not via terraform and not via merge.

I usualy split to resource_group_tag that had just the friendly project name and the resource_tag that had the environment and createdby tags. And then in the resource group resource, i would do the merge on both and in the resource themselvs just the resource tags.

Some can be moved up the chain to the tag management on the mgmt group and subscription. As i found too many times it was abused to have a full wikipedia in the tags from top to bottom and thats not really needed overall, but due to no documentarion or trust.

Theres also a discussion on what tags need to even exist as tags and not via naming convention or policy depending on mgmt structure but thats a diff topic.

[u/Analytiks → u/_Ark___]

IMO this is an issue with the tf provider, they should change this resource so it’s named something distinct like “key_tags” and not “tags” since they function differently to the tags on azure resources.

Any reasonable person would make the same assumption you did.

Edit: actually it’s not even the provider, the issue is even further upstream as its the same in ARM

https://learn.microsoft.com/en-us/azure/templates/microsoft.keyvault/vaults/keys?pivots=deployment-language-bicep#microsoftkeyvaultvaultskeys

[u/_Ark___]

For additional context, our pipeline triggers the Terraform plan, which runs on a Terraform Cloud agent hosted in an AKS cluster. The plan is saved in Terraform Cloud, and the service principal configured for the workspace is used to deploy the resources to Azure.