End to end encryption of MOF files

[kamranayub]

This would be a nice bundle or plugin to add. In a typical vanilla pull server, MOF files only encrypt the credentials but any other secrets or confidential information is in plaintext and available to anyone with access to the pull server configuration locations.

It would be preferable to simply encrypt MOF files at rest on the pull server (they should be encrypted when cached by the target node). Additonally, perhaps Tug can also provide a secret store API for getting/storing secrets for configurations (we're kind of using our build agent to store secrets but that kinda sucks because it all has to be passed in via parameters--we could build a separate API to do it, but Tug seems like a good place to do it for DSC similar to how it works for Azure Automation). Ideally, trying to figure out how to encrypt any non-PSCredential values is what I'm after.

[ebekker]

Encrypting the at-rest storage of MOF files is pretty straight forward. For example, when using the PS5 bundle, you can be sure to store the MOF files in an encrypted format and adjust the GetConfiguration call to decrypt the files just before serving them up to a node.

[ebekker]

I think the "Secret Store API" is pby a bit out of scope for Tug -- are you looking for functionality similar to something like this?

[kamranayub]

Yes, and I agree the store is out of scope as a core tug feature--but an add-on bundle or something would be great. I'm thinking like Powershell SMA, where you can store and retrieve assets via cmdlets. Rather than using an external store like Vault (which looks amazing, thanks) the DSC secrets could just be stored in the database and managed through the same Tug API. It's more of a convenience thing--someone wouldn't need to buy/build a secret store, it's just a bundle to add on top of Tug.

More importantly, the encrypt-at-rest would be awesome core feature, it's amazing it's not just part of the specification when almost everything else can be encrypted in the pipeline.

[ebekker]

Encryption-at-rest does not need to be factored into the Pull Mode protocol specification, since it's a back-end implementation detail, and DSC server can choose to implement it, but I agree it would be a useful feature to support, however it will require a little design since the issue of encryption key management and related issues come into play.

We may be able to integrate some sort of "Content Filter" feature, as a hook in the "binary server" implementations -- that way you can plug in any sort of translation/encoding process on read/write, including encryption, compression, validation, etc.

[ebekker]

As you can see by the scope and scale of the Vault project, secret storage is a beast unto itself. Perhaps what you're looking for might be a PowerShell interface to Vault? Just a quick search shows me there are a few modest attempts to do this, but it looks like they're trying to do this "on their own" by going directly against the Vault REST API.

I think a better approach may be to leverage one of the two (1 and 2) .NET client libraries and wrap that up in PowerShell-friendly module. That would pby be a great contribution to the community on its own and then it could be incorporated into lots of things, perhaps including DSC configuration to encrypt/decrypt secrets.

[kamranayub]

My coworker and I were discussing that it'd be nice to provide the certificate information to use for encryption--it could use the pull server certificate by default (since that has to be distributed to nodes anyway, you already have it) but you could choose to use a different certificate if you had reason to.

[ebekker]

Hmm, I wonder if I'm missing something -- based on your comment regarding certificates and it being distributed to the nodes, are you thinking that you could encrypt the MOF files, and send them encrypted to the nodes, and which point the nodes would be able to decrypt them? That's not possible -- the nodes are running the LCM client that comes out of the box with PowerShell/WMF and it does not understand an encrypted configuration (or module) payload.

When it requests one of these binary objects from a DSC Pull Mode server, it's using the MS-DSCPM protocol and there are no provisions in that protocol for an encrypted payload.

Is this what you're thinking or did I misinterpret?