Creating Azure VM by using VM admin password from Azure keyvault secret

Question

I am using Azure Portal UI to create a Windows Virtual Machine in Azure. I created a secret adminpassin Azure keyvault that specifies the administrator password for the VM to be created.

When it comes to use that adminpass secret while creating the VM, there are tutorials that describes how to do that if you are creating the VM using an ARM Template: Securely Deploy Azure VM With Local Admin Password from Azure Key Vault and not in ARM Template

But how can i use that keyvault secret if i am creating the VM using Azure portal UI? Is that possible?

And, is there any benefit (other than security) in specifying the password as secret instead of raw text? I mean, If we add the Windows user accounts in a KeyVault, is it possible that we can easily modify or revoke access to VM when needed?

EDIT :

Is KeyVault secret directly binded to a VM ? I mean, If I modify the VM password's secret value in KeyVault, that doesn't automatically change the password of the VM just beacuse it used the secret during deployment time. What would actually happen is, the applications which reads the keyvault to get credentials to authenticate to the VM, will get a wrong crendetials and auth will fail. Right?

Here are 2 deployment scenarios:

• Create a VM via Azure portal UI by specifying the Admin username and password there itself, and after the VM is deployed, just adding the credentials to keyvault secret so that other applications can use them.

• First, add credentials to Keyvault secret, and then deployed VM via ARM templates which uses that secret to read VM Admin credentials.

I just want to make sure that, in both cases, the keyvault secret is intended to be used by other applications that want to authenticate the VM. And, from the perspective of the VM, it reads the keyvault only when the VM is created. Am i correct here?

Answer 1

No it is not possible to create a Windows VM from the portal while specifying a password from KeyVault. Wouldn't surprise me if this feature is released soon as Microsoft is putting a lot of efforts in the security area.

In the context of Secrets for Windows VM passwords, it's generally kept in KeyVault for easier management and security. Say you are deploying using any IaC tool, you do not need to store your password as an environment variable or do not need to store it in Git.

Keeping it in KeyVault allows it to be safely retrieved when needed for creating the VM, and also allows many other resources to access this password for anything else that they might need it for.

Secondly, for easier management of permissions. In KeyVault, you have the same concept of RBAC as any other Azure resource then you have the concept of Access Policies, which is now also available to a certain except under new KeyVault RBAC policies. Having this level of control allows you to decide who can or cannot have access to a VM/Resource's credentials.

Saving the password to KeyVault and removing someone's direct permission to a secret will not revoke access to the VM. It will merely stop that person from accessing the password saved. If that person copied the password from KeyVault, they will still be able to login.

However, if you have an application or resource that will retrieve the secrets programmatically from KeyVault each time it needs to do something, then yes - in this scenario, removing access to the secrets will revoke access to the VM.

Is KeyVault secret directly binded to a VM ? I mean, If I modify the VM password's secret value in KeyVault, that doesn't automatically change the password of the VM just beacuse it used the secret during deployment time. What would actually happen is, the applications which reads the keyvault to get credentials to authenticate to the VM, will get a wrong crendetials and auth will fail. Right?

KeyVault is not bound to the VM. Think of KeyVault as a very secure excel sheet. That excel sheet is not bound to your VM. If you open the excel sheet and delete or change the password, it will not change the VM password. However, anyone else (or application) that relies on that password to authenticate to the VM will no longer be able to do so because the password cannot be found anymore.

Yes, your two deployments scenarios are correct, this is how it will behave - you understood the concept. Again, think of the secure excel sheet that's shared with many people etc...