Improve proxy documentation

[scoopex]

No description provided.

[berendt]

Remove this. We have a lot of scenarios where this makes no sense.

[scoopex]

Interesting. Can you provide more details?

[berendt]

Only add a sample IP range here that makes sense (e.g. the CIDR used inside the cluster).

[scoopex]

I also listed the three 3 RFC1981 ranges in the container and kubernetes section.

The motivation for listing all private networks was, that these networks or network areas are relatively rarely accessed via a proxy anyway.

Since both Docker itself and the services operated with it tend to use HTTP communication in private networks outside the Docker network but within the OSISM environment, we avoid the OSISM user getting into trouble in so many cases because he may not have thought of all potential networks at the time of configuration.

[berendt]

The intend of the proxy is the use in (semi) air-gapped environments. There we only want to exclude the internal network from the proxy. Everything else has to go through the proxy.

[scoopex]

Air-gapped environments are possible uses-cases, but I would assume that this is a rather exotic scenario.

It is probably more common for a proxy to be used for internet access because it offers the possibility to put domains on an allow list via patterns or even to use it as a caching proxy.
For security reasons, for example, you can configure the proxy to only allow the download artifacts from defined sources - e.g. this makes it more difficult for an attacker who has compromised an Openstack API service to download code from the network).

Both the nodes themselves and the networks used in Docker are RFC1918 networks. There is simply a risk that the user will not think of one or the other network or will create it later. With the proposal to generally exclude these networks, we probably avoid most of the typical problems for most users.

Due to the flexible configurability of OSISM, a more explicit configuration can be made later if necessary.