Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question]: @AzureFileCopy6 cannot find the storage account with WIF service connection if the UMI is in different subscription #20690

Open
1 of 4 tasks
hancheng-ms opened this issue Nov 26, 2024 · 10 comments

Comments

@hancheng-ms
Copy link

Task name

AzureFileCopy

Task version

6.248.3

Environment type (Please select at least one enviroment where you face this issue)

  • Self-Hosted
  • Microsoft Hosted
  • VMSS Pool
  • Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

MMS windows 2022

Question

My pipeline to upload file to blob storage hit this error: ##[error]Storage account: csdngpstorage not found. The selected service connection 'Service Principal' supports storage accounts of Azure Resource Manager type only.

I think the UMI has all necessary permissions (reader, container blob contributor and so on) to access this subscription. The task tried to set Set-AzContext against a different subscription where the storage account was not created in. This reminded me to an issue I hit before in my custom az script. Because we manually created the WIF service connection and use this single UMI to access all azure subscriptions in MS tenant, we just need to add the umi to be "reader" of these subs and it worked well for most devops pipelines. Except I need to add one line to select the right subscription context to the azCLI script to make it pick right subscription need to work on.

Does AzureFileCopy support this scenario? How can I pick the subscription in the AzureFileCopy? Do we need a feature change to this pipeline task?
@v-schhabra
Copy link
Contributor

Hi @hancheng-ms
Thanks for reporting this issue.
Could you pls share the complete pipeline logs by adding the variable "system.debug" to true?

@v-schhabra v-schhabra added the Area:RM RM task team label Nov 26, 2024
@hancheng-ms
Copy link
Author

Upload the log in this file, AzureFileCopy6.log, also if you are MS employee you can use this link https://microsoft.visualstudio.com/OSGCXE/_build/results?buildId=111440037&view=logs&j=d9011fe4-49d8-516e-6af1-e5afc7ba01d4&t=be5330e2-f88e-5b94-f22f-9affc1ee0a93

@v-schhabra
Copy link
Contributor

Hi @hancheng-ms
In the latest release we observed that the task is getting succeeded without any errors. Could you please let us know if the error is sporadic or not?
And did you made any changes in the task post that it started to succeed.

@hancheng-ms
Copy link
Author

hancheng-ms commented Dec 2, 2024

@v-schhabra I just used another non FIC service connection to unblock my deployment, you need check the previous running history in 20241126.1 I shared above

@v-schhabra
Copy link
Contributor

Thanks for responding. Will check this issue and keep you posted on the updates.

@v-vinaykoora
Copy link

@hancheng-ms We tried to repo the issue, but we didn't see any errors. Based on the error message which you have shared above.

We suspect you were not using ARM service connection or the storage account which you were using is classic storage account and not an ARM type.

Can you please verify and clarify on the above 2 queries

My pipeline to upload file to blob storage hit this error: ##[error]Storage account: csdngpstorage not found. The selected service connection 'Service Principal' supports storage accounts of Azure Resource Manager type only.

@hancheng-ms
Copy link
Author

hancheng-ms commented Dec 30, 2024

We use the arm service connection (workload identity federation with openid connect), and could you share the way to check if a storage account is classic or arm type? But I think the storage is the ARM type, I checked some document and the names of traditional storage account has the suffix '(classic)'.

@hancheng-ms
Copy link
Author

I can confirm now that all of our blob storages are v2 so they are ARM type. I also checked our azure custom role we assigned to the UMI in the blob storage, it has the same config as our role in PME. The pipeline runs well against PME tenant.

I can repo this issue in another pipeline https://microsoft.visualstudio.com/OSGCXE/_build/results?buildId=111391237&view=logs&j=d9011fe4-49d8-516e-6af1-e5afc7ba01d4&t=be5330e2-f88e-5b94-f22f-9affc1ee0a93. Did you place the UMI in another subscription when you tried to repro the error?

@v-vinaykoora
Copy link

@hancheng-ms Thanks for the information. Yes, for the classic storage accounts we will be having the suffix as classic beside them. Can you please also let us know what kind of role you assigned to UMI for the blob storage.

We have tried from our end where both the storage account and UMI are in same subscriptions. Can you please let us know are you using storage account in one subscription and UMI in another subscription and also please check whether this storage account "csdngpstorage" exists in azure portal.

@hancheng-ms
Copy link
Author

we assigned our custom role to the blob storage, I can share the role's config with you in Teams.

and No, our UMI and storage accounts are NOT in the same subscription, I guess this causes this error in our pipeline.

csdngpstorage exist, it is our one of our dev storage used for years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants