Draft of trust for DSC artifacts #1687
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,58 @@ | ||
| --- | ||
| RFC: RFCNNNN # WG will set the number after submission | ||
| Author: SteveL-MSFT | ||
| Sponsor: null # <@GitHubUserName> | ||
| Status: Draft # <Draft | Experimental | Accepted | Final> | ||
| SupercededBy: null # <Superceding RFC Number> | ||
| Version: 1.0 # <Major>.<Minor> | ||
| Area: Security | ||
| CommentsDue: null # <Date for submitting comments to current draft (minimum 1 month)> | ||
| --- | ||
|
|
||
| # Trust and DSC Artifacts | ||
|
|
||
| To enable defense-in-depth security for DSC artifacts, this RFC proposes a signing mechanism for DSC artifacts. This will allow consumers of DSC artifacts to verify the authenticity and integrity of the artifacts they consume. | ||
| Artifacts include DSC configuration files, DSC manifests, and the executable used by the DSC manifest. | ||
| Only YAML format DSC artifacts will be supported for signing. | ||
|
|
||
| ## Motivation | ||
|
|
||
| > As an Enterprise Administrator, | ||
| > I want to restrict the execution of DSC artifacts to only those that are signed by a trusted authority, | ||
| > so that I can ensure a secure supply chain for DSC artifacts. | ||
|
|
||
| ## Proposed experience | ||
|
|
||
| Signing requirement will be opt-in, however, if it is not enabled, then a warning message will be emitted. | ||
| A policy setting will be added to enforce the signing requirement. If the policy is set to enforce signing, then unsigned artifacts will not be executed and an error message will be emitted. | ||
|
Collaborator
There was a problem hiding this comment. I suspect this is out of scope for this RFC, but wanted to clarify that the trust model should also include not just that artifacts are signed but which identities/methods/etc to trust. Initial implementation being binary to whether the artifact is verifiable is okay in my opinion. |
||
|
|
||
| The `DSC resource list` (and corresponding JSONRpc API) will be updated to include a `Trust` property for each resource. | ||
| The values will be `Authenticode`, `Catalog`, `Notary`, or `None`. This will allow consumers to determine the trust level of a resource before consuming it. | ||
|
Comment on lines
+29
to
+30
Collaborator
There was a problem hiding this comment. If I'm understanding correctly, the return data will look like (other fields elided): trust: none
---
trust: authenticodeOr are these variants that will carry the relevant metadata? I think it would also be useful to be able to review the signing/trust details for specific resources and extensions, possibly as a separate command and JSONRpc API endpoint. |
||
|
|
||
| ## Specification | ||
|
|
||
| DSC deployment at-scale is currently aligned with using OCI registries to store and distribute DSC artifacts. | ||
| Therefore, the signing mechanism will be aligned with the OCI registry signing mechanism. | ||
| The signing mechanism will be based on the [Notary Project](https://notaryproject.dev/) which specifically is for signing and verifying content in OCI registries. | ||
|
Collaborator
There was a problem hiding this comment. In prior working group discussions we floated the idea of an extensible architecture for verifying artifacts. We should clarify whether we only intend to support built-in verification options or an extensible model with built-in verification extensions. For example, sigstore/cosign is an alternative that enables developers to sign their artifacts with an OIDC identity and, importantly for us, is already adopted by many package registries including homebrew and PyPI. |
||
|
|
||
| There would be policy settings to set which signers are trusted, and which signing mechanism is required for a given artifact. | ||
|
Collaborator
There was a problem hiding this comment. We should probably also consider explicit allow listing for artifacts that a user/security team trusts but which aren't signed by a supported mechanism. Probably for manifest files we should minimally require both the fully qualified type name and full path to the manifest. If the policy includes a SHA we should require that to match as well. |
||
|
|
||
| On Windows, there will be additional support for signing and verifying DSC artifacts using the Windows Authenticode signing mechanism. | ||
| This includes both Catalog signing (required for Windows in-box components such as Windows PowerShell) and individual File signing (binaries and YAML files). | ||
|
|
||
| Authenticode trust is determined by the Windows trust store, which is managed by the operating system. | ||
|
|
||
| Notary signing and authenticode signing are not mutually exclusive. | ||
|
|
||
| ## Alternate Proposals and Considerations | ||
|
|
||
| PGP/GPG signing was considered, however, it was determined that the Notary Project is a better fit for the OCI registry signing mechanism. | ||
|
|
||
| On Linux/macOS, there will be resources that rely on binaries that are not part of the OCI artifact (e.g. python). | ||
| Since there isn't individual file signing on Linux/macOS, it may make sense to at least verify the folder of the binary has permissions that don't allow world write access. | ||
|
Comment on lines
+51
to
+52
Collaborator
There was a problem hiding this comment. I'm not particularly familiar with code signing on macOS, but my understanding is that there is some support for signing - the developer docs state:
While not an immediate requirement (and related to the extensible architecture comment above), we probably want to consider the standards for macOS and see whether and how we can fit within those. |
||
|
|
||
| ## Related work items | ||
|
|
||
| - [Signing Resource Manifests](https://github.com/PowerShell/DSC/issues/327) | ||
| - [Signing Configurations](https://github.com/PowerShell/DSC/issues/210) | ||
| - [DSC Registry Proposal](https://github.com/PowerShell/DSC/issues/92) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We (probably) want a way to suppress the warning messages. Especially for the initial work, when most resources in use (like PSDSC class resources) won't be signed.
Otherwise I suspect it will raise a fair bit of noise and users will complain about not being able to use policy to suppress the warnings.
I would expect the default to be emitting a warning and both the error and silently continue variants to be opt-in through policy.