Act as an OIDC IdP to access to private repos

[eriksw]

Tell us more.

I want to allow Renovate to access private repos without needing to make any long-lived cloud provider credentials such as Google Service Account Keys or AWS IAM User Access Keys. This can be accomplished if Renovate acts as an OpenID Connect (OIDC) Identity Provider (IdP) because providers like Google Cloud, AWS, and more support acting as an OIDC Relying Party (RP).

This would be useful because it is generally regarded as a best practice to disable the ability to create Service Account keys at the Google Cloud organization level using "Organization Policy" controls, and it'd be nice to not have to make exceptions to that to allow Renovate to check the versions of dependencies in private repos.

Here's the brief, high-level version of what would be involved:

• Renovate would securely maintain asymmetric signing keys used to sign the tokens it issues. It would serve the public portions of these keys, along with some other metadata, at the appropriate /.well-known/... locations.
• On the cloud provider side, you'd set up the appropriate configuration to recognize Renovate as an Identity Provider and what entities (GCP: Service Accounts, AWS: Roles) can be accessed based on the assertions in a token issued by Renovate.
• In a hostRule, instead of storing an encrypted token to be used as-is, you'd configure the necessary parameters for Renovate to be able to exchange a token (issued and signed by Renovate) for credentials from the cloud provider.

To get a bit more specific:

A hostRule configuration for access to an Artifact Registry docker repo might look something like this:

    {
      "matchHost": "us-central1-docker.pkg.dev",
      "authType": "BasicViaGoogleOIDC",
      "googleOIDC": {
        "provider": "projects/00000000000/locations/global/workloadIdentityPools/renovate/providers/renovate",
        "serviceAccount": "renovate-bot@myprojectnamehere.iam.gserviceaccount.com"
      }
      }
    }

The JWT signed by Renovate would probably include a few claim details like this (subsetted from what tokens issued by Github Actions include):

{
  ...
  "repository_host": "github",
  "repository": "myorg/myrepo",
  "repository_id": "1234556",
  "repository_owner": "myorg",
  "repository_owner_id": "1234",
  "run_id": "55a4e2a8-8095-4603-bca1-f7533a691635"
}

Specific References:

• Configuration in Google Cloud consists of setting up Workload Identity Federation and then modifying the policy of the Service Account to grant the Workload Identity User permission to the principalSet://... representing the identity provider configuration and optionally/recommended the desired attribute values. (This can get as fine-grained as you want it to.)
• Configuration in Amazon Web Services consists of creating an OIDC Identity Provider Configuration and adding that provider to the trust policy of a Role.

Unfortunately, I do think there would probably need to be RP (Relying Party)-specific code in Renovate due to differing ways that you exchange the token that Renovate signs for actual credentials usable for accessing cloud provider resources. The overwhelming majority of the work would be reusable from one provider to the next, but there would almost always need to be some work done per cloud and repo type.

Lastly, I do want to make clear that this is about a lot more than just Docker dependencies. On the GCP side there's private git repositories plus all the many kinds of repos in Artifact Registry (Maven, RPM, Apt, NPM, Python, Go, probably more on the way.) On the AWS side there's all the stuff CodeArtifact supports, plus of course CodeCommit (git) and ECR (Docker).

[rarkins]

Thanks for submitting the idea.

Quick questions:

• Are you a user of the hosted app or looking for this for self-hosted?
• Are you interested in writing this implementation yourself?

[eriksw]

I am a user of the hosted app. This would be most useful for the hosted app because the preferred method for configuring an OIDC RP is to reference the IdP by URL and rely upon public web PKI to secure the RP's fetching of the IdP's public keys/etc from the well-known paths. (However, there is pre-release support for side-loading the public keys into the GCP RP configuration.)

I don't have the bandwidth to develop this.

[rarkins]

One problem we have is that we want to remove the use of all shared secrets from the Renovate App at runtime. In other words the only secrets passed to the running container will be user-scoped ones, such as the app token (scoped to their org) or any secrets configured in hostRules.

Wouldn't OIDC as described require having a single private key passed to every job? i.e. if one malicious user can compromise it then they could compromise other user secrets?

[eriksw]

I agree that it'd be a bad idea to allow job executions to access the signing key material.

I'm not familiar with how Renovate handles the decryption of encrypted secrets currently, so my suggestion is based on an assumption that you have some kind of central trusted environment that has the key to decrypt secrets before passing them to the isolated job run environment.

I would extend on that by passing in an additional token to the job run environment at the start of each job. This token would contain a signed set of claims identifying the job run, with an "audience" of a renovate-internal token issuing service. While the job is running, if it needs to get an OIDC token to identify itself to something external, it would be able to use this token to make a request to the centralized token issuing service. The token issuing service's job would be to validate this token and then respond with a token signed by a publicly-trusted key that contains the same claims in the internal token but with the "audience" changed to whatever the job has requested.

I believe this would adequately limit the damage that an RCE within the isolated job execution environment could do: It could obtain a token with any audience, but that token would only be good for accessing resources that were configured allow access from renovate and which were either intentionally granting access to renovate runs for that repo, or were lacking appropriate restrictions on the basis of attribute claims. A compromised job run should not be able to pretend to be a job run of a different repo. (When configuring a GCP "Workload Identity Pool Provider", you might set the attribute conditions to something like attribute.repository.startsWith("mycompany/") && attribute.repository_host == "github_cloud".)