Open ChrisTav424 opened 2 years ago
Hi @ChrisTav424,
My organisation are having the same issues, think it could be related to this:
It's trying to acquire the subscription_id from the service connection, to then workout where the remote backend is - as yours is a management group service connection it does not have this.
Could be worth having that as a default value but also have the option to pass the subscription ID to the task
Related issue #26
Hi. I will take a look on how we can solve this.
Thanks @mericstam
Is there a workaround until it's resolved?
Temporary workaround we have used is that we create the DevOps service connection against some subscription but manually give the service principal RBAC-permissions to the wanted management group in Azure also. After that Terraform can make changes based on the permissions inherited from MG level. We just point terraform to make changes in MG level or any other subscription under it.
Hi, there is no quick fix for this, as for now the extension only supports subscription scoped spn.
I will put this issue on our internal board for Product Owner to prioritize.
Please feel free to add the functionality if you want by forking this repo and issue a pull request.
Or follow @JyrkiHei's workaround.
Br Manuel
Having the same problem @mericstam. Has there been any prioritization done on this and are you able to provide an ETA?
Unfortunately there is no ETA for next feature adding release. I belong to Solidify a Microsoft partner and we are maintaining this extension + many more from MS DevLabs. The main goal is to keep them green i.e update security issues, update to later versions of dependencies. and if we have time left add features. MS DevLabs issued extensions do not have the same official status as the ordinary Microsoft publisher ones. At the moment we are prioritizing to move to node version 16. I have many things I would like to get into this extension but at the moment bandwidth is low for terraform extension features
Please use subscription scoped Service Principal RBAC in "Managed Group (auto)" mode for Service Connection to start with, then go to your tenant portal to make a small tweak.
Click on "Azure Active Directory" and then IAMs.
Add the Service Principal to the Subscription IAM's as "Contributor" to test this fix. Select "Users or Groups" after clicking the "+ Add" button, then in the blade on the right, start typing the name of the service principal (should be your organization name) -- It will appear and then you can select it, and click apply, then move to Review, and commit the change.
Retry at this stage, it should work.
I recommend HIGHLY you define a custom role (best practice) instead of Contributor, to scope down permissions, this gets it working. I am able to use Managed Group mode now without this error and modify my storage accounts. You do not need to include subscription_id or reference to any secrets in your terraform (this is the goal!)
⛔ Please do NOT give an app "Contributor" and leave it this way in production. Scope down the SP's role in your subscription accordingly by spending a little time making a custom role that scopes out permissions your terraform needs to use. This recommendation is for testing purposes only.
Hi @loopyd
Where can I find "Managed Group (auto)" mode for Service Connection?
Where can I find "Managed Group (auto)" mode for Service Connection?
I'm guessing they mean this:
We are using the Terraform@V3 task to deploy infrastructure at the management group level (Tenant Root Group). The following is the pipeline yaml.
This is where we are setting the different service connection scopes
How do we get past this error?