Difficulties configuring Azure auth backend using MSI

[Andrew Beresford]

I'm having great difficulty getting the azure auth backend working. Our vault servers have MSI enabled am I'm trying to use that to allow them to talk to Azure, but when I attempt to do a vault write auth/azure/login (with a valid role, jwt, resource_group_name and vm_name), I get an error message back:

Error writing data to auth/azure/login: Error making API request.

URL: PUT https://127.0.0.1:8200/v1/auth/azure/login
Code: 500. Errors:

* unable to retrieve virtual machine metadata: compute.VirtualMachinesClient#Get: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client 'XXX' with object id 'YYY' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/read' over scope '/subscriptions/ZZZ/resourceGroups/CCC/providers/Microsoft.Compute/virtualMachines/DDD'."

(I've edited out sensitive parts of the response).

I'm not at all confident that I have correctly configured the AD App part of the config. I'm assuming with this method (MSI) that I don't need to populate the client_id and client_secret parts of the azure auth config. At the moment, I have created an AD App Registration of the type Webapp/API, but I can't work out how to associate my vault servers with it, or add the appropriate permissions to the app (or work out what the appropriate permissions are!).

[Chris Hoffman]

The AD App is used as the scope for generating the jwt on the client.  It sounds to me that this is working correctly.  

I believe you need to assign the virtual machine hosting Vault (or any container for it, such as Resouce Group) read permissions on virtual machines.  This allows Vault to query metadata on the virtual machine requesting access and validate that the machine requesting access is who it says it is.

Chris

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/a83071cc-7c43-4832-bf60-5e7811195f92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Beresford]

Perfect! It looks like Vault is now able to authenticate and check the token.

The next problem I'm having is that Vault claims that the VM that is attempting to authenticate doesn't exist:

* unable to retrieve virtual machine metadata: compute.VirtualMachinesClient#Get: Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="ResourceNotFound" Message="The Resource 'Microsoft.Compute/virtualMachines/test-vault_3' under resource group 'test-vault-rg' was not found."

I think I might know why - the VM that I'm attempting to authenticate is actually a VM instance in a VirtualMachineScaleSet rather than a VM. Could that have an impact? I think compute.VirtualMachinesClient won't return VM instances of VMSS.

Andrew

[Andrew Beresford]

I've just tested out accessing vault using the azure auth backend from a VM which is *not* part of a VMSS. It works perfectly.

Is support for VMSS VM instances possible?

Andrew

[Chris Hoffman]

Thanks for the info. We are digging into this.

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/662c75af-8a88-40ec-bf99-607a78764418%40googlegroups.com.

[Andrew Beresford]

I've just submitted a PR related to this: https://github.com/hashicorp/vault-plugin-auth-azure/pull/12