Allow access/configure authentication to private (python/poetry) registries hosted by Google Artifact Repository

[dolfandringa]

Is there an existing issue for this?

• [X] I have searched the existing issues

Feature description

Potentially related to #5836, but a bit different because I dont use Workload Identity Federation. I want dependabot to check my python/poetry dependencies, but this fails with authentication errors like this one when running the dependency graph manually:

Dependabot failed to update your dependencies because there was an error resolving your Python dependency files.

Dependabot encountered the following error:

Creating virtualenv <myenv> in /home/dependabot/.cache/pypoetry/virtualenvs
Updating dependencies
Resolving dependencies...
Source (<my-registry>): Authorization error accessing <redacted>

This is probably because dependabot doesnt know how to authenticate against Google Artifact Registry (GAR). There is a google supplied github action for this that is used in regular github actions. It requires setting a GOOGLE_AUTHENTICATION_CREDENTIALS_JSON secret. But the python (and other?) private registries only allow a username/password or token to be specified, and dont make any mention of GAR.

So the feature request is either:

1. Would it be possible to update the docs on how to authenticate with GAR if its already possible
2. Could you add google artifact repository authentication for private repositories?

[PeterJCLaw]

How are you authenticating to GAR? If you've got e.g: a service account JSON credentials blob as a secret in GitHub then you can use that as the password and one of _json_key or _json_key_base64 as the username. (See the docs at https://cloud.google.com/artifact-registry/docs/python/authentication for general information).

The gotcha you may hit is that, depending on how you're authenticating locally, this may inject other urls into your requirements files (as I mention on https://github.com/dependabot/dependabot-core/issues/9171).

[mbrancato]

@PeterJCLaw static secrets overall are a poor security practice. For Google, they typically are long-lived JSON keys, and Google has a big warning explaining that users should not use static JSON keys. If lost or stole, they provide challengeless authentication.

Google's warning shown to all users in the cloud console when trying to create static keys: Service account keys could pose a security risk if compromised. We recommend you avoid downloading service account keys and instead use the Workload Identity Federation . Learn more about the best way to authenticate service accounts on Google Cloud .

Short lived keys, issued via federated authentication are the best solution between GitHub and Google. Specifically for Google, and generally applying to other major IaaS providers as well, they offer a decision tree on how to select authentication. Static keys are the absolute last resort. Google provides a federated authentication action just for this purpose. When setup properly, it requires and uses no static secrets.

[PeterJCLaw]

@mbrancato sure, though even following the diagram you linked to I think the answer is to use a service account key? (which is what I was suggesting) This is based on the limitation highlighted by this ticket -- that Dependabot does not offer federated identity. It seemed useful to highlight the potential workaround as well as to cross link the limitations I'd hit when trying to make that approach work.

[mbrancato]

@PeterJCLaw The solution is to use workload identity federation. That's basically what the OP is asking for - to add support for federation. Google supports this with the repo-scoped GitHub token via claim matching. But in general there is no way beyond static secrets to authenticate Dependabot currently to any private repo.