Update GitOps config to macOS Sonoma 14.5

[spokanemac]

Updates minimum macOS configuration to 14.5 for Sonoma. https://github.com/fleetdm/confidential/issues/6576

TODO:

• Update MDM Payload in Tines workflow.

[noahtalerman]

@lukeheath and @spokanemac I think when we merge this PR we'll be dogfooding two methods for enforcing OS updates, on every Mac, at the same time:

• Apple's built-in Software Update (DDM feature)
• Fleet's maintenance windows

macos_updates controls the Software Update DDM feature while the macOS - Check if latest version policy is hooked up to the calendar integration for maintenance windows.

I propose that we dogfood Fleet's maintenance windows in Workstations and the Software Update DDM feature in Workstations canary.

Why?

• Fleet's maintenance windows are best practice.
• We still want to dogfood Software Update DDM. Maybe it's actually better? Maybe there are bugs?

What do y'all think?

[spokanemac]

@noahtalerman, My thought was that the Software Update DDM would encourage the update ahead of the maintenance window, with the maintenance window playing cleanup to any host that did not run the update. We will have a requirement to action updates within 15 days in the future, and maintenance windows are currently once a month.

I am OK with your proposed approach, and I will need to undo changes to the Tines workflow. I would like to test the above for the next OS update enforcement.

[noahtalerman]

My thought was that the Software Update DDM would encourage the update ahead of the maintenance window, with the maintenance window playing cleanup to any host that did not run the update.

@spokanemac makes sense!

JD and I just chatted on Zoom and we decided to go with this approach.

Why? We can see what it's like to use both Software Update (DDM feature) to nag users + Fleet's maintenance Window to enforce if they don't get to it.

[noahtalerman]

Marko and I noticed that having both maintenance windows + Software Update (DDM) enabled creates a confusing/conflicting experience for end users.

For example, Noah's maintenance windows is scheduled for 5/21 @9:30a local time. The Software Update notification tells me that my Mac will be updated on 5/31 @12p local time:

[noahtalerman]

cc @spokanemac @marko-lisica @lukeheath ^^

[spokanemac]

@noahtalerman I agree, but we had to pick an arbitrary enforcement date for DDM. I have to do some fancy API footwork to get the version in the Tines workflow, so I don't have to update it with each version bump. I'm open to finding a way of seeing the scheduled time on the user calendar, and setting DDM dynamically for each user, but I think that would be handled in the DDM code.

[lukeheath]

@noahtalerman @spokanemac Agreed, I'm having a confusing experience with both. I had a pop-up today prompting me for an update and saying it was scheduled for 5/31 to happen automatically, but I have a calendar event for tomorrow. We should make the Fleet recommended best practice to use DDM OR a failing policy with calendar automation to update OS versions, but not both.

For our purposes today, can we update the Workstations team to use the failing policy and calendar automation, and use canary to dogfood DDM? Then folks can choose which one they want to dogfood with this update.

[spokanemac]

@lukeheath @noahtalerman The takeaway is that an admin will do what we've done today, so how do we improve this experience? Do we put a warning banner on the DDM settings if a maintenance window is configured? Do we disable DDM settings completely? (This will likely not be seen if configured with GitOps.)

[lukeheath]

@spokanemac I agree; this is a UX issue that other admins will likely repeat. It will require some thought on how to best address it. I created a dogfooding feature request here to cover this case.