Loading today’s stories
Security1 distinct publisher3 min readUpdated
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
Compiled by The WatchSomething wrong?How this is made
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.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
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.
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.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
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.
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.
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.
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.
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.
invest
H100 rentals are back to $2.35 an hour, and your AI cost model is stale1 distinct publisher
invest
Rust's arrayref hijack lasted 86 minutes, and Wiz ties it to North Korea1 distinct publisher
product
Pearson's inversion: in learning products, the correct answer can be the product failure1 distinct publisher
build
Agent-written docs need a paper trail, not a confidence score1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 12, 2026