Use vscode authentication instead of Azure Account extension #15403
Conversation
StephenWeatherford
changed the title
StephenWeatherford
force-pushed
the
sw/241004-new-auth-provider
branch
from
4db6390
to
bbc3da2
Compare
|
While this change is done is it possible to verify in advance that container registry access via Lighthouse permissions work with the new authentication mechanism. Basically fixing this #8714 |
StephenWeatherford
force-pushed
the
sw/241004-new-auth-provider
branch
from
8af39a4
to
8e7d44b
Compare
StephenWeatherford
changed the title
StephenWeatherford
force-pushed
the
sw/241004-new-auth-provider
branch
from
8e7d44b
to
c87ea3e
Compare
|
Test this change out locally with the following install scripts (Action run 11848453163) VSCode
Azure CLI
|
Dotnet Test Results 78 files - 39 78 suites - 39 29m 24s ⏱️ - 14m 2s Results for commit 7091480. ± Comparison against base commit 4b190e2. This pull request removes 1841 and adds 630 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
| @@ -9,9 +9,16 @@ public class CredentialFromTokenAndTimeStamp : TokenCredential | |||
| { | |||
There was a problem hiding this comment.
See Conversation tab for the UI changes. NOTE: I've tested all deployment scopes with both the Deploy Bicep File... menu and also the deployment pane. I've also tested on ChinaCloud, but deployment pane doesn't currently succeed with sovereign clouds (#14834), not with my changes here. The wrong credentials are somehow getting used.
StephenWeatherford
changed the title
@slavizh in case you're interested in testing yourself, you can use the scripts in the above comment to preview the changes:
|
|
@anthony-c-martin I have tried the build but still getting error although I think it is not caused by the build as I get the same error with the latest stable release as well. Error is pasted below. As far as I understand the error it cannot find any credentials (in my case from VisualStudioCode type) to authenticate. And this is the strange thing because I have authenticated multiple times, change directories (tenants), selected subscriptions and still getting the same error. If I have the time I will try to see if I first can successfully authenticate via VisualStudioCode by just having Azure RBAC access and than after I succeed I will try with using Lighthouse. I for sure remember that previously access via RBAC was working fine and even when I have chosen to use Lighthouse it was throwing some other authentication error not the credentials not found. A side thing from this I have found this message: "It's a known issue that VisualStudioCodeCredential doesn't work with Azure Account extension versions newer than 0.9.11. A long-term fix to this problem is in progress. In the meantime, consider authenticating with AzureCliCredential." |
|
@slavizh @anthony-c-martin @shenglol Yes, unfortunately this change will not affect #8714 at all, it only affects bicep file deployment in vscode, and not module restore, since module restore also has to work from commandline, outside of vscode.
Correct, that's what I was trying to explain here:
Presumably vscode's recent authentication API is part of that long-term fix, although I don't have any inside knowledge of that. So until this is fixed, @anthony-c-martin @shenglol it seems like we should at least put a warning in bicepconfig.json if it's used? @slavizh You were able to determine that vscode supports Lighthouse, right (i.e.,. that it works in the Azure Resources extension)? |
StephenWeatherford
changed the title
|
@StephenWeatherford yes. Basically Lighthouse works by projecting subscriptions/resources into your tenant. Because I have a user that is from tenant1 and it is also guest on tenant2. The subscriptions are in tenant2 so I have access to the subscriptions if I see them as logged to tenant2 and as logged to tenant1 (via Lighthouse). In the azure resources extensions I was able to see the same subscriptions twice. Thus my assumption that it works because I see the subscription once as I am getting access via tenant2 and second time via Lighthouse with tenant1. I hope that explains it if you are not completely familiar with Lighthouse. One thing that is not clear from the documentation is what are the requirements for the Visual Studio code option and the steps to logon properly. My assumption is that it uses Azure Account extension and based on where you are logged there it takes those credentials. If that is the case might be good to add requirements and small how to guide or link to Azure extension if it has documentation on logging. I will still try to test if VSC option works via normal Azure RBAC as the mentioned version of Azure Account extension is 3 years old and I remember the VSC option working at least for RBAC at most one year ago. |
|
I have tested just by using Azure RBAC but couldn't make it work. Getting the same error always. I even tried installing 0.9.10 version of Azure Account extension and still it is the same. I even tried enabling MSAL settings in VSC
and still the same error. Now I wonder if this was ever working or I am doing something completely wrong. My main steps are:
Sign out was performed when I changed some setting to make sure all was from clear start. As soon as I use CLI or PS options it works. |
|
@alexweininger @slavizh @shenglol I tried with Azure Account 0.9.10 and got the same result - I logged in using "Azure: Sign In" and could see subscriptions listed via "Azure: Select Subscriptions", but still bicep fails on module restore with CredentialUnavailableException, suggesting I need to log in. I also note that if I reload the window and try "Azure: Selection Subscriptions" again, no subscriptions show, indicating the Azure Account extension is not able to store its credentials properly. I.e., it appears VisualStudioCodeCredential no longer works at all with newer versions of vscode, even if using old versions of Azure Account Extension. Sorry for the inconveience. We'll discuss changing our docs at the very least until VisualStudioCodeCredential is fixed. TL;DR I believe this is what is happening... The old Azure Account extension used to use keytar to store credentials. I believe that info to be sharable with other extensions, it had to use the keytar installed with vscode, so it dynamically loaded it from vscode's node_modules\keytar folder (see https://github.com/microsoft/vscode-azure-account/blob/c465c17c86c9ffeb1543a3e5372993eb0a56de0e/src/utils/keytar.ts). In 0.9.12, they removed this code, but VisualStudioCodeCredential was looking for the credentials from vscode using keytar, so it worked with versions <= 0.9.11. Sometime later, vscode stopped shipping with keytar (probably when adding the authentication API), so now 0.9.11 can no longer store its credentials and VisualStudioCodeCredential can no longer find it. |
StephenWeatherford
force-pushed
the
sw/241004-new-auth-provider
branch
from
8984a80
to
60c8cd0
Compare
|
What Stephen explained is accurate to my knowledge (from the Azure Account side of things) |
|
I am glad that we now have clear indication about the root cause of the issue. |
StephenWeatherford
force-pushed
the
sw/241004-new-auth-provider
branch
from
b34feaf
to
24d1b9b
Compare
Fixes 14101
NOTE: I plan on not merging this until the current release ships, so we have some time to dogfood internally before the December release.
Fixes #14101
Microsoft Reviewers: Open in CodeFlow
Overview of UI changes (images from https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deploy-vscode)
NEW: You never see this menu now. Instead, if you aren't logged in, you'll see something like this:
NEW: Bicep no longer uses the Azure Account extension (it's being deprecated). Instead, it uses new built-in vscode functionality that is integrated with vscode's UI, e.g.:
and also integrates with other extensions like the Azure Resources extension.
The statement that deployment doesn't use values from the bicepconfig.json is correct. Instead, if you need to sign in to a custom cloud, use this vscode setting before signing in:
Note: multiple signed-in accounts isn't currently supported (you may need to sign out of one first using the vscode UI above), although hopefully that will be fixed soon, perhaps even before this feature change ships.