Azure Account extension that the Azure Bicep extension depends on for authentication will be deprecated in January 2025

[alexweininger]

Hello 👋,

Azure Account extension that the Azure Bicep extension depends on for authentication will be deprecated in January 2025. Please see microsoft/vscode-azure-account#964 for more details.

Please reach out to me on Teams for questions or support.

[slavizh]

Whoever takes this can you make sure that #8714 is fixed as part of the release?

[stephaniezyen]

@StephenWeatherford can you respond/look at this please?

[StephenWeatherford]

@slavizh This PR will not change anything with the bicepconfig.json VisualStudioCode option, which is used by module restoration. What it does is change our deployment functionality in vscode to remove its dependence on the Azure Account, instead using vscode's new built-in authentication API. I don't know anything about Lighthouse but assume you would need to make sure it's supported by vscode's new auth, and that VisualStudioCodeCredential would also need to be changed to also use the new vscode authentication for things to work correctly for module restoration with VisualStudioCode.

TLDR; Here is my understanding from talking to @alexweininger and @shenglol:

The Azure Account extension is being deprecated so that it no longer stores account sign-in information. Instead, extensions are being changed to use vscode's new built-in authentication API, which integrates with the Accounts menu in lower-left-hand corner of vscode and status bar.

(This bug has a good write-up)

So, neither us nor the Azure Account extension have anything to do with Azure accounts and sign-in anymore, it's all up to vscode, where VisualStudioCodeCredential, which is how our VisualStudioCode credential option is implemented, currently appears to still be tied to the Azure Account extension. My assumption is that going forward, it would need to be changed to also use the vscode authentication API, but I don't have any insight into that process. Likewise, Lighthouse support probably would need to be built into vscode directly. Don't know if it currently works or not. Is it possible to test with the Azure Resources extension? It uses the new vscode auth.

Related bugs that I can find that appear to be related to the solutions around VisualStudioCodeCredential:
microsoft/vscode#178740
Azure/azure-sdk-for-net#30525
Azure/azure-sdk-for-js#30942

I don't understand if/how Lighthouse relates to these.

Hope that helps.

[slavizh]

@StephenWeatherford I think I got more confused now :) . Azure Resources extension works I think. I cannot fully verify it. I can see the subscriptions for which I have access via Lighthouse but I do not see container registries. I think Azure resources just does not supports container registries as visible resource. It shows 7-8 resource types that its support. As #8714 it seems that is cross issue between VSC and Bicep extension I think someone from Bicep team should just work with VSC to resolve it. It is hard for me to reach to the VSC team complaining for issue with extension which I do not understand how it works. I just know that the integration works perfectly if I use Az CLI but it fails when I switch to VSC authentication. Note that Azure Resources extension have the capability to choose a tenant specifically for t hat extension different from the Azure account extension:

I believe azureResourceGroups.login applies to Azure Resources extension and the other is for Azure account extension. The bicep extension does not expose in the error even which tenant and credentials are used for authentication and it does not have option to select which tenant as Azure resources extension.

[StephenWeatherford]

@slavizh I can't blame you!

I believe azureResourceGroups.login applies to Azure Resources extension and the other is for Azure account extension.

Correct, the old Azure Account extension stores different sign-in info than vscode's new auth. The Azure Resources extension and soon Bicep use the vscode sign-ins.

We don't own the code that implements the "VisualStudioCode" option in bicepconfig.json (which is used just for module restoration, and not deployment). When it is eventually fixed, I assume it will also use the same vscode authentication mechanism. (Right now it uses the Azure Account extension's stored credentials, although it doesn't work with newer extension verisions.). So, if Lighthouse is compatible with the Azure Resources extension, I expect eventually VisualStudioCode in bicepconfig.json will also, eventually (not under our control, nor vscode's, although vscode is working with them).

Azure Resources extension works I think. I cannot fully verify it. I can see the subscriptions for which I have access via Lighthouse but I do not see container registries.

I think Azure resources just does not supports container registries as visible resource. It shows 7-8 resource types that its support.

Correct. Don't suppose you have any container apps, they show. But either way, you're saying you are seeing other resources available via Lighthouse, right? If so, it appears vscode's new auth is compatible. And so I expect VisualStudioCode would, too, once it's fixed to use vscode auth.

[StephenWeatherford]

@slavizh and anyone else who's interested: If you have time today, would you mind doing a sanity check of Bicep extension deployment with the new code? Everything seems to be working fine, except that I have seen some problems when signed in to multiple accounts (this wasn’t possible with the previous code, but is now via Azure: Sign In (azureResourceGroups.login) command) and when users have access to multiple tenants. As far as I can tell, the below work-around should be sufficient if you do run into problems...

Instructions:

Installing the pre-release Bicep vscode extension via command line:
Mac/Linux:
bash <(curl -Ls https://aka.ms/bicep/nightly-vsix.sh) --run-id 12148761797
Windows
iex "& { $(irm https://aka.ms/bicep/nightly-vsix.ps1) } -RunId 12148761797"

If you run into the error “No subscriptions found.” In the output window, please let me know, and then try this work-around: Install the “Azure Resources” extension, go to the Azure view, and see if it “Sign in to Directory…”. If so, click it and follow instructions. Bicep deploy should then work.

You can use “Install specific version…” in the extensions view in vscode to go back to the current version.

Thanks!

[slavizh]

@StephenWeatherford I do not use the deployment pane so not much help here.

[StephenWeatherford]

@StephenWeatherford I do not use the deployment pane so not much help here.

No problem, thanks anyway.