TL;DR:
It looks like Munki is going to need a signed binary and an MDM-delivered PPPC/TCC config profile to continue working properly on macOS Ventura.
Details
Last week was Apple’s Worldwide Developer Conference 2022. Among others things announced and introduced was macOS Ventura, or macOS 13.
As is not unusual for macOS releases, this release contains changes that may affect the functionality of Munki (and other similar tools).
Two changes in particular have the potential to affect Munki functionality (and there may be more, but these were discussed in WWDC sessions):
1) A new “Login Items” section in the System Settings (formerly System Preferences) application. This settings view allows users to easily disable Login Items, Launch Agents, and Launch Daemons. Users require admin rights to disable Launch Daemons. Since Munki makes heavy use of Launch Agents and Launch Daemons, a user could easily and trivially disable Munki from running. At present there appear to be no management options/tools to prevent this. File Feedback with Apple about how important managing would be to your organization.
2) A new privacy protection around “App Management”. This prevents software from changing or removing items from /Applications without user approval. Its effect on Munki can be subtle and easy to miss in simple testing.
On a fresh Ventura install, Munki can install software as it does under Monterey and earlier. But when updating or removing software, it may be blocked from making changes to apps in /Applications. Again, this can be easy to miss in testing. It’s common to have Terminal set for Full Disk Access, and also common for ssh to have Full Disk Access (via /usr/libexec/sshd-keychain-wrapper). Running managedsoftwareupdate via either of these methods will allow Munki to update and/or remove app bundles in /Applications. But Munki operations triggered via launchd jobs will fail to update or remove app bundles in /Applications.
Apple has not yet provided supported/documented management controls to affect or manage this behavior. It _appears_ at present that managing/allowing Full Disk Access will allow processes to update or remove app bundles in /Applications, but I’d really like to see official Apple documentation and recommendations on this topic.
It is possible to “pre-approve” binaries or apps for Full Disk Access via an MDM-delivered profile, but the binary or app must be signed. In the case of Munki, this will most likely have to take the form of a signed binary wrapper/launcher that calls munki-python and the needed Munki scripted tools.
But this surfaces another problem. I don’t want to sign this binary with my personal Apple Developer ID and then distribute that as part of the official Munki release. And (while I have not asked) I suspect my employer doesn’t want to publicly distribute a Munki binary signed by them. While orgs using Munki could sign the tool themselves (and some will), many orgs will find this hard to do. I’d like to find some way to have a “Munki Project” or “Mac Admins” identity for a publicly-distributed release of the Munki tools. If anyone has useful thoughts, ideas, or information on how that might happen, I’d greatly appreciate it.
(Original Google Groups posting here: https://groups.google.com/g/munki-dev/c/yRKhUGjNibY/m/eZ91OxZ5AAAJ)
Managing OS X 
Hey Greg. I’ve submitted feedback about launch items mdm management.
As far as signing Munki, you could incorporate “Munki” or whatever as an LLC, which should provide you with the ability to request a DUNS, and allow you to sign up for an Apple Dev account under that DUNS number.
I don’t Greg wants to incorporate for munki purposes. But I would say that munki is not the only thing that a Mac Admin needs to sign these days. E.G. PHP needs to be maintained and signed in Monterey and higher. So a Mac Admin that sets up munki may have to acquire the skill to sign things for more than just the munki project and perhaps this won’t be as big a barrier as Greg thinks.
Totally fair. Signing can be a pain though if you’re not using a management system (or don’t want to pay for a dev account). Getting the CA pushed out for a self signed cert is going to be problematic once Ventura drops.
Honestly though, can’t say we didn’t see this coming… the other pieces in Ventura are more annoying (users being able to disable system level launch items easily).