Open jsuereth opened 6 months ago
jpkrohling
commented
6 months ago While we don't have an official recommendation right now, we have implemented code signing for the Collector and are gathering learnings from that. It would be valuable to us if you could follow what we are doing with the Collector and share your experience.
@cpanato helped us implement the code signing there, perhaps he'd be able to help you with this as well.
jpkrohling
commented
4 months ago I was able to get to this today. The current link to the attestation documentation for cargo is this: https://opensource.axo.dev/cargo-dist/book/supplychain-security/attestations/github.html
It uses GitHub's attestation features, described here: https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/
The blog post has a "how it works" section, which matches my understanding of sigstore and how we are doing with the Collector: we do the release from within a GitHub workflow, which obtains an OIDC token from GitHub. An ephemeral private key is generated, and this token is used with the key to sign the artifact that is being released. The results are recorded in the transparency logs, which can be verified by users.
What I like about using GitHub attestations is that it allows GitHub users to use gh attestation verify, but you'd still need to provide instructions to your users on how to verify the artifacts. For the Collector, we are using cosign, which should also work with cargo-dist/github, as they all use the same infra behind the scenes (especially the transparency logs).
From your requests:
- An integration guide on recommended options from Otel Security SiG
- A mechanism to update Github Action workflows to sign all artifacts (ideally supported by cargo-dist).
sigstore is the common thread here. I like GitHub's approach very much and I think we can end up recommending that widely to the OTel SIGs. I find their blog post a great reference, but we could certainly come up with something of our own in this repo here. It won't be much different than the instructions from that blog post though.
- A shared set of keys that denote "This was built by open-telemetry automation" that is owned by security sig but we can leverage for signing artifacts we publish.
The most common setup for sigstore, especially in CI, is to use ephemeral keys, with the identity coming from an OIDC token. GitHub generates the token based on the org, repo, and build ref. This way, the identity of a deliverable isn't tied to the person or organization that released it but to the workflow that did it. This provides a link back to the SHA that triggered that release.
jsuereth
commented
3 months ago @jpkrohling Thanks again for looking into this. I plan to add the GH attestations to weaver going forward. You can see we did for docker attestations here: https://github.com/open-telemetry/weaver/pull/319
The Semantic Conventions Tooling Working Group is looking for advice on signing artifacts.
Background.
Weaver is a templating tool we own that generates markdown documentation and code from semantic conventions. It is distributed as the following:
You can find an asset list on the 0.4.0 Release
Weaver includes a command line interface that generates code, calculates statistics and allows interactive interaction with the repository to discover names/signals that can be generated.
Today, weaver artifacts are unsigned and, e.g., the windows distributions issue a security notice.
The distribution tooling we have has guidance on how to solve this: cargo-dist Signing and Attestation
Needs
We'd love guidance (ideally in the form of a How-to-Guide) on how to sign our artifacts. Particularly: