Honest question, but why can't docker use something like bittorrent to download images?
Most of us download our OS via torrents only, so we may as well download the images too if there was support for it.
Most of us download our OS via torrents only, so we may as well download the images too if there was support for it.
I mean, I only do it to stick it to the people who claim torrents can only be used for piracy; I think most people prefer the simplicity of direct downloads though…
Afaik Windows is also using this to install updates where it shares the download with others in the region (1) using p2p (though i may be wrong since i don't use Windows anymore)
(1) https://www.itproportal.com/amp/news/how-to-stop-windows-10-...
In fact, there already exist several implementations of it for Docker![0, 1, 2]
Docker will be limiting manifest operations, not actual blob transmissions.
- There is no rate limiting for paid accounts or companies from what I see in the article.
For your own company, you'd host a swarm that is firewalled in. Then when someone says "I want image xyz" the first thing you do is look for seeders in the swarm for that file. If non exists, then you initiate an http download from docker to get the image.
Now you've got fast distribution with low external network traffic.
Not sure how this would play with Cloud provider pricing, though. I don't believe AWS would be too happy seeing their services turned into BT swarms :)
1. Only some companies work like that.
2. I'd expect it to work like a webtorrent; try to download by p2p, but if that fails then fall back to HTTP.
Google Cloud uses an adjacent feature called binary authorization. When turned on, only images that are signed by a given authority (usually your ci/cd instruments) can be run inside your Kubernetes cluster.
Binary authorization may be a good starting point for someone trying to make bittorrent distributed images a usable thing.
That's exactly what Bittorrent does with its hash tree. You'd get the root hash (extremely tiny) from Docker Hub, and the rest of the metadata, as well as the data blocks, from the swarm. The authenticity is all handled by the TLS that serves you the root infohash from Docker Hub. It's a Merkle tree: the root hash is for the metadata, which is a list of hashes of the blocks.
You get the hash of the final result from the trusted server and hash is checked. Because of this you will never get an invalid image.
There are also some clever tricks to make sure no one can force you to start over from scratch by sending wrong data. But that's more of a detail.
When the backdoor is detected, you now need a revocation system so the distribution of the malicious image will die. You can theoretically do this on the tracker level, but people may build other trackers that may not propagate the changes.