"Azd pipeline config" failed with cloud shell in Linux desktop

[blow-hey]

Describe the issue: Azd pipeline config failed with cloud shell in Linux desktop, failed to create or update service principal.

The error message as follows:

Repro steps:

1. Log in to the portal and open cloud shell.
2. Clean out auth and other settings using "rm -rf ~/.azd"
3. Set environment variables: export AZD_IN_CLOUDSHELL=1, export NODE_ENV=dev
4. Installation: to install run curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --install-folder ~/azd --symlink-folder ~/bin
5. Run azd command:
   • azd init -t <template>
   • azd up
   • azd pipeline config

Environment: OS: Linux desktop Template: todo-java-mongo and todo-nodejs-mongo-swa-func Azd version: 1.0.1 (commit e0cd1aca716fa5d08704beade7dcc734fe68f5f1)

Expected behavior: Run command azd pipeline config success.

@rajeshkamal5050, @danieljurek for notification.

[rajeshkamal5050]

@danieljurek can you take a look?

cc @vhvb1989

[vhvb1989]

I tried myself and did not see any issue (I tried PS and Bash on cloud-shell):

@blow-hey , just want to confirm, can you mention how are you opening the cloud-shell? I am curious b/c the screenshot from the issue looks like a regular terminal/console from Linux. Did you use the cloud-shell button from Azure Portal ?

Here is how it would typically look cloud-shell running Powershell:

And running bash:

[danieljurek]

I'm also not seeing issues. I suspect your account needs permission to create service principals in the tenant.

Can you run the azd pipeline config command again with --debug

[weikanglim]

@danieljurek Is there something we can do here to surface more error details (may not be on our side) about the 400 error? That error is a dead end for most users.

[blow-hey]

I'm also not seeing issues. I suspect your account needs permission to create service principals in the tenant.

Can you run the azd pipeline config command again with --debug

Result of running command azd pipeline config --debug

[danieljurek]

Thanks! @weikanglim is right, we should show more error information about failed CloudShell auth.

[vhvb1989]

@blow-hey , can you run this from the cloud-shell:

curl -X POST http://localhost:50342/oauth2/token --header "Content-Type: application/x-www-form-urlencoded" --header "Metadata: true" --data-urlencode "resource=https://graph.microsoft.com"

Just let us know if you get an error from that or if it works and gives you a token (no need to paste the token here).

@danieljurek , I think, for some <reasons> the credential is not setting the url for resource=url parameter here:

Those <reasons> seems to be the issue here, as the request becomes invalid. You can reproduced the 400 error code by running:

curl -X POST http://localhost:50342/oauth2/token --header "Content-Type: application/x-www-form-urlencoded" --header "Metadata: true" --data-urlencode "resource=not-valid-url-audience-here"

the result will give the error:

< HTTP/1.1 400 Bad Request
< X-Powered-By: Express
< Content-Type: application/json; charset=utf-8
< Content-Length: 1082
< ETag: W/"43a-wSsXbZuwfaD2PTfCu8bcd4Pxt5U"
< Date: Fri, 16 Jun 2023 21:26:21 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
{"error":{"code":"AudienceNotSupported","message":"Audience not-valid is not a supported MSI token audience. Supported audiences: https://management.core.windows.net/,https://management.azure.com/,https://graph.windows.net/,https://vault.azure.net,https://datalake.azure.net/,https://outlook.office365.com/,https://graph.microsoft.com/,https://batch.core.windows.net/,https://analysis.windows.net/powerbi/api,https://storage.azure.com/,https://rest.media.azure.net,https://api.loganalytics.io,https://ossrdbms-aad.database.windows.net,https://www.yammer.com,https://digitaltwins.azure.net,0b07f429-9f4b-4714-9392-cc5e8e80c8b0,822c8694-ad95-4735-9c55-256f7db2f9b4,https://dev.azuresynapse.net,https://database.windows.net,https://quantum.microsoft.com,https://iothubs.azure.net,2ff814a6-3304-4ab8-85cb-cd0e6f879c1d,https://azuredatabricks.net/,ce34e7e5-485f-4d76-964f-b3d2b16d1e4f,https://azure-devices-provisioning.net,https://managedhsm.azure.net,499b84ac-1321-427f-aa17-267ca6975798,https://api.adu.microsoft.com/,https://* Connection #0 to host localhost left intact
purview.azure.net/,6dae42f8-4368-4678-94ff-3960e28e3630"}}

@weikanglim , azd is using an independent http client to fetch the token. Would that be problematic for your test-recorder? I think we should be using the sdk-core pipeline for making the http request. That would give us the logs and retry for free.

[blow-hey]

@vhvb1989, We try to run the command curl -X POST http://localhost:50342/oauth2/token --header "Content-Type: application/x-www-form-urlencoded" --header "Metadata: true" --data-urlencode " resource=not-valid-url-audience-here", the result prompts Timeout waiting for token from portal, the more detailed information is as follows:

Besides, this prompt box will pop up when run the above command, we click sign in again, then jump page prompts that Enroll Linux device in Intune is required:

According to the documentation provided on the page, follow the steps to configure and sign in Microsoft Intune, then the following prompt appears, Enroll Linux device in Intune failed, the more detailed information is as follows:

[vhvb1989]

It might be possible to install Microsoft Edge on Linux from: https://www.microsoft.com/en-us/edge/download

However, I would rather recommend not running this cloud-shell test case from Linux, as the observed issues are beyond azd-scope.

Also, running cloud-shell from Windows has no difference from running from any other OS, as the shell is running on the cloud. So, we don't need to test cloud-shell on multi-os. @danieljurek , your call. You might want to update the test case

[v-jiaodi]

@rajeshkamal5050 This issue also occurs in the following cases:

Environment:

• OS: Linux Desktop.
• Template: all templates
• Branch: Staging
• Azd version: azd version 1.0.3-beta.1-daily.2905893 (commit https://github.com/Azure/azure-dev/commit/a7126c9e3b8573d3874c47adf0caad927a551d76)

[danieljurek]

Following up on this: We see this behavior so far in machines which are not managed attempting to access APIs that are restricted to only being accessed by managed machines. In these cases, the behavior is expected as the APIs will not be accessible. The fix is to add more error logging to help the user identify the problem more quickly and take steps to resolve it.