softwaresupplychain

Signing and Securing Confidential Kubernetes Clusters in the Cloud with Sigstore

This is a Sigstore case study contributed by Fabian Kammel of Edgeless Systems Confidential computing is an exciting new technology that can help make the public cloud more secure. It protects data stored on leased third-party infrastructure and ensures nobody modifies or intercepts it, whether it resides on the cloud or is being routed to or from your internal assets. But it’s also vital that security solutions like those of Edgeless Systems are secure themselves.

Sigstore Update — August 2022

It has been very busy in the Sigstore community over the past few weeks with lots of activity and initiatives progressing at speed. With so many exciting things happening it’s hard to keep up, but here’s a summary of the highlights from the past month. NPM set to adopt Sigstore GitHub just announced a new request for comments (RFC) for linking packages to their source and build environment for the npm package manager.

Adopting Sigstore Incrementally

Developers, package maintainers, and enterprises that would like to adopt Sigstore may already sign published artifacts. Signers may have existing procedures to securely store and use signing keys. Sigstore can be used to sign artifacts with existing self-managed, long-lived signing keys. Sigstore provides a simple user experience for signing, verification, and generating structured signature metadata for artifacts and container signatures. Sigstore also offers a community-operated, free-to-use transparency log for auditing signature generation.

Privacy in Sigstore

Photo by Tim Mossholder on Unsplash By default, the keyless signing flow for Sigstore exposes a user’s email: $ rekor-cli search --email zack@example.com \ # not my real email! | wc -l Found matching entries (listed by UUID): 112 Specifically, a user logs in to Fulcio with OIDC. Fulcio issues a short-lived certificate with the SAN set to your email address as reported by the OIDC identity provider, even if your email is not typically exposed on that service itself (for instance, your GitHub email will be exposed, even though it’s not generally public).

Sigstore: Bring-your-own sTUF with TUF

Users of Sigstore may want to leverage Sigstore tools and infrastructure, but may not want want to rely on Sigstore’s root of trust or all of the components of the public infrastructure. For example, a company may want to maintain a private transparency log for all internal build information but only make entries to a public log for published releases. Or, a user may not want to include their email addresses in a public certificate transparency log.

Celebrating 1,000,000 entries in Rekor

We’ve finally reached a million entries! We hit a million entries by the end of 2021: rekor-cli get — log-index 1000000 LogID: c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d Index: 1000000 IntegratedTime: 2021–12–27T21:34:27Z UUID: abb93264122dc2eb6da3ac77957978dda3ceb3521ab52cdff8490b23eaf791c1 As a double milestone — the turn of the year and the next order of magnitude — this is a good opportunity to look into what’s become of the Sigstore ecosystem since its inception. Throughout the last year, we’ve seen a lot of different initiatives, new types of signatures added, tools, major features, and more from the whole community.

It’s ten o’clock, do you know where your private keys are?

Short-lived certificates are great — a short lifetime removes the need for complicated revocation policies and reduces an attacker’s window of opportunity. Yet using short-lived certificates in the software supply chain brings a lifetime problem: how can users trust artifacts after the certificate’s expiration? Repeatedly signing artifacts and requesting certificates is tedious. Really, distributors only need to prove that artifacts were signed when the certificate was valid… with timestamps! Enter SigStore’s new, free, open-source RFC 3161 timestamping service on the transparency log Rekor!

A Safer curl | bash ?

This post is about using container registries (Docker registries, OCI registries, whatever you want to call them) for the storage and distribution of generic, non-container-related binary artifacts. I explain the reasoning below, but first: code and demos Demos! Here’s a quick walkthrough of a draft tool (still WIP!) to securely fetch published contents from an OCI registry, called sget. sgetis part of the sigstore project, and is a standalone client that allows you to retrieve scripts or binaries from any OCI registry.