Repository navigation
Signing configurations #210
Description
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
Activity
michaeltlombardi commentedon Sep 28, 2023
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 commentedon Sep 28, 2023
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 commentedon Sep 28, 2023
Thomas Nieto (@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 commentedon Sep 28, 2023
Mikey Lombardi (He/Him) (@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 commentedon Sep 28, 2023
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 commentedon Dec 12, 2023
Although we should leverage some specific implementation, we should have
dschave 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 commentedon Feb 25, 2024
Created separate issue #327 for signing resource manifests
5 remaining items
haodeon commentedon Sep 25, 2025
I’m using a GitOps pattern to deliver and execute configuration files. All configuration is stored in version control, where commit signing already provides authenticity and integrity guarantees. In this workflow, additional signing of the configuration files themselves provides little or no extra security benefit.
By contrast, emitting warnings (or worse, errors) for unsigned configuration files creates noise and degrades the user experience. In practice, this leads to warning fatigue or developers silencing messages globally, which undercuts the intended security value.
michaeltlombardi commentedon Sep 25, 2025
If I'm understanding correctly, you're relying on signed commits for verifying at deployment time whether your configuration documents are trustable.
How are you verifying them on the machine where they are applied? How do you know that
some.config.dsc.yamlfile on a server is the same file you deployed? Are you comparing hashes of the files, or only and always using them through CI, or?haodeon commentedon Sep 25, 2025
Like Argo CD with signature verification.
dsc.exeSteveL-MSFT commentedon Sep 29, 2025
Deon (@haodeon) I think in your scenario, we will have #1081 implemented which would allow you to ignore authenticode checks.
haodeon commentedon Sep 29, 2025
I appreciate the check is configurable.
I agree with Thomas's earlier argument, verification of configuration files is the concern of a higher order tool.
dsc.exedoes not run as a service, something has to invoke it. The invoker should verify the files are authentic and consistent.ThomasNieto commentedon Sep 30, 2025
The whole signing story and what components are signed and how that is verified should be complied into an RFC. I want to see the wholistic design before implementation. Signing and security should be thoroughly defined providing a consistent experience for users on any supported platform.
I'm concerned the current PR without a RFC will result in DSC following the same bad signing posture PowerShell has. Currently users of non-Windows cannot verify if their PowerShell scripts/modules have been signed or cataloged signed for over a decade. There is no indication implementation will be anytime soon PowerShell/PowerShell#1159.
Could we also get some background on why DSC a low level tool should be verifying signatures in the first place? In the PowerShell and Linux design paradigms should limit the scope of the application to doing one thing and one thing well. In DSC case it is reading a configuration document and applying that though the discovery of resources.
Lets take a scenario of downloading a configuration document from GitHub or someone's website to apply a the dark theme to my laptop. The website author publishes the checksum or GPG detached signature of the file. The user then runs the commands to verify the file hasn't been tampered with. Then they run dsc to apply their configuration.
The second scenario would be to verify DSC resources on my machine haven't been tampered with. The
pathenvironment or DSC path environment variable is controlled by root or another admin that has control. The binaries in an root/admin owned path. If on Windows the OS would Authenticode check the binaries in use.In both of the examples DSC itself does not have to verify the signatures directly, other processes in place verify and protect the user.
Cross-Platform
Any solution should be cross platform from the beginning. Users of a particular platform shouldn't be more secure than another. The signing technology should be cross-platform and have trust verification. Only one technology should be used so that resource/config authors don't have to sign multiple times for different platforms.
JSON/YAML
My understanding is that only YAML files can be Authenticode signed. This presents multiple issues where a supported file type JSON for resource manifests and configuration documents will always throw a warning/error due to the inherent issue of not being able to sign those files.
DSC supports JSON resource manifests and configuration documents as such a signing solution should take that into account and provide ways for authors to securely distribute them.
Dynamic Config Docs
A solution should account for dynamically generated configuration documents or allow users to disable signature checking.
Import/Adapters
Since these take any file type, those can be signed or not. #1131
Embedded Manifests
#560
Resource Binary
In PR #1130 it currently checks for signatures on the binary. Any solution should work cross platform and account for non-windows signing practices like GPG detached signatures.
The current design also has limitations if the binary is checked for a signature or checksum any dependencies the exe/script leverages is signed or hasn't been replaced.
There is also the issue of scripted languages where the resource author cannot control the version (checksum) of the interpreter (python, powershell, etc)
SteveL-MSFT commentedon Oct 6, 2025
DSC calls resources directly, so I think it makes sense for DSC to check if the resources are trusted and behave accordingly. As WinGet Configure becomes more popular, we don't want people sharing configurations and resources that may be untrusted and having folks just use them. The priority right now is for Windows as our active partners for DSC are focused on Windows and Windows has built-in support for signing.
I think initially I wanted a universal solution for Windows, Linux, and macOS, but I've now accepted that Windows will likely stick with Authenticode and because that's not available on non-Windows, we'll have to support multiple solutions. It may even make sense to have an extension model for custom trust check, although that itself would be an attack vector.