keyvault | Uses keyvault to sign client creds token request to AAD | Identity Management library

What am I missing here?

There are a few issues here:

1. You're trying to assign an RBAC role to an App Registration. What you need to do is assign an RBAC role to the Service Principal. To get the Service Principal Id, you would need to go to Enterprise Applications section in Azure AD and find the Id of your Service Principal (Object ID).

2. Assigning Reader RBAC role will not do the trick as this role is for managing the Key Vault itself and not the data inside it. There are two ways to solve this:

• Use Access Policies: You can define appropriate access policies in your Azure Key Vault to give access to keys, secrets and certificates to your Service Principal.
• Use Data RBAC Roles: Instead of using Management RBAC roles (like Reader, Contributor etc.), you will need to use RBAC roles for managing data inside the Key Vault.

Please see this link for more details: https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy-portal.

You could directly query the accessPolicies properties from the Azure CLI command.

I believe it is a 2 step process:

1. You will need to import the certificate stored into your Azure Key Vault into your App Service. You can use Import-AzWebAppKeyVaultCertificate Cmdlet to do so.

2. Bind this certificate to your App Service. You can use New-AzWebAppSSLBinding by specifying the certificate thumbprint for that purpose.

Please change the following lines of code:

No. User managed identity is also not supported with ManagedIdentityCredential in the local environment.

You should use DefaultAzureCredential for the code to work in local environment.

See the Note tip here.

Note

The ManagedIdentityCredential works only in Azure environments of services that support managed identity authentication. It doesn't work in the local environment. Use DefaultAzureCredential for the code to work in both local and Azure environments as it will fall back to a few authentication options including managed identity.

In case you want to use a user-asigned managed identity with the DefaultAzureCredential when deployed to Azure, specify the clientId.

It is because Powershell saves the output of get-default-policy in a different encoding from that of bash and CMD.

Please use this workaround:

Try to use ClientSecretCredential to do this :

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 binded to the VM. Think of Keyvault as a very secure excel sheet. That excel sheet is not binded 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...

Update:
You should declare a variable first by click blank, then you can select a variable at step3:

After you added ADF managed identity permissions to Get and List secrets.

1. Add a secret to the key valut. Here my secret name is mysecret.
   

2. So your URL should looks like https://your-keyvault-name.vault.azure.net/secrets/mysecret?api-version=7.0
   

3. Add dynamic content @activity('Web1').output.value to your Set variable1 activity.