BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Sigstore Moves to GA with Enhanced Stability and Reliability

Sigstore Moves to GA with Enhanced Stability and Reliability

The Open Source Security Foundation (OpenSSF) has moved Sigstore, an artifact signing, and verification technology, into general availability. This announcement sees the Sigstore certificate authority, Fulcio, and transparency log, Rekor, also move into GA with their 1.0 releases. The release brings improved stability and reliability to the services for use within production workloads.

Sigstore provides a standard for signing, verifying, and protecting open-source software. The move to GA comes with a 99.5% uptime SLO and the commitment of round-the-clock pager support. Previously the services were maintained on a best-effort basis. In addition, maintainers would periodically make breaking changes and reset data. The move to GA brings a promise of fully stabilized APIs.

High-level Sigstore architecture

High-level Sigstore architecture (source: Sigstore)

 

To achieve this stability the team has created a new staging environment for testing new features. The project has adopted infrastructure-as-code practices by codifying the infrastructure in Terraform. There is also a new CI/CD pipeline leveraging ArgoCD. Additional reliability features include a new public status page.

Sigstore supports a process known as keyless signing. When building with a CI/CD provider that supports OIDC tokens, Sigstore can generate ephemeral signing certificates without the need to maintain a private key. When generating a certificate, Sigstore encodes information from the OIDC token. This includes the path to the repository, the specific commit of the build, and a link to the file that contains the build instructions.

This is powered by the root Certificate Authority portion of Sigstore known as Fulcio. Fulcio can issue signing certificates based on an OIDC identity, such as an email address. Dan Lorenc, CEO of Chainguard, describes the process as follows:

  1. A person logs into their Identity Provider (think Google, or Facebook).
  2. The person requests an Identity Token from their provider.
  3. The person hands that token to the other system (called the Relying Party) they want to login to (think, Sigstore)!
  4. The relying party can verify this token, using data it knew about the Identity Provider ahead of time.

The advantage of this process is that there are no long-lived secrets within the CI/CD pipeline. The keyless nature refers to not needing the long-lived private key. By using ephemeral signing certificates, the risk of leaks is further reduced. The signed artifact can be validated even after the certificate has expired as the signature of the artifact was created in the valid time frame of the certificate. This can be validated against the Rekor transparency log either through the Cosign tool or directly using the get command:

rekor-cli get --rekor_server https://rekor.sigstore.dev --log-index <log-index>

The Cosign tool is designed to simplify signing container images. As part of this release, it also is moved to version 1.0 and is considered ready for production use. Cosign can be used on several artifact types including OCI and Docker images as well as artifacts that can be stored within a container registry such as WASM or eBPF modules. Text files and binary blobs are supported using the cosign sign-blob command.

While Sigstore originally started as a partnership between Red Hat and Google, it is now a part of the OpenSSF. Both Python and Kubernetes have adopted Sigstore and other package repositories, like npm and Ruby, are currently working on integrating with the tool.

Client tools such as Cosign, sigstore-python, and sigstore-java are available for download. More details about the Rekor and Fulcio APIs can be found within their GitHub repositories.

About the Author

Rate this Article

Adoption
Style

BT