Workload Identity Meets Supply Chain Security: Teleport's Sigstore Integration

It’s no secret that the software development life cycle is becoming more complex.

With a plethora of libraries, frameworks, and now AI coding agents and assistants, we can build far more ambitious software in a fraction of the time. This is fantastic! But with it come greater opportunities for accidental or malicious security bugs and vulnerabilities to sneak in undetected, with potentially devastating consequences for your users and their trust in your company.

One particularly memorable example of this is the SUNBURST attack, which in 2020 saw tens of thousands of SolarWinds customers including government and healthcare agencies impacted by a highly sophisticated backdoor, injected into the popular Orion software package at build-time.

Thankfully there is a growing ecosystem of tools around the problem of securing the software supply chain; from your laptop, through CI, all the way to the production environment.

These tools are built on a foundation of trust established with cryptographic signatures. In order to trust that the container image running in production is the same as when it left CI, or that the results of a vulnerability scan haven't been tampered with, we must sign them and securely distribute the key material needed to verify these signatures.

What is Sigstore?

Sigstore is a framework and suite of tools for signing software artifacts such as binaries and container images, as well as "attestations" of the software's origin, dependencies, build process, test results, and pretty much anything you can represent using the in-toto format.

There are a number of other projects in this space (e.g. Notary), but Sigstore is emerging as a leader and is the core technology behind GitHub's artifact attestation and npm's package provenance features.

It offers a novel solution to one of the hardest problems in artifact signing: key distribution. With traditional signing solutions, you typically need to create and distribute long-lived signing keys or certificates. Rotating and revoking these credentials is difficult, so teams frequently put it off until it's too late.

Sigstore takes a very different approach with its "keyless" mode, which leverages single-use certificates bound to an OIDC identity (e.g. a Google account or GitHub Actions token). In the same way Teleport removes static credentials from human and machine infrastructure access, Sigstore removes them from code signing and verification.

Sigstore also records its signatures in a public transparency log for auditability, which makes it possible to monitor for unauthorized use of your identity or a compromise of the Sigstore infrastructure itself.

Getting started with Sigstore is easy. To try it out locally, use cosign to sign a container image. It will open a browser window for you to log in with your Google, Microsoft, or GitHub account, and push the signature up to your container registry.

$ cosign sign $IMAGE

Consumers can then check you really have signed the image with cosign verify:

$ cosign verify $IMAGE \
  --certificate-identity daniel.upton@goteleport.com \
  --certificate-oidc-issuer https://accounts.google.com

Note that we didn't need to figure out how to share our public key.

What does this have to do with Machine & Workload Identity?

Teleport Machine & Workload Identity replaces static credentials with SPIFFE-compliant cryptographic identities and short-lived certificates, enabling secure, policy-based authentication and mutual TLS between workloads and services.

Using tbot's SPIFFE Workload API, applications can obtain cryptographically verifiable identity documents called "SVIDs" (X.509 certificates or JWTs) which can be used to authenticate with other systems, or be exchanged for cloud credentials (for example, by using AWS Roles Anywhere or GCP Workload Identity Federation).

When an application requests a SVID, tbot performs a process called workload attestation to discover information about it such as the container image and Kubernetes pod labels. Teleport can use this information to decide whether or not to issue the SVID.

Now, tbot can also discover container image signatures as part of the attestation process, and they can be incorporated into the credential issuance decision.

In other words: by using the Sigstore integration, you can bake supply chain security into your workload identity. You could, for example, lock down access to your microservices, databases, or cloud accounts to only software built and signed in your trusted CI environment or that has passed a scan for CVEs and other common vulnerabilities. This massively reduces the surface for and potential impact of supply chain attacks.

Getting started

There are broadly three steps required to enable Teleport's Sigstore integration:

1. Create a SigstorePolicy object that describes how and by whom artifacts must be signed and attested.
2. Call the sigstore.policy_satisfied function from your WorkloadIdentity rules to ensure the policy's requirements are met before issuing SVIDs.
3. Enable tbot's Sigstore attestor, which discovers image signatures for Kubernetes, Docker, and Podman workloads from an OCI registry.

Demo

Let's take a peek at how this looks in practice. To follow along, see the full example code here.