Packer: `azure-arm` builder "fails" to find your desired resource group when your service principal credentials are incorrect

[carlosonunez]

Summary

Given an azure-arm builder and a Packer template consumer,
When I run packer build but provide an invalid client_id/client_secret pair,
Then azure-arm tells me that it cannot find the resource group instead of telling me that my credentials are incorrect.

Bug Details

• Packer version from packer version: 1.1.2
• Host platform: Alpine 3.6.2
• Debug log output and template: https://gist.github.com/carlosonunez/3627fed4fba82cd9f97df858672f511d

Actual and expected output are included in the Gist sample above.

Additional Context

This was verified by running Charles and dropping into packet contents. See this Gist for instructions, if needed.

[v6]

// , I have this same issue. Even with a mistaken value for CLIENT_ID_SECRET= I'm not getting a mistaken credentials error, but a useless error about not finding the proper resource group.

The following seems to be an example of this:

https://stackoverflow.com/questions/47871191/packer-azure-arm-cannot-locate-the-managed-image-resource-group

[SwampDragons]

@boumenot does this seem like a packer bug to you or us just passing through a not-useful API error response?

[boumenot]

This is an Azure builder bug.

[v6]

// , There is a long, and ever increasing list of error messages from Azure, of _varying_ helpfulness, that Packer doesn't even parse.

Azure RM API lookup failure errors have the ambiguity of possibly referring to a permissions issue, rather than a missing resource.

But the problems with Packer's error message happen before any successful authentication into Azure in the first place.

Packer's error message adds icing on the ambiguity cake, by implying this:

_authentication_ was successful, but resource lookup was not

In reality, authentication was unsuccessful, and the error had nothing to do with any resources.

[SwampDragons]

Cool, thanks for the context.

[azr]

Howdy @paulmey, do you know of a way to check wether packer is correctly authenticated before going though ? This would be a great UX benefit for packer-azure beginners.
I can probably help ! 🙂

[paulmey]

Hmm, yes, I agree that would be so much better.
For most, including the ClientId/Secret token provider, the actual authentication is done when the ADAL framework detects that the token is either not there or expired. Typically, this will happen the first time a token is used. The 'unauthorized' error is burried in the response error object from that call. I'm not sure that it is easy to peel that out.
I did notice that we do call EnsureFresh for all token types now fairly early in the builder Run(). I wonder if this might just be fixed already now, since I refactored the Azure client setup code earlier this year.

[azr]

Yup, all fixed now !

I remember having a weird 'wrong group' error in a centos azure vm last week which was fixed regenerating credentials & this is why I commented here;
I just double checked now and it turns out the credentials were just old ones and the error was correct.

I tested again and :

• No credentials at all, it failed very early with :

  Build 'azure-arm' errored: adal: Failed to execute the refresh request. Error = 'Get http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fmanagement.azure.com%2F: dial tcp 169.254.169.254:80: i/o timeout'

• Wrong secret, it also failed very early with :

  Build 'azure-arm' errored: adal: Refresh request failed. Status Code = '401'. Response body: {"error":"invalid_client","error_description":"AADSTS7000215: Invalid client secret is provided.

I think this issue can be closed. Thanks !!!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.