Today's post comes via information from Steve Lewis, a Sr. Azure Cloud Engineer (ACE) in CXP. He's delivering support to our top Azure customers.
An interesting aspect of being a Support Engineer (or an Azure Cloud Engineer) is that we learn how to read error messages better than anyone. Customers have grown to ignore error messages as they so often are not useful. However, this post shows a really good error message from Azure that you should know about.
In case you're not familiar with it, CloudShell is an awesome part of the Azure portal that allows you to execute PowerShell cmdlets (as well as Bash) in the browser. Pressing on the ">_" button in the top of the screen gets you to the CloudShell environment:
We had a customer that recently opened up a critical situation support case regarding Azure Key Vault and CloudShell. He'd used CloudShell to create the vault and then immediately went to create the secret inside of it, but was denied access to do so.
An interesting note about Key Vault in the Azure Portal: the creator of a Key Vault is automatically granted an Access Policy. In fact, you can see it in the blade before you create it:
Even more: when a Key Vault is created using Powershell on the desktop, an Access Policy is created as well:
However, we have a different experience when running the same in CloudShell:
You can clearly see that there are no access policies set for this Key Vault upon creation. Not only that, it tells us that there are no access policies set and how to set them. That's why when I try to set a secret value inside the key vault, it does not work:
This is one of those cases where if the customer had carefully read the output, they would have understood that they need to set an access policy. It's been known that there are sometimes really arcane and useless error messages that come from Microsoft resources, but this is not one of those times. However, before doing that, let's look at the principal we are working under:
It's highly unlikely that you would want to set an access policy for this user, but would rather do it for your own security principal. Let's log in properly:
Now we can can work properly with this. Let's change to the right subscription, set the access policy (using your account name), and check the vault again:
Now it has an access policy:
And we can finally set the secret:
Again, thanks to Steve Lewis for figuring this out and sharing with me for this blog.
I hope this helps you out when using the Azure Key Vault! Please follow us on Twitter and tweet about it!