This is the 7th part of my Key Vault series - This will also be the shortest one.
When you got control over the server, be it a virtual one or a standalone one, the approach you need to take, depends on what kind of access you have to the server.
If you have full access to the machine, the approach you should take is using a certificate to access it. I wrote about this in Part 4, and also explained how to generate and use it. The reason this is the best approach is that when using a certificate, you can avoid having a secret access key to the Key Vault in your configuration files. When using a certificate, we tell our application to identify as the Service Principal the certificate represent. The Service Principal will have been granted access to the keys in the vault, so your code should only focus on getting the right secrets.
I cant do jack with certificates
When you don't have full access to the server, or at least cant install or access certificates, we are back at the "fallback" way of accessing your Key Vault, which is a ClientId and a Client Secret. Code for how to do this can be found in Part 3.
That is it - I didn't expect this post to be so short, but during writing I noticed that the previous posts covered the topic in full.
Azure Key Vault series index
- Creating and accessing Azure Key Vault
- Get secrets from Azure Key Vault in your app
- Client Id/ApplicationId vs Certificate based access
- Using Key Vault from an Azure Web App
- Using Key Vault with Azure Functions
- Using Key Vault from a Virtual Server (you are reading it)
- Using Key Vault from Azure DevOps (VSTS)
- Using Key Vault in an Umbraco site
- Using Key Vault in an Umbraco Cloud site