Ensuring integrity with Push

This topic contains 7 replies, has 5 voices, and was last updated by  Eric 2 weeks, 3 days ago.

  • Author
    Posts
  • #80345

    Eric
    Participant

    I am considering switching from Pull to Push, for various reasons discussed in other posts. But I don't know how to ensure that what I have in my code repository matches what's in production. Without a central choke point like I have with Pull, an admin could easily push a compiled config to a machine, change the code that generated it, and check that code in – without ever recompiling and pushing it to the machine.

    Put another way, how do I make sure that what I have in code is actually what I have in production?

    With Pull, I have an audit script that compiles the code from the repo each night and compares the MOF it generates with what's on the Pull server. Then I rely on the LCM on each host to ensure it's in line with the Pull server.

  • #80347

    Don Jones
    Keymaster

    You have to treat it like deploying code. Check in, run through a build pipeline, test the results, and push the MOF. Everything after check in gets automated. That's all on you to code up, of course.

  • #80350

    So, do you want to ensure that what it's on the machine is actually the mof you compiled? Or do you want to control who modified the source configuration which you push to all machines?

    • #80353

      Eric
      Participant

      Leandro – the first, that what is on the machine is actually the mof I compiled. Or, that what is on the machine is equal to what is specified by the code in the repository.

    • #80765

      What I can think of is, not nice but, have a Script resource calculating the hash for the mof you're running and if it doesn't match (or pester to test status), then write an entry in the eventlog and pick it up with your monitoring tool.

  • #80735

    Julien Nury
    Participant

    We use Pull server and git'hooks:
    – everytime we push in the DSC Configuration git repository, a script is triggered to rebuild every mofs
    – if the 'build' succeed, we copy all mofs and dependencies in the Pull Server publication folder
    – in about 15 minutes, hosts are getting modified configurations and apply them

    Aditionnaly, we could detect which mofs were updated and trigger a Update-DSCConfiguration on corresponding hosts.

  • #80945

    Ralph Kyttle
    Participant

    I think a tool we released called DSCEA might be able to help. https://microsoft.github.io/DSCEA

    This will allow you take a reference MOF and compare it to systems in your environment to see if they are configured in the desired state.

    • #80963

      Eric
      Participant

      Ralph, thanks for that link! I will check out the tool further; it may be useful for us.

      However, I noticed that the documentation contains a potential solution to my conundrum. You have a screenshot of Test-DscConfiguration and I noticed you used the "ReferenceConfiguration" parameter, which I did not realize existed. It looks like this would let me take a MOF freshly generated from the code in my repo and use that as the basis to audit my machines, regardless of what MOF the server might actually be using. I think that will get me exactly what I want.

You must be logged in to reply to this topic.