Trusted publishing: support for Google Cloud service accounts

[woodruffw]

Support for these would allow PyPI users with Google Cloud-based publishing workflows to benefit from trusted publishing.

An example claim set from a Google Cloud service account, lightly anonymized:

{
  "aud": "{SOME-AUDIENCE}",
  "azp": "{SOME-AZP}",
  "email": "{PROJECT-NUMBER}-compute@developer.gserviceaccount.com",
  "email_verified": true,
  "exp": 1682967007,
  "google": {
    "compute_engine": {
      "instance_creation_timestamp": 1674546966,
      "instance_id": "{INSTANCE-ID}",
      "instance_name": "dev",
      "project_id": "{PROJECT-ID}",
      "project_number": {PROJECT-NUMBER},
      "zone": "us-central1-a"
    }
  },
  "iat": 1682963407,
  "iss": "https://accounts.google.com",
  "sub": "{SOME-AZP}"
}

I've tried to keep the substitution names consistent above, to show where field values are duplicated.

Based on that claim set, it looks like the relevant uniquely identifying fields are:

1. aud (which should be pypi, similar to GitHub-issued JWTs)
2. azp: no idea what this is
3. google.project_id: presumably configured by a user
4. google.project_number: presumably a unique ID that prevents resurrection of google.project_id
5. email: presumably derivable consistently from google.project_number

So, my first educated guess is that we'll want to allow users to configure (3) and (4). Does that sound right to you @di?

---

• Refactor warehouse.oidc.models to make adding new publisher models simpler (warehouse, tests: devolve oidc.models #13553)
• Add OIDC provider models and services for Google Cloud
  • Models: oidc/models: add initial Google models #13559
  • Services oidc: Google JWKS/services scaffolding #13569
• Support multiple publishers in the UI: Add a horizontal tab picker #13571
• Expose Google Cloud providers through forms and views: Add support for Google trusted publishing #15144
• Update emails, etc. to be generic over OIDC provider kinds (xref Expand OIDC email template's publisher specifiers #13667): Generalize trusted publishing emails #13872
• Update user docs: Document additional Trusted Publishers #15192

[woodruffw]

Hmm, the google key doesn't appear in the Google Cloud docs: https://cloud.google.com/docs/authentication/token-types#id

[di]

azp: no idea what this is

This is some reference to the user the token was issued to

So, my first educated guess is that we'll want to allow users to configure (3) and (4).

These are specific to Compute Engine identities and might not be universally available. I think we'll just want to verify aud/sub/email.

More details here: https://cloud.google.com/docs/authentication/token-types#id

[woodruffw]

Sounds good! It looks like email might be a little funky, since it should be derivable from the project number but is marked as optional. But I can certainly start with the assumption that it'll be present.

[woodruffw]

Opened #13553 to kick this off: it refactors oidc.models into a module hierarchy, so that we can add more OIDC publishers without blowing up the size of the existing oidc/models.py.

[di]

Thinking about sub: I haven't found an easy/clean way for a user to get this value (the unique numeric ID of the identity). Additionally, I'm assuming (but haven't confirmed) if a service account is deleted//recreated with the same name, this ID will change. This would be good protection against resurrection attacks, but given that the service account identity includes the project number, which can't be resurrected, I'm not sure it's strictly necessary, so this might become an "optional" field (similar to environment for GitHub)

[di]

@woodruffw I can work on finishing #13571 and adding the forms/views if you want to work on the emails?