Keyless Sign OIDC Providers

[alecrevangelista]

Cross posting my cosign GitHub Issue here just in case its a Fulcio related-issue.

I have been looking into using keyless signing again. My problem is that I want to be able to use keyless signing completely from the command-line / terminal (without the need to login through a UI). So far, the cosign docs haven't shown how to do this with OIDC providers other than GCP... The example in the documentation is:

cosign sign --identity-token=$(gcloud auth print-identity-token --audiences=sigstore) gcr.io/user-vmtest2/demo

We do not use GCP so unfortunately this is not an option for us. Alternatively, I did try using my Amazon EKS Cluster as the OIDC provider (following this guide), and the Identity Token I received from that turned out to work with cosign just fine. The ID token from EKS took this form:

{
  "aud": [
    "sigstore"
  ],
  "exp": 1727329539,
  "iat": 1727328939,
  "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/EKS_ID",
  "kubernetes.io": {
    "namespace": "MY_EKS_NAMESPACE",
    "pod": {
      "name": "MY_EKS_POD",
      "uid": "1234567899"
    },
    "serviceaccount": {
      "name": "MY_EKS_SERVICE_ACCOUNT",
      "uid": "1234567890"
    }
  },
  "nbf": 1727328939,
  "sub": "system:serviceaccount:MY_EKS_SERVICE_ACCOUNT"
}

I wanted to try and see if we can use Hashicorp Vault as an OIDC provider. Our Vault ID token takes the form:

{
  "aud": "sigstore",
  "email": "[email protected]",
  "exp": 1727332282,
  "iat": 1727328682,
  "iss": "https://stg.vault.company.com/v1/VAULT_NAMESPACE/identity/oidc",
  "namespace": "t9wNo",
  "nbf": "1727328682",
  "sub": "1234567890"
}

The public keys can be reached at https://stg.vault.COMPANY.com/v1/VAULT_NAMESPACE/identity/oidc/.well-known/keys. However, using this token unfortunately leads to the error:

cosign sign-blob --identity-token eyabc --output-certificate cert.txt --output-signature sig.txt test.txt --bundle cosign.bundle
Using payload from: test.txt
Generating ephemeral keys...
Retrieving signed certificate...
Error: signing test.txt: getting key from Fulcio: retrieving cert: not verified by identity provider
main.go:74: error during command execution: signing test.txt: getting key from Fulcio: retrieving cert: not verified by identity provider

Is there anything wrong with the Vault token claims? Is the Vault token not an option we can use? Are there any other options we can use for our use-case?

[alecrevangelista]

I see that AWS EKS is part of the list of supported OIDC providers: https://github.com/sigstore/fulcio/blob/main/config/identity/config.yaml#L108-L110, so this addresses one of my questions.

Based on the doc: https://github.com/sigstore/fulcio/blob/main/docs/new-idp-requirements.md, perhaps Hashicorp Vault can be added as an additional Idp, or is that not a feature that is possible? If so that would be very good for us.

[haydentherapper]

I think you're hitting two issues.

not verified by identity provider is because the token you've provided contains an email but not an email_verified claim.

The other issue is that Vaults are self-hosted and I thought typically not publicly exposed, though I'm not very familiar with the product. This would mean that Fulcio cannot verify the token provided for a self-hosted vault without the identity provider being public as well.

If so, you could host your own instance of Fulcio within your network, configured to support your vault (adding something like this but with your vault values).

[alecrevangelista]

Hi @haydentherapper,

Thanks for the response! Regarding the two issues you pointed out:

1. We added the email_verified claim but it still won’t take the token, probably due to issue no. 2 you pointed out above
2. So from that list of supported providers, Vault is not one of them BUT we do expose the public keys over at https://<stg/prod>.vault.<company>.com/v1/<namespace>/identity/oidc/.well-known/keys -- Isn't this the only thing that needs to be exposed based on these requirements?

With that, was is there any possibility of adding Vault in the future?

[haydentherapper]

Actually I think this is straightforward to add assuming the URIs are standard. We can add Vault instances as "meta issuers", meaning we just use * in place of any values unique to your deployment. Is https://*.vault.*.com/v1/*/identity/oidc/ a standard URI for vault deployments?

[alecrevangelista]

@haydentherapper, yes that looks to be Vaults standard URI. Under the hood, what exactly is happening? From my understanding, is it:

1. A signing request is made through cosign sign-blob --identity-token <> ...
2. The identity-token will contain a base URI in the iss claim, which the backend will just append .well-known/openid-configuration to
3. The fully-constructed URI: $ISS/.well-known/openid-configuration is inspected for the jwks_uri value, which will then point to $ISS/.well-known/keys.
4. The pubkeys are retrieved from here and then other validation stuff happens

I ask because I think in Vault there are two OIDC setups, a multi-tenancy setup and a global setup. This means the iss can be either:

1. https://stg.vault.COMPANY.com/v1/<namespace>/identity/oidc OR
2. https://stg.vault.COMPANY.com/v1/identity/oidc/provider/<provider>

But I guess the regex https://*.vault.*.com/v1/*/identity/oidc/* like you mention above will account for this since it all starts with that iss param?

[haydentherapper]

As I mentioned over Slack, I haven't been able to find documentation that that regex is standard for a Vault deployment - if you have any references, that would be helpful.
We also want to make sure we're supporting well-secured hosted instances like the other providers. Most of the supported providers are public, so this is a bit of a unique case, since iiuc some vaults are self-hosted, some are managed by Hashicorp.