[General workload issue]:

[vivsri]

Check for previous/existing GitHub issues

• I have checked for previous/existing GitHub issues

Issue Type?

Feature Request

Description

Hi Bruno,
Just a quick question around the VM initiative, as it's presently located only at the landing zone scope.
I tested it out by duplicating the assignment to the management sub & it works like a charm.
On the other hand if i try the same trick to other subscription, the remediation fails as it complains the System Assigned ID has no permission over the managed identity, which lives in the management sub, which is not a problem if the vm belongs in a management sub, so i created another MI in the other sub where my vm lives now & the remediation works.
Is this something okay to do, as I'm not sure about the policy definitions & logic, & can we pls have the initiative available at all possible levels including identity where im running an entra connect vm.

[Brunoga-MS]

Hello @vivsri ,
thanks for your feedback. What you describe looks good to be done. We already have a similar ask (see #399 ) and we are working on it. My question is: other than Management MG do you see any other MG which would benefits from VM alerts assignment?

Thanks,
Bruno.

[vivsri]

Hi @Brunoga-MS
Thanks for the reply.
As I was referring to the Identity Sub or the MG above it, where I have an Entra Connect VM running.
So if i understand it right, we need a Managed Identity locally in the Sub for the alert rules to be created & it won't work at the Landing Zone MG level too as we are using the Identity which exists only in the Management Sub.

[Brunoga-MS]

You could also have a MI created in the management subscription but with permission assigned at the pseudoRootMG level like the deployment of AMBA does when not using your own MI. Hence, if using your own MI, no need to create more than one; just assign the necessary permission to the pseudoRootMG.

Thanks,
Bruno.

[vivsri]

Thanks, exactly my point, when i run AMBA, i get a MI created by default in the MG Sub, with permissions as monitoring Reader at the pseudo Root or the IR(Intermediate Root), but the remediation fails for any VMs, that are not in the MG Sub. In order to make the remediation work i need to supply and MI residing in the sub locally.

[Brunoga-MS]

It shouldn't fail. We need to investigate more on this. I will get back to you as soon as possible

[vivsri]

Many thanks, that was my reason to ask why do I need to create an additional MI

[vivsri]

Hi @Brunoga-MS,
I did some further investigation & post that on comparing with Monstar, the fix for the remediation is to use the UAMI, instead of System Assigned Identity, so while we move the VM initiative, if we can update the policy definition, the remediation would work for VMs located at any scope from the same UAMI, created in MGMT Sub, as the permissions would get assigned in the remediation section to the scope where it is needed. You can compare the one at the Landing Zone

[Brunoga-MS]

Hi @vivsri,
you are correct. I was investigating as well and found the same. You need to use the existing UAMI (either the one created by AMBA-ALZ during the first deployment or your own). In particular the one created by AMBA-ALZ has permission assigned to the pseudoRootManagementGroup. I did the test by modifying template to ensure I was using the same approach and landed to the same conclusion (as expected).

Hope that helps,
Bruno.

[vivsri]

But we still need to modify the policy definition to use UAMI, as currently it is using SAMI. The one created by AMBA has just monitoring reader permissions, which is not sufficient to make it work for remediation.

[Brunoga-MS]

It is since the remediation is done through the SAMI used during the assignment which has all the necessary permission. This is the reason why I tested the assignment through the template. If you cloned the repo, I can share the part of the code to add to the alzArm.json, so you just have to commit and push and then deploy again using your repo. Let me know if you would give it a try.

[vivsri]

I think I'm saying the same thing about the SAMI & was hoping if it can be fixed in the next release or so, after that we can use it as generally available. Also I haven't cloned the repo we are using it directly just keeping the params locally, so i can give it a try using a different tag or feature branch if that makes sense.

[Brunoga-MS]

Yes, we have it in our plan. You can try pointing the deployment to use my private template version at https://raw.githubusercontent.com/Brunoga-MS/azure-monitor-baseline-alerts/refs/heads/Assign_VM_To_Identity/patterns/alz/alzArm.json with your param file. As far as the remediation goes, you then have to run the following to remediate both Identity and Connectivity for VM alerts:

.\patterns\alz\scripts\Start-AMBARemediation.ps1 -managementGroupName $identityManagementGroup -policyName Alerting-VM
.\patterns\alz\scripts\Start-AMBARemediation.ps1 -managementGroupName $connectivityManagementGroup -policyName Alerting-VM

Let me know how it goes.

[vivsri]

Thanks I'll give it a try & confirm...

[vivsri]

So the pipeline worked well, using the template version provided by you, it did deploy the initiative at the connectivity scope. Bu the remediation section still has a SAMI instead of using the existing UAMI

[Brunoga-MS]

Should not be a problem since the initiative should have been updated by the template. Try to remediate and let me know

[vivsri]

Can i try to run the remediation via the portal directly, actually the remediation worked via the portal, can you pls help me understand the workflow, how it worked with the SAMI

[Brunoga-MS]

I would recommend to use the script. Read more at Remediate Policies

[vivsri]

Thanks I'll do so, let's conclude the topic here, hope it will be generally available now to be applied at different scopes.

[Brunoga-MS]

It should be soon :-).

Given your last comment I am going to close this one as resolved. Feel free to reopen it or to create a new one, should it be the case.

Thanks again,
Bruno.