Signing configurations

[SteveL-MSFT]

Summary of the new feature / enhancement

Need a way to enable only executing signed/trusted configurations. Need a cross-platform solution (ideally)

Proposed technical implementation details (optional)

No response

[michaeltlombardi]

Tools like cosign, ansible-sign, and minisign are what come to mind initially.

I've been following cosign for a while. It's initial selling point was signing container images (or ORAS artifacts, which might be worth keeping in mind re #92), but it also supports signing arbitrary blobs.

Relatedly, though possibly a fully separate issue, is whether a sort of sbom for configuration documents makes sense (unwinding the declared resource types and giving a more "full" snapshot of what the configuration document intended to convey).

Also worth keeping in mind on the approach whether/how to sign and verify manifests, and whether/how to indicate that DSC should only use signed and trusted resources and manifests.

[ThomasNieto]

Should DSC be validating signed configurations or should that be at a higher layer like an agent?

It could be problematic that DSC is making these kinds of technology decisions as what DSC has been proposed is a low level tool, reading configuration and apply using resources. You're getting more into the solution layer when deciding which plain text configuration is valid or not.

As an example, in my thought experiment of bringing back the LCM and pull server in DSCv3 I was going to use GPG as the tool as it was cross-platform and was able to validate signatures and encrypt configuration at rest/transit between pull server and node before passing the configuration to DSC.

[michaeltlombardi]

@ThomasNieto - that's a fair point. I think there's still value in signing and sboms for publishing DSC Resources (or reusable configurations, potentially) to a registry, but I see the sense in what you're saying around higher order tools being responsible for "should my users trust and execute this configuration or resource?"

[ThomasNieto]

@michaeltlombardi I agree that there should be signing for DSC resources. The problem I see is that DSC supports resources in different languages and each use different signing schemes. Should DSC enforce its own signing policy or should that be left up to each language? If DSC enforces its own signing then the author may have to support multiple signing technologies. For example, if I write my DSC resource in PowerShell or C# I can use Authenticode to sign the files. If I decide to write in a Linux paradigm I may use GPG to detach sign my files and publish the public key on the website for user validation.

[michaeltlombardi]

Sorry, to clarify for "signed resources" - I meant the manifests for command-based resources and the hypothetical ORAS artifact for resources published to the registry I proposed in #92 - I think you're probably right that whether/how the commands the resource runs are signed/trusted is a different scope of problem.

[SteveL-MSFT]

Although we should leverage some specific implementation, we should have dsc have an extensibility model to support different ways of signing/validation so it's not locked to just one type. This will aid in adoption for environments that already standardized on signing.

[SteveL-MSFT]

Created separate issue https://github.com/PowerShell/DSC/issues/327 for signing resource manifests