Well, you’re very slightly off-base on a couple of things. Let’s review:
One thing we really liked with the pullserver is being sure the right MOF is pulled fort he right server and also being sure there is a central repository. All that makes rogue mof, or the wrong mof used on a node, alot less likely to happen.
Ssssure. One presumes the folder containing the MOFs would be secured so that only trusted administrators would have Write access, so that secures the Pull server. With security auditing on the MOF folder, you’d also have an audit trail of changes, so you could punish the offender. Further, if your MOFs are coming as the end product of a proper DevOps-style toolchain, you could easily revert to a previous version of the MOF and redeploy it.
But pull mode doesn’t prevent a stupid admin from deploying a broken MOF, which the node will then pull. So you’re not SURE the right MOF is being pulled unless you’ve set up a very careful process.
The node decides which MOF it will pull, based upon its meta-configuration, which you push to it. You need to be a local Admin on the node in order for it to accept a push. So if you’re concerned about stupid administrators and push mode, they could mess up the meta-configuration, too.
But the pullserver is severly limited for a production env. We looked at tug, but we have no manpower right now to develop the logic to put in Tug, so we are falling back on push for the moment.
Yeah, the native pull server is pretty bare-bones. MS’ official solution is to use Azure Administration, which can provide a much more robust pull server for cloud and on-prem nodes. Tug may also need less logic-writing than you think; Eugene has been doing a lot to make it a more out-of-the-box solution for common scenarios. And the native pull server, with a SQL back-end, is “decently” robust, so long as you don’t need reporting.
So, am I wrong in saying that with the LCM configured in Push mode, you could push the wrong MOF to a node?
Well, obviously. If you’re an admin on the remote node you could push any damn MOF you pleased. You could also do any number of other destructive things, like formatting the C: drive, shutting it down, etc. And as I noted, even in pull mode, you can still push a bad meta-MOF and get the node pulling the wrong MOF from the pull server. Admins can break things.
Also, anyone could push a mof to a node from anywhere?
No, certainly not “anyone.” Whatever account is used to run Start-DscConfiguration needs to be recognized as a local Admin on the node. You can obviously control who is a local admin on the nodes.
What is advised to prevent such things?
Be careful. Don’t be stupid. Have a good process in place. Be careful who you assign trusted administrator rights to. Frankly, I think it’s probably a lot easier to fat-finger things and mess up push mode than pull mode, if you’re doing it right.
Don’t confuse “security” with “stupidity prevention;” Security features aren’t meant to stop stupid administrators, nor are they designed to prevent mistakes. That’s not what security does. You prevent mistakes by having a controlled process for change deployment, and by relying on trusted administrators (this is why they’re “trusted”) to follow those processes.
If only “ConfigurationNames” could also (optionally) apply to push, it would have been a big plus to limit what mof could be pushed to a certain node.