Draft of trust for DSC artifacts - #1687
Conversation
|
|
||
| ## Proposed experience | ||
|
|
||
| Signing requirement will be opt-in, however, if it is not enabled, then a warning message will be emitted. |
There was a problem hiding this comment.
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.
|
|
||
| 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. |
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.
| 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. | ||
|
|
||
| There would be policy settings to set which signers are trusted, and which signing mechanism is required for a given artifact. |
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 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. |
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:
Code signing is a macOS security technology that you use to certify that an app was created by you. Once an app is signed, the system can detect any change to the app—whether the change is introduced accidentally or by malicious code. You can control how your signed code loads signed plug-ins and other signed code without invalidating the signatures of the host code or of the guest (dynamically loaded) code.
You work with code objects that represent uniquely identified elements of running code in the system. In addition to UNIX processes, these elements can include scripts, applets, widgets, and so forth. You also work with static code objects that represent code in the file system. Static code includes applications, tools, frameworks, plug-ins, scripts, and so on.
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.
| 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. |
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.
| ## 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. |
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.
2 participants
PR Summary
RFC describing how trust will be established for DSC artifacts