azure-dev
azure-dev copied to clipboard
`azd pipeline config` - Insufficient privileges to complete the operation
Describe the issue:
azd pipeline config test fail.
The failure error is as follows:

Repro steps:
1.Run command azd up
2.Run command azd pipeline config
Environment:
-
OS : Linux desktop Template: todo-nodejs-mongo, todo-csharp-cosmos-sql , todo-nodejs-mongo-swa-func, todo-python-mongo, todo-python-mongo-swa-func
-
OS : CodeSpace Template: todo-csharp-cosmos-sql, todo-nodejs-mongo, todo-nodejs-mongo-aca, todo-nodejs-mongo-swa-func, todo-python-mongo, todo-python-mongo-aca, todo-python-mongo-swa-func
Expected behavior:
In Linux environment, when Azure CLI version is 2.38.0, azd pipeline config test can success.
@rajeshkamal5050, @jongio for notification.
@vhvb1989 when you get a chance. can you take a look at this?
Trying to reproduce.
Looking at the issue, it looks like az is trying to do log in and fails. But I see the comment about using 2.36 works.
@v-jiaodi can you run az login before running azd pipeline config and see if that works?
I will come back later with more findings on my side
Also, can you confirm your OS?
I saw you mentioned OS : Linux desktop. Is it WSL ? or is it a VM? Docker?
what distro? Ubuntu/Debian ???
Please share more details about it
as a workaround, please run az login --scope https://graph.microsoft.com//.default before running azd pipeline config
I will see how to integrate this to azd
@vhvb1989 , I run azd pipeline config after running az login, but it still doesn't work.
OS: Linux VM
distribution: Ubuntu 20.04
Besides,I try to run az login --scope https://graph.microsoft.com//.default before running azd pipeline config, I get an error as follow:

In other environments and templates,we have found the same issue recently . we have updated the issue description.
Marking it as a blocker since it seems to have happened in other environments and templates recently.
@vhvb1989 can you take a look and update?
I am able to reproduce it by logging az with az login --use-device-code
This seems to be an issue/limitation of logging az cli in using a device-code on Linux.
The workaround is to use az login alone and use a web browser to do the logging in
Removing blocker based on above update. Let us try to document it as a limitation based on
- https://github.com/Azure/azure-cli/issues/17273
@vhvb1989 can you work with @puicchan to get it documented.
See issue: https://github.com/Azure/azure-cli/issues/17273
It is expected to fail auth on Linux.
As a workaround, people can log in with a service principal before running az pipeline config (just need to make sure to use the required scope to the service principal to be able to create and assign another service principal)
Also related issues and workarounds https://github.com/Azure/azure-cli/issues/16401 https://github.com/Azure/azure-cli/issues/19652 https://stackoverflow.com/questions/68892711/azure-ad-authentication-error-aadsts50005-on-linux
See issue: Azure/azure-cli#17273
It is expected to fail auth on Linux.
As a workaround, people can log in with a service principal before running
az pipeline config(just need to make sure to use the required scope to the service principal to be able to create and assign another service principal)
@vhvb1989 We tried to log in with service principal before running az pipeline config in codespace environment, but it still prompted an insufficient permissions error.
Login Command: az login --service-principal -u <app-id> -p <password-or-cert> --tenant <tenant>
Error Message:

Our service principal api permissions just owned User.Read permission now, what permissions do we need for this step?

You need the system access administrator
See and try this: https://github.com/Azure/azure-dev/issues/134#issuecomment-1208592571
@vhvb1989 - Thanks for your reply, but the issue https://github.com/Azure/azure-dev/issues/134#issuecomment-1208592571 is not related to the problem we are having. Our current problem is that after logging in with the service principal, we do not have permission to create or update service principal (When execute command: azd pipeline config).
The specific error message is:
Error: failed to create or update service principal: failed running az ad sp create-for-rbac: exit code: 1, stdout: , stderr: ERROR: Insufficient privileges to complete the operation.
: exit status 1
Besides, according to the comments of the issue: https://github.com/Azure/azure-cli/issues/12939#issuecomment-612286761, we also tried to add Directory.Read.All permission in the service principal we used to log in, but couldn't click the Grant admin consent for in API permissions.

