sigstore
Proposal: Kubernetes Pod Details OID
Description
We should add more details about Kubernetes based OIDC tokens in certificates to ID pods / service accounts.
Currently we only include the service account / cluster, i.e.
Subject Alternative Name (critical):
url:
- https://kubernetes.io/namespaces/default/serviceaccounts/default
OIDC Issuer: https://container.googleapis.com/v1/projects/...
https://rekor.tlog.dev/?logIndex=3405075
We actually already parse out all of the claims, but we don't include them in the cert:
https://github.com/sigstore/fulcio/blob/6b5f9aecf50803569ebda6e064561fd0838dddbc/pkg/identity/kubernetes/principal.go#L86-L95
Including these would let us identify the individual pod that ran, similar to how we can ID individual GitHub Action workflows with the GitHub custom claims.
Proposal: Add new OIDs for Kubernetes runtime information.
It probably also makes sense to start creating sub-directories of OIDs depending on the custom claim types - i.e. reserve 1.3.6.1.4.1.57264.1.7 for custom Kubernetes claims (2-6 is already in use by GitHub Actions) then add:
| OID | Name |
|---|---|
| 1.3.6.1.4.1.57264.1.7 | Kubernetes Claims |
| 1.3.6.1.4.1.57264.1.7.1 | Namespace |
| 1.3.6.1.4.1.57264.1.7.2 | Pod Name |
| 1.3.6.1.4.1.57264.1.7.3 | Pod UID |
| 1.3.6.1.4.1.57264.1.7.4 | Service Account Name |
| 1.3.6.1.4.1.57264.1.7.5 | Service Account UID |
cc @asraa @laurentsimon curious what y’all think about this. We’ve had a similar conversation about additional metadata in the certificate for GHA workflows and decided that is more about provenance metadata rather than identity.
Are Name and UID representative of the same identity?
My initial thought is we represent the service account in the certificate and scope it to a namespace, and that should be sufficient, because that represents a unique identity iiuc.
There's also some prior art for this representation of an identity with Istio certificates, which take the format spiffe://trustdomain/ns/<namespace>/sa/<service account>
I suppose here it may make more sense than in the GHA case, because different pods could have different security guarantees? So this would help provide more information about the builder / signer itself? (IIUC)
In GitHub case, there was an additional claim about "self-hosted" vs "GH-hosted" workflow that, when available in the OIDC token, could be added to the certificate for a similar purpose.
+1 on the general notion of sub-directories based on types
Including these would let us identify the individual pod that ran, similar to how we can ID individual GitHub Action workflows with the GitHub custom claims.
I think this should be the case -- the namespace is still a grouping of pods. Having identification of pods means if sharing resources between individual compute resources, they can be identified.
I can't decide if pods are analagous to jobs or workflows in the GHA case, but either way, I think if job-identification could occur in GHA, we would have that in the GHA claims and it would make our lives a little easier.
I'm going to close this out, feel free to reopen if you think this is still something that is needed. I don't think it's necessary to include pod information because this seems closer to something like the job in GHA, and verification policies wouldn't be written on that level of granularity.