KeyVaultClientException: Operation "get" is not allowed
Azure Key Vault is an interesting new service for Azure users that allows you to store keys and/or secrets away from prying eyes. If someone was to break into your server, they would not have access to the keys, although theoretically, they could call into the Key Vault manually to decrypt data.
Some restrictions that are a pain. Secrets, which are pretty much anything you want them to be, are not Hardware Security Module backed so their use is only slightly better than using something like encrypted web configuration files. An attacker could potentially gain access to the Key Vault in the same way they might access your web servers. Another pain is that although you can create keys invisibly and delegate encryption and decryption to a Hardware Security Module, the service only currently supports RSA keys (i.e. public key encrypt/decrypt), which is incredibly slow relative to symmetrical encryption and not something to use for repeated low-latency operations.
Anyway, I wanted to give it a go and followed the tutorial here: https://azure.microsoft.com/en-gb/documentation/articles/key-vault-get-started/ which is kind of OK, although like a lot of Microsoft Documentation, the important distilled stuff tends to be spread across lots of documents, even for something simple like the Key Vault, where I want to read headline stuff and be able to drill-down into the details if needed.
I set it all up, added a vault, a key and a secret and then tried to access it from .Net code using the NuGet packages. I got the KeyVaultClientException fire and the message "Operation "get" is not allowed", which sounds kind of obvious except that I had definitely given the permission to my app. Of course, with all the Active Directory requirement, there is another whole level of confusion about what might or might not be broken.
The problem? A simple typo in the secret name (passed as URL) left over from an attempt to use a key, which had "keys" in the path instead of "secrets". I only spotted the problem due to a similar problem on CDNs where you tend to get permission denied errors when attempting to access a non-existent object. I guess it makes sense since the vault is on a public URL and you don't necessarily want people fishing for key names but it is still a pain, especially since the principal did have access to the key vault itself.
The other thing I now need to work out is how to avoid it creating a key vault client and obtaining access tokens for every operation. I can obviously cache the values but how will I know when I need to re-authenticate i.e. when the token expires etc? Just more hassle I suppose.
Some restrictions that are a pain. Secrets, which are pretty much anything you want them to be, are not Hardware Security Module backed so their use is only slightly better than using something like encrypted web configuration files. An attacker could potentially gain access to the Key Vault in the same way they might access your web servers. Another pain is that although you can create keys invisibly and delegate encryption and decryption to a Hardware Security Module, the service only currently supports RSA keys (i.e. public key encrypt/decrypt), which is incredibly slow relative to symmetrical encryption and not something to use for repeated low-latency operations.
Anyway, I wanted to give it a go and followed the tutorial here: https://azure.microsoft.com/en-gb/documentation/articles/key-vault-get-started/ which is kind of OK, although like a lot of Microsoft Documentation, the important distilled stuff tends to be spread across lots of documents, even for something simple like the Key Vault, where I want to read headline stuff and be able to drill-down into the details if needed.
I set it all up, added a vault, a key and a secret and then tried to access it from .Net code using the NuGet packages. I got the KeyVaultClientException fire and the message "Operation "get" is not allowed", which sounds kind of obvious except that I had definitely given the permission to my app. Of course, with all the Active Directory requirement, there is another whole level of confusion about what might or might not be broken.
The problem? A simple typo in the secret name (passed as URL) left over from an attempt to use a key, which had "keys" in the path instead of "secrets". I only spotted the problem due to a similar problem on CDNs where you tend to get permission denied errors when attempting to access a non-existent object. I guess it makes sense since the vault is on a public URL and you don't necessarily want people fishing for key names but it is still a pain, especially since the principal did have access to the key vault itself.
The other thing I now need to work out is how to avoid it creating a key vault client and obtaining access tokens for every operation. I can obviously cache the values but how will I know when I need to re-authenticate i.e. when the token expires etc? Just more hassle I suppose.