Repository: hashicorp/terraform-provider-azurerm

Issue #6069: Error building account after upgrading to 1.38 and above
Created: 2020-03-11T15:33:54Z
Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment


Terraform (and AzureRM Provider) Version
Terraform v0.12.21

provider.azurerm v1.34.0
provider.external v1.2.0
provider.kubernetes v1.11.1
provider.random v2.2.1


azurerm_1.38.0 up to azurerm_2.0.0 are affected

Affected Resource(s)
it happens while bootstrapping azurerm, so no specific resource
Terraform Configuration Files
provider "azurerm" {
  version         = "1.38.0"
  skip_provider_registration  = "true"
}
Debug Output
Error: Error building account: Error getting authenticated object ID: Error listing Service Principals: autorest.Detail
edError{Original:(*azure.RequestError)(0xc000809710), PackageType:"graphrbac.ServicePrincipalsClient", Method:"List", S
tatusCode:400, Message:"Failure responding to request", ServiceError:[]uint8(nil), Response:(*http.Response)(0xc0008096
80)}

Actual Behavior
As it seems to use the new graph api, it should not use the list and odata filter to look for the service principal, it should use the specific resource query so it doesn't need additional permissions in the service principal to access it.
This is the line where it creates the filter
https://github.com/hashicorp/go-azure-helpers/blob/6e061044db42917eeaecea091acb19e5d917122e/authentication/azure_sp_objectid.go#L36
for the appId base on the API call
https://docs.microsoft.com/en-us/graph/api/serviceprincipal-list
Expected Behavior
it should use this API call
https://docs.microsoft.com/en-us/graph/api/serviceprincipal-get
because it probably requires less permissions.
I based that assumption on that az ad sp show --id http://SP-Name is working when I log in as the service principal but az ad sp list does not.
Steps to Reproduce
You just need to plan with the permissions of a Service Principal with Contributor role.
Important Factoids
The issue seems to exist in the go-azure-helpers and I also created an issue there. (see recerences)
References
hashicorp/go-azure-helpers#49

#0000

Duplicate issue #6928: SyntaxWarning: "is" with a literal. Did you mean "=="?
Created: 2020-05-14T14:35:25Z
Error: Error building account: Error getting authenticated object ID: Error parsing json result from the Azure CLI: Error retrieving running Azure CLI: /usr/lib64/az/lib/python3.6/site-packages/jmespath/visitor.py:32: SyntaxWarning: "is" with a literal. Did you mean "=="?
if x is 0 or x is 1:
/usr/lib64/az/lib/python3.6/site-packages/jmespath/visitor.py:32: SyntaxWarning: "is" with a literal. Did you mean "=="?
if x is 0 or x is 1:
/usr/lib64/az/lib/python3.6/site-packages/jmespath/visitor.py:34: SyntaxWarning: "is" with a literal. Did you mean "=="?
elif y is 0 or y is 1:
/usr/lib64/az/lib/python3.6/site-packages/jmespath/visitor.py:34: SyntaxWarning: "is" with a literal. Did you mean "=="?
elif y is 0 or y is 1:
/usr/lib64/az/lib/python3.6/site-packages/jmespath/visitor.py:260: SyntaxWarning: "is" with a literal. Did you mean "=="?
if original_result is 0:
on main.tf line 24, in provider "azurerm":
24: provider "azurerm" {
cat /etc/redhat-release
Fedora release 32 (Thirty Two)
terraform_0.12.25_linux_amd64
az --version
azure-cli                          2.5.1
command-modules-nspkg              2.0.3
core                               2.5.1
nspkg                              3.0.4
telemetry                          1.0.4
Python location '/usr/bin/python3'
Extensions directory '/home/pskora/.azure/cliextensions'
Python (Linux) 3.8.2 (default, Feb 28 2020, 00:00:00)
[GCC 10.0.1 20200216 (Red Hat 10.0.1-0.8)]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.

Closing comment (2020-05-14T15:14:53Z): hi @piotsk
Thanks for opening this issue :)
Taking a look through this appears to be a duplicate of #6069 - rather than having multiple issues open tracking the same thing I'm going to close this issue in favour of that one; would you mind subscribing to #6069 for updates?
Thanks!