Security 1 publisher3 min readPublished Aug 15, 2026, 6:16 AM PDT

Artifact Registry's Connector mode puts Artifactory on the pull path for GKE and Cloud Run

Google's new passthrough repository mode keeps no image copy, so every pull goes live to JFrog. That shifts the provenance boundary and parks a registry credential in Secret Manager.

The Watch · Security desk

Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AI Send a correction

What happened

Google Artifact Registry has introduced a new repository mode called Connector.
The Artifact Registry Connector acts as a passthrough proxy for private container registries such as JFrog Artifactory; every image request made through a Connector repository is forwarded in real time to the upstream private registry, and no copy of the image is stored in Google Artifact Registry.
JFrog says the missing piece had been getting Google Cloud runtime services such as Cloud Run and GKE to pull directly from JFrog for every container image pull, and that the gap is now closed.
The Connector must point to an existing Docker registry; JFrog highly recommends creating a dedicated virtual Docker repository, implying a unique URL, per Artifact Registry Connector, which it says greatly helps monitoring, auditing and managing usage contexts.
Artifact Registry needs a JFrog access token to pull images from JFrog, stored in a Google managed secret in Google Secret Manager; the two options are the recommended auto-rotating secret created per the instructions in the JFrog GCP Secret Rotator repository, or simply creating a new secret containing an access token to the JFrog Docker repository.

Compiled by The WatchSomething wrong?How this is made

Why it matters

Google Artifact Registry has added a repository mode called Connector, which acts as a passthrough proxy to a private registry such as JFrog Artifactory and stores no copy of the image in Artifact Registry itself ^[1]^[2]. According to JFrog, which announced the integration on its own blog, this closes the gap that previously stopped Cloud Run and GKE from pulling directly from Artifactory on every image pull ^[3]^[10].

The mechanics are short. You point the Connector at an existing JFrog Docker registry URL, in the form https://my-name.jfrog.io/docker, and attach credentials ^[6]. Artifact Registry needs a JFrog access token to do the pull, and that token lives in a Google-managed secret in Secret Manager; JFrog recommends an auto-rotating secret built from the instructions in its GCP Secret Rotator repository, with a plain static secret as the alternative ^[5]. Workloads then reference the Connector repository exactly as they would any other Artifact Registry repository ^[7]. JFrog also recommends a dedicated virtual Docker repository, and therefore a unique URL, per Connector, for monitoring, auditing and separating usage contexts ^[4].

What changes operationally is the failure and trust surface, not the deployment YAML. Because nothing is cached in Artifact Registry and every request is forwarded live, Artifactory availability and latency become part of the pull path for any workload that scales up, reschedules, or restarts ^[2]^[8]^[12]. JFrog states this plainly as the point: Artifactory serves the image and applies active policy at the moment of the request, and can block a pull immediately if an image has been flagged for a newly discovered critical CVE, even one that previously passed every check ^[8]. That is a real control, and it is also a new way for a running service to stop being able to start new instances. Teams that treat a mirrored registry as a shock absorber lose the absorber here ^[2]^[9].

The credential boundary moves as well. A JFrog access token with read access to a Docker repository now sits in Google Secret Manager and is consumed by a Google-managed service on behalf of your projects ^[5]^[13]. Anyone modelling blast radius should treat that secret as a registry credential of record, which is the reason the auto-rotation option and the one-virtual-repo-per-Connector advice are worth following rather than skipping ^[4]^[5]. Scoping the upstream repository narrowly is the only lever that limits what a leaked token can read ^[4]^[13].

What to watch: JFrog's post does not state the availability or launch stage of Connector mode, pricing or egress implications, added pull latency, request quotas, regional coverage, or how Artifact Registry side features behave when no copy of the artifact exists ^[11]. Those are the details that decide whether this is production-safe for a large GKE fleet, and they belong in Google's own documentation rather than a partner announcement ^[10]^[11]. Until then, test the obvious case before committing: block an image in Artifactory, then force a pod restart, and see what your cluster does.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
Google Artifact Registry has introduced a new repository mode called Connector.
ReportedSupportedSource: JFrog blog postView cited source
[2]
The Artifact Registry Connector acts as a passthrough proxy for private container registries such as JFrog Artifactory; every image request made through a Connector repository is forwarded in real time to the upstream private registry, and no copy of the image is stored in Google Artifact Registry.
ReportedSupportedSource: JFrog blog postView cited source
[3]
JFrog says the missing piece had been getting Google Cloud runtime services such as Cloud Run and GKE to pull directly from JFrog for every container image pull, and that the gap is now closed.
ReportedSupportedSource: JFrog blog postView cited source
[4]
The Connector must point to an existing Docker registry; JFrog highly recommends creating a dedicated virtual Docker repository, implying a unique URL, per Artifact Registry Connector, which it says greatly helps monitoring, auditing and managing usage contexts.
ReportedSupportedSource: JFrog blog postView cited source
[5]
Artifact Registry needs a JFrog access token to pull images from JFrog, stored in a Google managed secret in Google Secret Manager; the two options are the recommended auto-rotating secret created per the instructions in the JFrog GCP Secret Rotator repository, or simply creating a new secret containing an access token to the JFrog Docker repository.
ReportedSupportedSource: JFrog blog postView cited source
[6]
Configuration involves creating a new Artifact Registry repository of mode Connector, specifying the JFrog container registry URL in the format https://my-name.jfrog.io/docker as the Connector repository source, and configuring authentication credentials using the previously created secret.
ReportedSupportedSource: JFrog blog postView cited source
[7]
A Cloud Run service or GKE deployment is configured to pull container images from the Connector repository the same way it would reference any other Artifact Registry repository.
ReportedSupportedSource: JFrog blog postView cited source
[8]
When Cloud Run or GKE requests an image, the Connector forwards the request to JFrog Artifactory in real time with no copy created or stored in Artifact Registry; Artifactory serves the image and applies active security policies at the moment of the request, and if an image has been flagged due to a newly discovered critical CVE, Artifactory can block that pull immediately, even for images that previously passed all checks.
ReportedSupportedSource: JFrog blog postView cited source
[9]
JFrog frames the passthrough-only design as ensuring Artifactory remains the single source of truth for every container image, with no intermediate copy and no gap in policy enforcement, and without a copy stored in Artifact Registry operating outside that governance model.
ReportedSupportedSource: JFrog blog postView cited source
[10]
The only source for this account is a post published on jfrog.com by JFrog describing the integration.
ReportedSupportedSource: jfrog.comView cited source
[11]
The JFrog post describes the Connector concept and the setup and pull flow, but does not state a launch stage or availability status, pricing or egress implications, added pull latency, request quotas, regional coverage, or how Artifact Registry side features behave when no copy of the artifact is stored.
ReportedSupportedSource: JFrog blog postView cited source
[12]
Because no image copy is stored in Artifact Registry and every pull is forwarded live to Artifactory, Artifactory availability and response time are required at the moment of each image pull, including pulls triggered by scale-up, rescheduling or restart.
DerivedSupported2 sources— create a free account to open them
[13]
A JFrog access token with read access to the upstream Docker repository is held in Google Secret Manager and used by Artifact Registry to perform pulls, so the scope of that upstream repository bounds what the token can read.
DerivedSupported1 source— create a free account to open them

