Issue cert with OIDC custom claims

[salrashid123]

Question regarding how custom claims within a provided OIDC token can get baked into the issued cert

Currently, the issued cert emits the email as SAN and custom OID that denotes stuff like the issuer

GCP OIDC tokens minted in certain environments like GCE can include some interesting claims described here. Specifically, it includes information if the system is running confidential compute instance and other variables like projectID and number. I understand that some of these fields might not be appropriate to get baked into the cert but in other cases, the claims in the cert that say "yes, this build occured on a confidential compute instance in project 123, etc" (vs adding those as attestations or key/values during signing; i.,e its baked into the cert just by the oidc token's claims alone)

Is this something thats in the works or is there an abstraction on the cert issue that can inject these claims? (or am i trying to overload the fulcio cert itself for something its not supposed to handle?)

related:

• Standardizing CI OIDC token claims #754
• Proposal: Kubernetes Pod Details OID #778

---

just for ref, only GCE instances have these custom claims but i don't see why other services can't do the same in GCP.

eg, though cloud build doens't currently support id tokens on its own, in the event it did, you could inject runtime claims such as buildID, commitsha and what not

her'es a hypothetical set of claims for gcp in which i just happend to stuff all goolge services into one (gce, cloud run, cloud build; ofcourse only one would be there)

{
  "iss": "https://accounts.google.com",
  "iat": 1513871382,
  "exp": 1513874982,
  "aud": "http://www.example.com",
  "sub": "112179062720391305885",
  "azp": "112179062720391305885",
  "email": "1071284184436-compute@developer.gserviceaccount.com",
  "email_verified": true,
  "google": {
    "compute_engine": {
      "project_id": "my-project-id",
      "project_number": 1071284181111,
      "zone": "us-central1-a",
      "instance_id": "5381466489353574380",
      "instance_name": "some-image",
      "instance_creation_timestamp": 1513826570,
      "instance_confidentiality": 1      
    },
    "kubernetes_engine": {
         "cluster_name": "cluster-1"
    },
    "serverless": {
      "project_id": "my-project-id",
      "project_number": 1071284181111,
      "service": "tok",
      "imageDigest": "gcr.io/mineral-minutia-820/idtoken@sha256:938c785297fdfe4020b5a11992822137bd404ce4d5d1684b188cacc2dff6a7c8"
      "revision": "tok-00001-naz",
    },    
  }
}

[haydentherapper]

Check out #624. This seems like a similar issue, whether or not include provenance into the certificate. Ultimately we decided that Fulcio should just be for identity, and provenance should go into an attestation.

[salrashid123]

ok, makes sense; but i think there's overlap in embedding claims from GCE instance identity documenti with the feature requests above, no? (eg, podID for k8s, the github specifications; to me it seems like a similarly same thing is going on with those FRs as here)

[haydentherapper]

I think this is a little different. For the source repo specification, we're looking at embedding a standard set of claims from source repos like GitHub/GitLab/etc that only refer to the identity of a worker running CI jobs. For pod ID for k8s, this is an active discussion around if the pod is needed to uniquely identify the subject of the certificate.

For GCE, this would include metadata about how the build is produced, but no additional claims about the identity. Determining if the build occurred in a secure VM for example is provenance, not identity.

[salrashid123]

the GCE identity document actually includes info that uniquely idenfies that specific VM instance (the google.compute_engine.instance_id is globally unique so it'd kinda identify where its run with precision (vs a svc account identity which could be any vm in the instance group (or me on my laptop impersonating the svc account; if i impersonated the svc account from the laptop and got its oidc token, ther'es no way i'd also ever get these claims; theyr'e only available from the VM itself).

[haydentherapper]

closing, let me know if you have any other questions.