Plans to add Google Cloud Artifact Registry support for the recently announced Dependabot OIDC authentication?

[lguida-nasdaq]

Select Topic Area

Question

Body

On the announcement of OIDC support in dependabot (https://github.blog/changelog/2026-02-03-dependabot-now-supports-oidc-authentication/), I noticed only AWS, Azure and Jfrog repositories were supported. I wonder what about Google Cloud Artifact Registry?

[midiakiasat]

Today Dependabot OIDC auth is only supported for registries hosted on AWS CodeArtifact, Azure DevOps Artifacts, and JFrog Artifactory Google Cloud Artifact Registry isn’t listed/supported.

• No, GAR isn’t supported for Dependabot OIDC right now.
• No public ETA/roadmap is stated in the announcement/docs.
• Workaround: keep using static credentials for GAR in dependabot.yml (token/service-account based auth), or run an external process to rotate/update credentials until GAR is supported.

[dbuzatto]

Hi
It’s a good observation that Google Cloud Artifact Registry was not listed in the initial Dependabot OIDC announcement.

Current OIDC support status

As of the official Dependabot documentation and the GitHub changelog, OIDC authentication for Dependabot is currently documented only for the following private registry providers:

• AWS CodeArtifact
• Azure DevOps Artifacts
• JFrog Artifactory

These are the only providers explicitly supported for OIDC authentication in the current docs. :contentReference[oaicite:0]{index=0}

The documentation states that Dependabot can use OIDC to authenticate with private registries that use username/password authentication, but the only supported hosted providers listed are the ones above. :contentReference[oaicite:1]{index=1}

What that means for Google Cloud Artifact Registry

At this time there is no official support listed for using Dependabot OIDC authentication with Google Cloud Artifact Registry (GAR). The current options remain:

• Using traditional authentication (static tokens or service keys stored as Dependabot secrets)
• Running Dependabot on self-hosted runners with custom authentication flows (e.g., setting up the runner to authenticate using Workload Identity Federation or other GCP mechanisms, and then letting Dependabot use local credentials)
• Waiting for official support if and when GitHub extends OIDC support to additional providers

Google Cloud itself supports Workload Identity Federation and OIDC token flows for accessing Artifact Registry in general, but that does not automatically translate into Dependabot support without specific integration in Dependabot. :contentReference[oaicite:2]{index=2}

Why this might be the case

The initial rollout of OIDC for Dependabot clearly focused on providers with the broadest enterprise usage and existing integration patterns (AWS, Azure, JFrog). GitHub’s implementation appears to require provider-specific parameter support in the Dependabot configuration (tenant-id, client-id, etc.), which may not yet exist for other clouds. :contentReference[oaicite:3]{index=3}

There’s also discussion in the Dependabot repo about extending custom auth flows and OIDC support more broadly, but nothing official has landed for GAR yet. :contentReference[oaicite:4]{index=4}

Practical recommendations

• If you need to use Dependabot with Google Cloud Artifact Registry today, you’ll likely need to authenticate via Dependabot secrets or run Dependabot on a self-hosted runner configured to handle GCP authentication.
• For projects requiring OIDC directly, consider raising feedback in the Dependabot community or GitHub’s feature request channels to signal demand for Artifact Registry support.

Hope this helps clarify the current state of support.

[krillmango]

more power to google. what could go wrong