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

ManagedIdentityLocation changed from chosen region to global #764

Closed
Haakonak opened this issue Oct 3, 2024 · 5 comments
Closed

ManagedIdentityLocation changed from chosen region to global #764

Haakonak opened this issue Oct 3, 2024 · 5 comments
Assignees
Labels
awaiting response bug Something isn't working

Comments

@Haakonak
Copy link

Haakonak commented Oct 3, 2024

Describe the bug

We are unsure if this really is a bug or a feature, as we don't really understand the cmdlet output, but we are curious if anyone has any information regarding this issue.

We have an existing ALZ deployment with policies in our tenant, and when trying to take ownership of the assignments with EPAC, we get an information message after running the cmdlet:
Build-DeploymentPlans -PacEnvironmentSelector tenant1 -OutputFolder Output
We don't understand the output in the information message shown below:

Replace(identityLocation norwayeast->global,displayName,owner,metadata,parameters,nonComplianceMessages) 'assignmentName' at /managementGroups/identity

We have configured "norwayeast" in global-settings.jsonc for the "managedIdentityLocation"-parameter. We would'nt expect it to show "global" as the new setting being replaced. This issue occurs at multiple assignments, but not all.

We tried changing "norwayeast" in the managedIdentityLocation parameter to "eastus". The policy assignments we already had deployed showed this output:

Replace(identityLocation norwayeast->eastus,addedRoleAssignments,removedRoleAssignments)

And this was similar to what we expected. But in all the new assignments displayed the output message which showed them being changed to global. It does seem like the correct values are being set, but it displays the global value, which is confusing.

Does this "Replace" information mean that the managed identity location is being changed from norwayeast to global, or is the value being set to "norwayeast".

To Reproduce

Might be a little difficult to reproduce as we are taking ownership of an older, existing ALZ deployment. You would have to deploy an earlier version of ALZ policies, then try and take ownership of these existing assignments, in a specific region.

Expected behavior
We expect the Build-DeploymentPlans cmdlet to display an output similar to the one mentioned earlier, but it should look more like such:

Replace(identityLocation norwayeast->norwayeast,displayName,owner,metadata,parameters,nonComplianceMessages) 'assignmentName' at /managementGroups/identity

EPAC Version
v10.6.1 but issue also occured in v10.5.8.

@Haakonak Haakonak added the bug Something isn't working label Oct 3, 2024
@anwather
Copy link
Collaborator

anwather commented Oct 4, 2024

Strange I'll have to look in the code for why this is happening, can you confirm for that assignment the MI location is set to Norway east? Also since this is ALZ can you give me an assignment this is set for? We might be able to check their code as I know they used to do something weird with MI assignments.

@anwather
Copy link
Collaborator

anwather commented Oct 4, 2024

And L46.

Need to find out what the value of $Assignment.ManagedIdentityLocation is during the run, my guess is it is not defined hence it is adding 'global'

@anwather anwather self-assigned this Oct 4, 2024
@Haakonak
Copy link
Author

Haakonak commented Oct 8, 2024

After more testing it might seem like the output has confused us. Based on which assignments we take ownership of, it looks like the only ones that get the output we are confused about, are the ones who do not require a managed identity. Instead of the output then displaying the change from "norwayeast" to an empty field, it displays it as "norwayeast->global". In our mind it should be an output similar to this:
Location not supported: setting default value instead.

Some of the testing we did before coming to this conclusion:

We tried to take ownership of a few more assignments. These are all in the file: "ALZ-LandingZones-Default.jsonc"

  • Enforce-AKS-HTTPS
  • Deny-IP-forwarding
  • Deny-Subnet-Without-Nsg
  • Audit-AppGW-WAF
  • Deny-Storage-http
  • Deny-MgmtPorts-Internet

We tried to put "managedIdentityLocations" as a value inside each assignment and as a top level "global" value. Neither of these worked. It does not seem like placing "managedIdentityLocations" directly in the assignment files has any impact. We only see changes after switching "managedIdentityLocation" from "norwayeast" to "eastus" in the global-settings.jsonc file.

If we run the command:

Get-AzPolicyAssignment -Scope "/providers/Microsoft.Management/managementGroups/tenant-mg-id" -Name "Enforce-AKS-HTTPS"

We get the following output:
{F4CFCF7C-A44E-4101-B39D-405D8551D136}

After running the Build-Deployment cmdlet, we are being told by the output that the MI location is being set from norwayeast to global. However, this isnt really the case as the assignment does not require a MI, therefore what really happens is that the Location parameter is left empty.

Over all a bit confusing for us, but nothing that was really "wrong" in the sense that it changed our MI location, in places it should not be changed.

@anwather
Copy link
Collaborator

anwather commented Oct 9, 2024

This is a very strange issue which I can't seem to replicate -- ideally, I can find in the code what is happening however if an assignment doesn't have an identity, it shouldn't be triggered. If it does not cause any issues (just confusing output) then we might be safe to close this. Once you take ownership of the policies if it is still happening, we might have to look but at this stage I can't replicate what is happening.

@Haakonak
Copy link
Author

Haakonak commented Oct 9, 2024

Yes it's probably safe to close this issue, as the bug is not changing anything it shouldn't. And the issue doesn't persist after taking ownership of the policies either. Thank you for your responses @anwather!

@Haakonak Haakonak closed this as completed Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting response bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants