A Bit of Ambiance comes to Sigstore
Zero-trust security starts with trusting actual entities based on strong identity, not whoever happens to control a secret, or whoever gets behind a firewall. No secrets sounds great in theory! It even sounds a bit magical. How can we authenticate without any secrets? In reality you can’t but you move the secrets around a bit and change how they work to get a similar effect.
One common technique here is called Workload Identity, which leverages ambient credentials rather than explicit, fixed secrets. We’re excited to announce that Workload Identity is now fully supported in Project Sigstore! The rest of this post explains how these credentials work, why you should use them, and how to hook it all up with cosign.
About Workload Identity
Workload Identity is the pattern you use when receiving credentials from a metadata server on a virtual machine, or from a SPIRE socket mounted into your container. Instead of deploying a secret alongside your code (or god-forbid in it!), your code receives the credentials it needs from the environment. These have to come from somewhere — but the responsibility of storing, distributing, refreshing, and revoking secrets is now managed by the platform provider.
Instead of provisioning long-lived secrets as part of the build/deployment process that need to last as long as the binary might run for, your application can read ambient credentials, on-demand, directly from the environment.
Benefits of Ambient Credentials and Workload Identity
There are many benefits of this approach, including:
Lifetime. Ambient Credentials can be short-lived, and refreshed constantly by the underlying infrastructure. If a token gets lost — it will expire very quickly, limiting the damage caused by a leak.
Revocation. Tokens are issued and bound to specific entities (think a VM, a person, or even an application). This means an administrator can revoke access to an entity and the platform will instantly stop dispensing tokens.
Simplicity/Portability. The easiest secret to manage is none at all. Your application can be configured to use whatever secrets are available, making it easier to write code that works across containers, VMs, and even clouds.
Ambient Credentials in Project Sigstore!
Project Sigstore operates a free root Certificate Authority for code signing called Fulcio. Fulcio is designed to issue certificates completely automatically, which requires it to be able to verify identity across many different systems. The most common approach for federated identity is called OpenID Connect. The exact specification is complex, but you can think of it as this simple model:
- A person logs into their Identity Provider (think Google, or Facebook).
- The person requests an Identity Token from their provider.
- The person hands that token to the other system (called the Relying Party) they want to login to (think, Sigstore)!
- The relying party can verify this token, using data it knew about the Identity Provider ahead of time.
This is the typical system you see when doing a cosign sign command without a key locally. Your browser pops open, you authenticate with your provider (Google, GitHub, Microsoft), and get a brand new certificate. This login flow can be as secure as your provider allows! You can require 2FA, strong passwords, email verification, anything!
This flow works great for people, but until now hasn’t really worked in automated flows. For starters, there’s no person to type a password into a login box. You could always create a service account and store that password in your code, but then you’re right back where we started! This is where Ambient Credentials come in. Using OIDC, Sigstore can be configured to trust Workload Identity providers that are designed to authenticate systems, in addition to traditional person-based ones!
Using OIDC With Cosign
OIDC is not without its warts, but it is widely adopted! This means most cloud providers support issuing identity tokens directly. Open source projects like SPIFFE/SPIRE build on this to define ways to structure tokens and identifiers that are also widely understood. This means that in most environments, we hope you can just run cosign sign and get a certificate with no other configuration! This is possible today in a few places:
- On Google: GCP VMs, GKE clusters with Workload Identity enabled, and Google Cloud Build. See usage docs here.
- On GitHub: COMING SOON. You’ll be able to automatically authenticate directly from GitHub Actions, using their new OIDC support!
- SPIFFE/SPIRE: SPIFFE SVIDs are also directly supported by Sigstore. Add your federation endpoint for use.
If you’d like to see this in action, check out this working example using Distroless. Each image is signed in Google Cloud Build using ambient credentials. Here’s an example signature you can try verifying yourself:
Matt Moore of container fame also did a great demo/tech-talk of this in the OpenSSF’s Digital Identity Attestation Working Group.