Sources

Publishers whose own reporting we read for this story.

jfrog.com
1 article · August 12, 2026
JFrog Artifactory Now Integrates Natively with Artifact Registry in Google Cloud

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Builder

For builders the cluster reads as a concrete integration recipe: create (ideally a dedicated virtual) JFrog Docker repository, put an access token in Google Secret Manager - preferably auto-rotating via the JFrog GCP Secret Rotator - create an Artifact Registry repository of mode Connector pointed at https://my-name.jfrog.io/docker, then reference it from Cloud Run or GKE like any other Artifact Registry repository. What is absent is everything needed to size the change: no launch stage, no latency figures, no quotas, no regional coverage, and no statement of how Artifact Registry features that assume a stored artifact behave when nothing is stored.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence40: 0100
First-party mechanism detail, no external corroboration
The mechanism is described in unusual procedural detail by a party with direct knowledge - repository mode, upstream URL format, Secret Manager token options, pull-forwarding flow and pull-time policy evaluation - which makes the how credible. But the cluster contains exactly one item, authored by the vendor that benefits, with no Google documentation, changelog or third-party confirmation, and the post omits the parameters that would let a reader verify or bound the behaviour.
AdoptionInsufficient: No adoption signal beyond the announcement
The only observation is the vendor's own announcement post. It names no customers, discloses no usage, gives no launch stage or availability status, and there is no deployment, benchmark or pricing datapoint in the cluster, so adoption cannot be measured without inventing facts.
Hype gap+32: −100 understated0 aligned+100 overstated
Benefit framing runs ahead of stated operating limits
The post declares the gap 'now closed' and the design free of 'architectural tradeoffs' while omitting the tradeoffs the same mechanism creates: Artifactory becomes a hard dependency on every pull path, and latency, availability behaviour, pricing/egress, quotas, regional coverage and launch stage are all unstated. The mechanism claims themselves are plausible and specific, so the gap is moderate overstatement of certainty and completeness rather than fabrication.
Incentives88: 0100
Vendor announcing its own integration
The sole source is JFrog's own blog, written in the first person, announcing an integration that places JFrog Artifactory on the pull path for Google Cloud runtimes and explicitly displacing workarounds that let teams operate without Artifactory in that path. It appeals to 'joint customers' and 'enterprise customers', which is commercial positioning; no adversarial or independent voice appears in the cluster.
Confidence44: 0100
Mechanics likely right, scope and limits unknown
Confidence is moderate on how the Connector mode works and how it is wired, because the account is first-party, internally consistent and procedurally specific. It is low on whether the mode is generally available, what it costs, how it performs, where it runs, and how Artifact Registry features degrade with no stored copy - none of which the single interested source addresses.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Container Registry ProxyingFollow
Secrets and Credential ManagementFollow
Software Supply Chain GovernanceFollow
Google Cloud Runtime PlatformFollow

Entities

JFrog Follow
Google Artifact RegistryFollow
Artifact Registry ConnectorFollow
Google Secret ManagerFollow
Cloud Run Follow
Google Cloud Follow
Google Kubernetes Engine Follow
JFrog GCP Secret RotatorFollow
Artifactory Follow

Artifact Registry's Connector mode puts Artifactory on the pull path for GKE and Cloud Run

What happened

Why it matters

Claim ledger

Sources

Topics and entities

Topics

Entities

Claim ledger

Topics and entities

Topics

Entities

Perspective Coverage

Builder

Operator

Investor

Reality

Sources

What happened

Why it matters

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Builder

Operator

Investor

Reality

Sources

Related stories