Chainguard OIDC provider support

[mattmoor]

Description

Today Chainguard makes extensive use of Sigstore, and has long had it's own OIDC issuer (the fake used in this repo is derived from the skeleton of our original issuer).

We leak certain implementation details into our signatures (e.g. github actions), and so I would like to explore the option of signing our images with our own tokens.

Chainguard tokens with the appropriate audience can be produced with our CLI chainctl using:

chainctl auth token --audience sigstore

chainctl also supports assuming identities (e.g. from a CI workflow, see actions)

---

We also have our own internal notion of "service principals" which we use in a manner similar to Google's P4SA's (e.g. PROJECT@SERVICE.iam.gserviceaccount.com) or AWS's service linked roles to authorize access to customer resources by our internal services.

One of the specific scenarios that I am interested in supporting is signing/attesting OCI images with these customer-bound service identities. Here's an example token for the "catalog syncer" service principal from my dev environment:

{
  "header": {
    "alg": "RS256",
    "kid": "350024afa8480d687f2923bb7a7553a63e3b878b239edc02ed9279ebbdf11f1f"
  },
  "payload": {
    "act": {
      "aud": "chainguard",
      "iss": "https://issuer.mattmoor.dev/",
      "sub": "catalog-syncer:9a2552c399fb9e7ebb42c63c2c7e7984207eb31c"
    },
    "aud": "sigstore",
    "exp": 1718851916,
    "iat": 1718848316,
    "internal": {
      "service-principal": "CATALOG_SYNCER"
    },
    "iss": "https://issuer.mattmoor.dev/",
    "sub": "9a2552c399fb9e7ebb42c63c2c7e7984207eb31c/dc6a6a7f55ea79d7"
  },
  "signature": "REDACTED"
}

The way I would read this is:

• This is the CATALOG_SYNCER service principal,
• For the 9a2552c399fb9e7ebb42c63c2c7e7984207eb31c organization,
• With the full identity subject 9a2552c399fb9e7ebb42c63c2c7e7984207eb31c/dc6a6a7f55ea79d7.

I have some changes to Fulcio in progress (largely modeled after the Codefresh changes, which were the most recent) that would turn this into the subject: https://issuer.mattmoor.dev/9a2552c399fb9e7ebb42c63c2c7e7984207eb31c/dc6a6a7f55ea79d7

However, two things I'd love to discuss encoding via OID:

1. I'd love to encode our "actor claims" (act),
2. I'd love to encode the "service principal" (when specified).

cc @haydentherapper @bobcallaway @cpanato @priyawadhwa

[haydentherapper]

For adding more Sigstore OIDs, we'd want them to be generalizable and reused across providers, eg the OIDs added for CI providers. OIDs should be parsed and verifiable by all Sigstore clients, and from what you've described, these claims seem specific to your use case and so I'd assume only a Chainguard client would implement support for those OIDs.

I would rather have them encoded in the SAN, like what's done with the Kubernetes issuer, and parsed by your client. Another option would be specifying the claim values in OIDs under your control, as in not under 1.3.6.1.4.1.57264.

[mattmoor]

I like the idea of registering our own OID. Let’s say that’s the tentative plan, and we can iterate on expanding our cert stuff once we have got that registered.

If we find there is appetite for a standard set of OIDs for service principals later, then we can cross that bridge. 😁