properly support CIDR syntax for insecure registries

[miabbott]

The --insecure-registry flag for dockerd supports the use of a CIDR syntax to indicate that any IPs in a range should be treated as insecure. From the dockerd documenation:

--insecure-registry 10.1.0.0/16 tells the Docker daemon that all registries whose domain
resolve to an IP address is part of the subnet described by the CIDR syntax,
should be considered insecure.

However, after discussing with @baude, it seems that crio, podman and the like do not support the CIDR syntax.

So I think registries and/or its consumers should support the CIDR syntax to offer parity with the Docker ecosystem.

Worth noting that I arrived at this issue because I tried to use oc cluster up on a host and it initially failed with the following error and provided a workaround:

-- Checking Docker daemon configuration ... FAIL                                                                                                                                                                   
   Error: did not detect an --insecure-registry argument on the Docker daemon                                                                                                                                      
   Solution:                                                                                                                                                                                                       
                                                                                                         
     Ensure that the Docker daemon is running with the following argument:                                                                                                                                         
        --insecure-registry 172.30.0.0/16                                

[rhatdan]

@mtrmac WDYT

[mtrmac]

I’m really not thrilled about the concept:

• It is ambiguous WRT DNS names which return multiple addresses
• The obvious way to implement this (like the one my old docker/docker checkout uses) is racy against a malicious DNS server
• (It makes it way too easy to be lazy and exempt the whole company network from TLS, while nowadays it’s implausible to assume that anything behind the external firewall is non-malicious.)

To implement this at least minimally correctly, the registry client would have to make a DNS lookup, make a secure/insecure decision based on the results, and then connect to the HTTP/HTTPS server based on the original DNS lookup without looking up the name again. I can’t immediately see an easy way to do that—the HTTP/HTTPS decision usually happens way before the DNS lookup or a TCP connection setup.

I think we could, easily and securely enough, support this only for registries specified by an IP address (i.e. only 10.1.1.1, not registry.my-internal-network.local resolving to 10.1.1.1). But would that be enough for oc cluster up etc.?

[miabbott]

I think we could, easily and securely enough, support this only for registries specified by an IP address (i.e. only 10.1.1.1, not registry.my-internal-network.local resolving to 10.1.1.1). But would that be enough for oc cluster up etc.?

To be honest, I don't know enough about the requirements for oc cluster up, but I'm told that @deads2k might be the right person to ask.

David, could you weigh in on the use of CIDR syntax for insecure registries and how that interacts with oc cluster up?

[deads2k]

David, could you weigh in on the use of CIDR syntax for insecure registries and how that interacts with oc cluster up?

oc cluster up pins the IP address of the internal registry. @mfojtik @csrwng

[csrwng]

@deads2k which means we could check whether that one IP is within the insecure range instead of checking the entire CIDR

[deads2k]

@deads2k which means we could check whether that one IP is within the insecure range instead of checking the entire CIDR

I think so, but I copied you because I don't know much about that check.

[csrwng]

@deads2k we currently get all insecure CIDRs from docker and check that the entire 172.30.0.0/16 range is covered by their aggregate. We could easily change that to a single IP check.

[mtrmac]

Actually configuring a CIDR block would not be an issue, as long as clients use an IP address to refer to the registry. Matching an IP against an IP, or against a CIDR range, is both semantically clean.

The difficulties arise when any DNS is involved (e.g. a configuration which sets up --insecure-registry=172.30.0.0/16 and then tries to pull from my-registry-service.local).

(And yes, this would mean that “the same” registry would be used differently depending on whether the user uses a name or an address.)