Security issue: Allow changing the default registry

[interone-ms]

Docker needs outbound internet access to operate. This is a security issue in corporate environments, as many do not allow outbound internet access at all on servers to prevent data exfiltration or to comply with auditing policies.

Why this is important

In case an attacker gains code execution in an environment where outbound access to the default docker registry, he can exfiltrate data by compacting the data into an "image layer" and upload said layer to the Docker registry using previously created credentials - no need to access the docker daemon itself, as requests can be manually crafted by the attacker.

Furthermore, allowing users to use a Nexus cache reduces their network usage as well as allows them to operate in network outage situations (e.g. when AWS or whatever the official Docker registry is using as host has issues), so this also has impact on corporate uptime requirements by eliminating external dependencies.

Also, using a cache-only registry proxy prevents accidental pushing of private images to the wide Internet.

How to fix

A company can mitigate this threat in theory by installing e.g. Sonatype Nexus in proxy mode and then setting the default registry, e.g. as proposed in the closed ticket #11815 (and implemented by RedHat in an experimental fork some time ago). This prevents data exfiltration and provides a caching layer.

I do understand the reason why this ticket was closed (namespace fragmentation), however this is not a sufficient excuse when corporate security policies / threat audits are in effect, and in corporate environments the people involved generally do have sufficient competence to avoid fragmentation.

Why I am asking for this in the "official" Docker repository is because some environments prefer to use Debian/Ubuntu instead of RedHat and thus cannot use the fork.

[sbrl]

Is there any word on this (@thaJeztah?)? As mentioned above, this is a huge security issue. Furthermore, some great arguments can be found in #11815.

It would appear that this glaring issue has been ignored.