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.
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.
So, am I wrong in saying that with the LCM configured in Push mode, you could push the wrong MOF to a node?(With pull, the ConfigurationNames parameters would prevent that) Also, anyone could push a mof to a node from anywhere?(baring network access of course)
What is advised to prevent such things?
Well, you're very slightly off-base on a couple of things. Let's review:
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.
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.
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.
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.
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.
Thanks for the detailed reply. Of course, many things can go wrong even with the pullserver, but the main point was that the pullserver seemed to have more features to prevent the deployment of the wrong mof to a node than the push mode, and I wanted to make sure I wasn't missing anything.
It's true that a broken mof could make it's way to a node in a pull scenario, but the chances to suddenly see an SQL server appear on a presentation server are severely less likely in pull mode than in a push mode 🙂 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.
Honestly, the lack of competent resources is hitting us hard over here. Sad but true, we have no choice anymore but to have "less than competent" admins. My feeling is that the cloud will eventually "win" because of this, not because it's better for everything.
You must be logged in to reply to this topic.