One of the differences that in most case we use SSH keys to access a VM running in Azure. And Azure has a couple ways of securely storing that information. When creating a VM you can generate one at deployment, upload your own, or use an existing one already in azure.
When using “Use existing one stored in Azure” it refers to a separate repo in azure different than Azure Key Vault. It actually saves the key in a portal service SSK Keys.
The SSH Keys portal service give you the ability to download the public key so you can connect to the appropriate VMs.
In one of the production environment that I’m currently involved with. We do not allow public IP assigned to VMs without a proper business case. I actually agree with this policy since it limits the number of attack vectors. So, we use Azure Bastion. Connecting using Azure Bastion offers the possibility to use one of several ways to authenticate to the VMs.
SSH Private Key
SSH Private Key from Local File
SSH Private Key from Azure Key Vault
Using Azure Key Vault to securely store your keys and secrets allows you to manage the SSH keys by setting expiration dates, apply proper versioning, assign tags AND have them available to the Azure Bastion with the option of requesting the Passphrase.
Just like my previous article. In order to manage these keys, you can schedule an Azure Automation task, or an Azure Function to monitor the expiration dates and renew\regenerate the SSH Keys for you when appropriate. As a proof-of-concept I used the same Azure Automation Account as my last article with a new runbook to create the SSH keys for my environment and store them in Azure Key Vault