Bug report- grant_consent.sh script fails under service principal context

[MarcelHeek]

Is there an existing issue for this?

• I have searched the existing issues

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

Version of the module you are using

5.5.9

Rover Version

aztfmod/rover:1.1.7-2203.2311

Terraform Version

No response

AzureRM Provider Version

No response

Affected Resource(s)/Data Source(s)

azuread_service_principal

Terraform Configuration Files

azuread_applications = {
  sp = {
    useprefix        = true
    application_name = "sp"
  }
}

azuread_service_principals = {
  sp = {
    azuread_application = {
      key = "sp"
    }
  }
}

azuread_api_permissions = {
  sp = {
    microsoft_graph = {
      resource_app_id = "00000003-0000-0000-c000-000000000000"
      resource_access = {
        #Application permission : Application / Application.Read.All
        Application_Read_All = {
          id   = "9a5d68dd-52b0-4cc2-bd40-abcf44ac3a30"
          type = "Role"
        }
        #Application permission : Group / Group.Read.All
        Group_Read_All = {
          id   = "5b567255-7703-4780-807c-7be8301ae99b"
          type = "Role"
        }
        #Application permission : User / User.Read.All
        User_Read_All = {
          id   = "df021288-bdef-4463-88db-98f22de89214"
          type = "Role"
        }
      }
    }
  }
}

Expected Behaviour

Background info : I am deploying a lvl4 workload configuration that uses a service principal (for IaC deployment) with basically only permission of the workload subscription. Temporarily added this workload SP to Global Admin role, so I can use this service principal to create another Service Principal that needs Graph API permissions assigned and consent granted.

I expect the results to be that an App registration is created with API permissions set including Admin Consent granted.

Actual Behaviour

The actual result is that the API permissions are assigned, but consent grant fails because the ${resourceId} is not populated when running under the context of a Service Principal (with Global Admin privilege).

az login --service-principal --allow-no-subscriptions -u ${ARM_CLIENT_ID} -p=${ARM_CLIENT_SECRET} --tenant ${ARM_TENANT_ID}
az ad sp show --id "00000003-0000-0000-c000-000000000000" --query "id" -o tsv gives no output

When I run the last command under "normal" user context I receive output.
So under the context of the SP this is found in the logging (example from 1 API permission)

module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"]: Creating...
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"]: Provisioning with 'local-exec'...
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec):Executing: ["/bin/bash" "/__w/.../.../***/modules/solution/modules/azuread/service_principal/scripts/grant_consent.sh"]
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec):WARNING: The underlying Active Directory Graph API will be replaced by Microsoft Graph API in a future version of Azure CLI. Please carefully review all breaking changes introduced during this migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
**module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec): -resourceId:**
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec): - uri: https://graph.microsoft.com/v1.0/servicePrincipals/79895549-xxxx-4489-9a9b-xxxxxxxxxxxx/appRoleAssignedTo
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec): - body: {
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec):  "principalId": "79895549-xxxx-4489-9a9b-xxxxxxxxxxxx",
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec):  "resourceId": "",
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec):  "appRoleId": "9a5d68dd-52b0-4cc2-bd40-abcf44ac3a30"
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec):}
module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"] (local-exec):ERROR: Bad Request({"error":{"code":"Request_BadRequest","message":"Cannot convert the literal '' to the expected type 'Edm.Guid'.","innerError":{"date":"2022-07-11T11:42:56","request-id":"180396b7-xxxx-49f9-b586-xxxxxxxxxxxx","client-request-id":"180396b7-xxxx-49f9-b586-xxxxxxxxxxx"}}})

╷
│Error: local-exec provisioner error
│
│  with module.solution.module.azuread_service_principals["sp"].null_resource.grant_admin_consent["microsoft_graph-Application_Read_All"],
│  on /__w/.../.../***/modules/solution/modules/azuread/service_principal/grant_api_permissions.tf line 37, in resource "null_resource" "grant_admin_consent":
│  37:   provisioner "local-exec" {
│
│Error running command
│'/__w/.../.../***/modules/solution/modules/azuread/service_principal/scripts/grant_consent.sh':
│exit status 1. Output: WARNING: The underlying Active Directory Graph API
│will be replaced by Microsoft Graph API in a future version of Azure CLI.
│Please carefully review all breaking changes introduced during this
│migration: https://docs.microsoft.com/cli/azure/microsoft-graph-migration
**│ -resourceId:** 
│ - uri: https://graph.microsoft.com/v1.0/servicePrincipals/79895549-xxxx-4489-9a9b-xxxxxxxxxxxx/appRoleAssignedTo
│ - body: {
│  "principalId": "79895549-xxxx-4489-9a9b-xxxxxxxxxxxx",
│  "resourceId": "",
│  "appRoleId": "9a5d68dd-52b0-4cc2-bd40-abcf44ac3a30"
│}
│ERROR: Bad Request({"error":{"code":"Request_BadRequest","message":"Cannot
│convert the literal '' to the expected type
│'Edm.Guid'.","innerError":{"date":"2022-07-11T11:42:56","request-id":"180396b7-xxxx-49f9-b586-xxxxxxxxxxxx","client-request-id":"180396b7-xxxx-49f9-b586-xxxxxxxxxxxx"}}})
│

It appears to me that his became an issue after this commit where the objectId was changed to id. Because before this commit the logic just worked fine under the same circumstances. Possibly due to an update to the AZ CLI I reckon.

Steps to Reproduce

I guess enough info is added already

Important Factoids

No response

References

No response

[wasfree]

This issue seems to be related to azure cli version.

az ad sp show --id "00000003-0000-0000-c000-000000000000" -o tsv

• 2.37.0 it's -> id
• 2.36.0 it's -> objectId

In azure-cli 2.37.0 the underlying Active Directory Graph API was replaced by Microsoft Graph API

[MarcelHeek]

@wasfree I am not so familiar in this material. What should be the next step, or is this something that needs to be fixed in the CAF framework/modules ?

[arnaudlh]

You might want to try with an updated version of rover using the azure cli 2.37 - typically latest rover should help - aztfmod/rover:1.2.3-2207.0210
Let me know.

[wasfree]

@arnaudlh upgrading azure cli version to 2.37.0 has downside hashicorp/terraform-provider-azurerm#7787 seems datasource data.azurerm_client_config is empty until azurerm provider version 3.9.0.

[arnaudlh]

thats correct @wasfree - seems like the refactoring was not smooth in the cli/provider.

It has impact if you are consuming the module as standalone, BUT if you are leveraging the rover commands and contexts, we are fixing that glitch automatically for you with querying and re-injecting the vars (see https://github.com/aztfmod/terraform-azurerm-caf/pull/1185/files)

[MarcelHeek]

Thanks @arnaudlh I will try the version of the Rover you mentioned next week. Will let you know....

[MarcelHeek]

@arnaudlh

bumping the rover version up to aztfmod/rover:1.2.3-2207.0210 fixed the issue. API permissions are added as expected as well as the Grant Consent is given properly.
Thanks for the advice....