Azure Key Vault not getting Vault information from the store path

[sreiutz]

Robert Colbert @ Assurant explained in a call that Orchestrator Azure Keyvault extension for Keyfactor requires optional fields in cert store and it's not getting those details from the store path as needed (during Discovery). Workaround is manually adding the vault name.

See below email from Robert Colbert @ Assurant for details on version tested and his feedback on how to fix:

I just looked at the code for 3.1.2 and it does NOT address the AKV bug where the VaultName property is used for constructing the VaultURL instead of deriving it from the storePath.

There are 2 options for resolving this:

Change how vaultURL is derived to construct it from the storePath provided during discovery Change discovery to populate the VaultName property pushed to Control as part of the discovery process. In my opinion, deriving the URL from the immutable storePath attribute is a cleaner implementation but option 2 is less likely to impact customers.

-Robert

[joevanwanzeeleKF]

Thanks for taking the time to create this issue Robert. To make sure I'm understanding the issue; it is that discovery does not pre-populate the vault name field for newly discovered vaults? As of v 3.1 the vault name field is no longer required. The name is parsed from the store path when needed for the API requests to Azure.
It will be parsed from the store path in the current format: <subscription id>:<resource group name>:<vault name>, and it also supports the legacy store path formats (full resource identifier or <subscription id>:<vault name>.

There is a limitation of the Command platform that only allows the store path value to be returned from discovery jobs, but the vault name field, specifically, is no longer required. The value for this is always retrieved from the store path.

[rmcolbert]

When we ran vault discovery and created the discovered vaults, future KV operations failed w/ errors that the vault was not found or null.

[joevanwanzeeleKF]

If your store types are set up according to versions prior to 3.0 (if they have the vault name field), that field will need to be populated, otherwise you could see that error. If it is missing entirely from the store type definition (as in store type spec for version 3.0+), it will pull the value from the store path.

[rmcolbert]

Ok, so we need to update the store type to remove vaultname and it should work as you described. We'll try that. Thank you.