but couldn't click the Grant admin consent for in API permissions.
That won't be possible for Microsoft tenant. Microsoft does not allow admin consent for testing purposes.
If you want to have a SP with admin consent, you can use a different tenant (you can set up your own Azure subscription and tenant from https://my.visualstudio.com/ ).
But, coming back to the original question and flow (not using a SP to login), can you mention what Azure subscription are you using? (the name of the subscription)
You must be part of that Subscription and to have the Contributor role access so you are allowed to create the SP when running azd pipeline config
This is because the SP that azd creates is scoped to the entire subscription (the one you set while running azd init or azd up ). So the user running azd pipeline config needs to have the permission for creating the SP with subscription access.
The same thing applies for the SP you created to do the log in.. You actually don't need to add the Read/write permission for MS graph. What you need to do is, after you create it, you need to add it as Contributor for the Azure subscription that you are using, so it becomes entitled to create/update the subscription.
@vhvb1989 - We have added SP as Contributor for the Azure subscription (Azure SDK Developer Playground) that we are using, but it also failed. Taking the Linux Ubuntu 20.04 environment as an example, we have tried the following three login methods:
azd login: As mentioned above, it doesn't work inUbuntu 20.04.az login --use-device-code: In this way, it helped us to pass the login verification, but when we executedaz pipeline configcommand, it failed. This is also the problem at the beginning of this issue. After discussion, we tried a third login method based on this comment of yours.az login --service-principal -u <app-id> -p <password-or-cert> --tenant <tenant>: It also failed in the step of executingaz pipeline config, we actually add our SP as Contributor for this Azure subscription. but it prompts thepermission is insufficient. What are we missing?

We are testing Azure DevOps(new feature) for CI/CD pipelines configuration, it also occurs the same issue with command: azd pipeline config --provider azdo.
@vhvb1989 - After testing, we found that the error message has changed, adding comment to stay up to date:
- When we log in as
az login --use-device-code, the error message changes to:
Error: failed to create or update service principal: failed running az ad sp create-for-rbac: exit code: 1, stdout: , stderr: ERROR: AADSTS53000: Device is not in required device state: compliant. Conditional Access policy requires a compliant device, and the device is not compliant. The user must enroll their device with an approved MDM provider like Intune.
- When we log in with service principal, it still prompts
Insufficient privileges to complete the operation.
In addition, we would like to confirm with you which login method we should use when testing. At present, it seems that none of the methods can successfully create a service principal in step azd pipeline config. How to resolve this issue, any ideas?
@zedy-wj
When we log in as az login --use-device-code, the error message changes to: Error: failed to create or update service principal: failed running az ad sp create-for-rbac: exit code: 1, stdout: , stderr
For the above let's track using #866
When we log in with service principal, it still prompts Insufficient privileges to complete the operation.
Let's track the insufficient privileges using this issue. @vhvb1989 Please try unblocking them. Also, if it is confusing internally, let's make sure to document the same and be clear for external folks.
Thank you @rajeshkamal5050
Both issues are sort of related, as they are both a side effect of the same Conditional Access Policy.
But it is OK to use both issues.
So, for using a service principal , I have checked what is the required permissions to be added to the service principal and they are:
- Application.ReadWrite.All for Microsoft Graph

This access requires admin consent, so it won't be possible to have it within Microsoft tenant. (Microsoft does not provide admin consent for testing applications).
So, this test scenario for using a service principal to log in (az login --service-principal) won't work when using any Azure subscription within Microsoft tenant.
In order to use a service principal, please create a new Azure Subscription outside Microsoft tenant.
Here's a way to do it:
- Go to http://my.visualstudio.com/
- Login with a Microsoft account (it can be @microsoft.com or @outlook.com or @hotmail.com , etc.. any personal or work account is valid)
- Click on
Try Azure for free(for personal account)
or the use credits in Azure to explore (for @microsoft accounts)

- Follow the
activateinstructions to set up a new Azure subscription. - Once the subscription is ready, use the Azure Portal to create a Service Principal. You can use the Azure portal search to find the app registration section
-
Go to API permissions and click Add permissions

-
Select Microsoft Graph

-
Select application permissions

-
Look for
Application.ReadWriteand add it
- Click on
Grant Admin consent for <subscription>. It should be enabled as you are the owner and admin of the tenant, so you can grant the permision
At this point, the service principal is allowed to list/update/create service principals within the subscription.
The next step is to assign the User Access Administrator role to the Service Principal within the subscription so it can assig roles/access within the Azure subscription.
You should already know how to do this step, as it is the result of this: https://github.com/Azure/azure-dev/issues/197#issuecomment-1255779265
Note: You only need to add the User Access Administrator role for azd pipeline config. But you might need the Contributor role for other azd operations
Once you add the roles, you are ready to log in with az login using the Service Principal within the test subscription :)
Let me know if you try this and have any issues.
@vhvb1989 - Thank you for your help! We were blocked when using a private account to sign up for a free trial of azure portal, which requires a visa or master card, we have applied for it, and we expect to start testing next week.
We can use our own personal account to verify the feasibility of the service principal login method in both environments( Codespace, Linux Ubuntu 20.04 ), but this is not a long-term solution. It's not very reliable when it comes to security and professionalism. Considering that we will have automated tests in the future, can you provide a dedicated test account?
Besides, except for the service principal login method, there are other better ways to solve this issue?
@zedy-wj , lets skip azd pipeline validation from the codespaces scenario for now.
And for wsl/dev-container, you have made it work by adding the --scope arg to az login before azd pipeline config right?
So, are we unblock 100% if we just skip the codespaces approach?
(I will propose to return a message like pipeline config operation is not supported when running within codespaces . But for now, we can just skip it
@vhvb1989 -
First, for the wsl/devcontainer environment, we have made it work by adding the --scope arg to az login before azd pipeline config
Second, according to your suggestion, after we use the service principal ( private account ) login method, we run the azd pipeline config command, and in the linux and codespace environments, all passed. But besides the permission Application.ReadWrite.All for Microsoft Graph, we also added:
Directory.Read.Allin api permissionsGlobal administratorin Azure Active Directory Roles for service principal
In addition to the codespace environment, this problem also exists in the linux ubuntu 20.04 environment, whether to skip the execution of azd pipeline config in linux?
When you mention linux ubuntu 20.04, can you elaborate about it?
Is it wsl running Ubuntu and you are you using VSCode to connecto to it?
is it wsl running Ubuntu and you are using a command line directly (no vscode?)?
is it a docker container running Ubuntu?
Is it a Virtual Machine from the cloud, running ubuntu and you are using ssh to connect to it? (with or without vscode?)
Is it a real PC running Ubuntu?
Based on the details, I can tell if we can skip the execution or not.
THank you
It's a Virtual Machine from the cloud, running ubuntu and we are using ssh to connect to it without vscode.
It's a Virtual Machine from the cloud, running ubuntu and we are using ssh to connect to it without vscode.
using shh only won't be enough, unless you use some ssh console that supports port forwarding. For example, using VSCode with either ssh-remote extension or secure-tunnel to stablish the connection to the Virtual Machine will allow you to launch your browser locally to do log in for the az cli and redirect the response to the VM.
But, there's really no need to test all the specific Linux configurations for azd pipeline config. You can choose only one (which ever you find easiest for you to set up), for example, Ubuntu in wsl from VSCode. This is because after the az cli is logged in, azd will behave the same for any Linux distribution, regardless of the way it is running (VM, container, wsl, etc)
@vhvb1989 - Thanks for your suggestion, we will discuss it.
@rajeshkamal5050 - We have tested Ubuntu in wsl from VSCode. Do we need to perform tests in the Linux Desktop environment? Currently in the test plan, both linux and wsl need to be tested.
But, there's really no need to test all the specific Linux configurations for
azd pipeline config. You can choose only one (which ever you find easiest for you to set up), for example, Ubuntu in wsl from VSCode. This is because after theaz cliis logged in, azd will behave the same for any Linux distribution, regardless of the way it is running (VM, container, wsl, etc)
@vhvb1989 - When we used VSCode with ssh-remote extension to stablish the connection to the Virtual Machine, and this issue no longer reproduce( Using az login ). Besides, check again with you if the test for azd pipeline config is skipped in the codespace environment? If skipped, we are unblocking 100% when use the az login method for testing,
If you have no further questions about this issue, we will close it.
yes, skip codespaces for azd pipeline config.
You can choose any Linux set-up to run azd pipeline config. And it's fine to test it just in one set up per template
I get this issue with the latest azd after I login with my @microsoft account:
vscode ➜ /workspaces/fastapi-azure-function-apim (main) $ azd login --use-device-code
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code RTF2ZKQTD to authenticate.
Logged in to Azure.
vscode ➜ /workspaces/fastapi-azure-function-apim (main) $ azd pipeline config
Using pipeline provider: GitHub
? This command requires you to be logged into GitHub. Log in using the GitHub CLI? Yes
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser
! First copy your one-time code: 19E2-0860
Press Enter to open github.com in your browser...
c✓ Authentication complete.
- gh config set -h github.com git_protocol https
✓ Configured git protocol
✓ Logged in as pamelafox
Creating or updating service principal az-dev-01-14-2023-20-34-33.
ERROR: failed to create or update service principal: failed retrieving application list, failed executing request: http call(https://login.microsoftonline.com/organizations/oauth2/v2.0/token)(POST) error: reply status code was 400:
{"error":"invalid_grant","error_description":"AADSTS50005: User tried to log in to a device from a platform (Unknown) that's currently not supported through Conditional Access policy. Supported device platforms are: iOS, Android, Mac, and Windows flavors.\r\nTrace ID: 6cc07526-f00e-48f8-b303-eefd3ad32a00\r\nCorrelation ID: 99ae692b-ff7f-474c-90a1-c1681a42ca49\r\nTimestamp: 2023-01-14 20:34:46Z","error_codes":[50005],"timestamp":"2023-01-14 20:34:46Z","trace_id":"6cc07526-f00e-48f8-b303-eefd3ad32a00","correlation_id":"99ae692b-ff7f-474c-90a1-c1681a42ca49"}
I'm inside a Dev Container in VS Code. VS Code version info:
Version: 1.74.3 (Universal)
Commit: 97dec172d3256f8ca4bfb2143f3f76b503ca0534
Date: 2023-01-09T17:07:18.579Z (5 days ago)
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin arm64 22.2.0
Sandboxed: No
I just tried it in Terminal outside of the devcontainer, which was already logged in, and it did work there:
(.venv) fastapi-azure-function-apim % azd pipeline config
Using pipeline provider: GitHub
Creating or updating service principal az-dev-01-14-2023-20-47-43.
Configuring repository pamelafox/fastapi-azure-function-apim.
Created federated identity credential for GitHub with subject repo:pamelafox/fastapi-azure-function-apim:ref:refs/heads/main
Created federated identity credential for GitHub with subject repo:pamelafox/fastapi-azure-function-apim:pull_request
Setting AZURE_ENV_NAME GitHub repo secret.
Setting AZURE_LOCATION GitHub repo secret.
Setting AZURE_TENANT_ID GitHub repo secret.
Setting AZURE_SUBSCRIPTION_ID GitHub repo secret.
Setting AZURE_CLIENT_ID GitHub repo secret.