SYS.1.6.A5

[sluetze]

The networks for the administration of the host, the administration of the containers and their access networks MUST be separated appropriately to the protection requirements.

Hosts and containers are controlled via the Kubernetes API. This is addressed via api.. The load balancer used for this is located in the administration network. The load balancer for *.apps. is set up separately in the active network. This means that the administration is appropriately separated.

The Console (the OpenShift web UI) is used by all users. Authorization takes place at the API level and is secured via RBAC.

The control plane is to be located in an administration network.

In principle, at least, administration of the host SHOULD only be possible from the administration network.

The web UI can be configured on another router that is terminated on the administration load balancer and is therefore only accessible from the administration network. This means that it can no longer be reached from the active network.

Only the communication relationships necessary for operation SHOULD be permitted.

This is a standard OpenShift feature. The OpenShift documentation [OpenShiftDocs] contains the necessary communication paths between control plane, infrastructure and worker nodes, as well as the necessary firewall activations of the underlying network stack at hardware or IaaS level. The communication between containers or pods within a client (“Project”) is not restricted by default, but can be regulated with micro-segmentation if necessary or as a service mesh with mTLS authentication be implemented (see APP.4.4.A18).

Externally exposed services can receive their own IP and thus data traffic can also be separated outside the platform. Inter-node communication is carried out via suitable tunnel protocols (VXLAN, GENEVE) and can also be encrypted using IPSec.

[sluetze]

rules:
      # Section 1,2
      - general_network_separation
      # Section 3
      - configure_network_policies
      - configure_network_policies_namespaces

@benruland @lichtblaugue not sure here, if we should introduce a rule to check for separation of ingresscontrollers at Section 1 or if I am taking it to far.

on could check with rules:

• more than 1 ingresscontroller defined
• 1 ingresscontroller NOT in hostnetwork (which is the admin network)
• console routes not on the same ingresscontroller as a workload route (how to determine one!?)

but I am not sure, if this is over the top for this.

[sluetze]

another thing that @lichtblaugue said in a mail thread regarding this: Even if we have a check, which is checking for multiple ingresscontrollers, we would have no way to determine if this ingressoncontrollers are existing for the network separation usecase.

They might exist for sharding/workload distribution or other usecases. So a check, which checks for multiple ingresses would be prone to false negatives/false positives due to this or would be very complex (calculating ip subnets to ensure the ICs are in different subnets and so on, and even this would not guarantee, that these subnets are flagged for different usage).