Azure / azure-policy

Repository for Azure Resource Policy built-in definitions and samples
MIT License
1.5k stars 1.09k forks source link

[Preview]: Schedule recurring updates using Update Management Center #1209

Open sajwvanzundert opened 1 year ago

sajwvanzundert commented 1 year ago

Details of the scenario you tried and the problem that is occurring

The policy existence condition only checks for the existence of a link with a maintenance schedule. A maintenance schedule also has a prerequisite of having patch orchestration to be set to Customer Managed Schedule. However, once the policy remediation is run and the maintenance schedule is linked to a VM you can freely change the patch orchestration back to anything unsupported while keeping a link with the maintenance schedule. This in itself is an issue but I think more complicated to fix. Policy will no longer remediate this as the existence condition is still valid.

Verbose logs showing the problem

Suggested solution to the issue

Add patch orchestration parameter as extra existence condition to check if it is set to 'Customer Managed Schedule'.

If policy is Guest Configuration - details about target node

eehret commented 7 months ago

I discovered this issue myself recently and opened a support case about it.

To make matters worse, I can't seem to create a custom policy to remediate the patchMode myself, since on Linux VMs the alias 'Microsoft.Compute/virtualMachines/osProfile.linuxConfiguration.patchSettings.patchMode' is not marked as modifiable in the metadata. I was planning to do this by duplicating and modifying /providers/Microsoft.Authorization/policyDefinitions/59efceea-0c96-497e-a4a1-4eb2290dac15

Alas, this would only work for Windows, which are much less numerous than Linux in our tenant.

See: https://github.com/Azure/azure-policy/issues/1277

BartDecker commented 7 months ago

Can we exchange MS ticketnumbers? I encounter the same problem and am going to raise a ticket today as well.

I tried to leverage this method (as DINE) but here all systems evaluate to compliant. So there is an issue there as well: https://learn.microsoft.com/en-us/answers/questions/1520341/custom-azure-policy-to-enable-automatic-vm-guest-p?page=1&orderby=Helpful&comment=answer-1444586#newest-answer-comment

Looks like same problem exists for: bypassPlatformSafetyChecksOnUserSchedule & enableHotpatching (for windows)

eehret commented 7 months ago

@BartDecker Sure. My ticket for this is # 2401310040013420

Microsoft had the audacity, based on finding confirmation in forums like serverfault.com that this is in fact the current behaviour, to claim that somehow this means it is "expected behaviour".

Ridiculous.
My counter to their assertion was to ask that , if it's expected , then why aren't these limitations documented?

Good luck! Hopefully together we'll be able to get some momentum behind a proper fix to these issues.

BartDecker commented 7 months ago

Wht you at least could do is leverage the other related update manager policy (the one that sets the patchmode/schedules). Strip the maintenance configuration part of it and use the rest.

Like mentioned in: https://learn.microsoft.com/en-us/answers/questions/1520341/custom-azure-policy-to-enable-automatic-vm-guest-p?page=1&orderby=Helpful&comment=answer-1444586#newest-answer-comment

It could indeed be that the non-modifiable is needed on the linux if the setting cannot be change within the OS at deploy time. I'm not 100% sure if this setting is a 100% "external to os" setting or if it has also a related "within os" config setting.

BartDecker commented 7 months ago

I also created a ticket @ MS