SYS.1.6.A16

[sluetze]

No description provided.

[sluetze]

Administrative access from a container to the container host and vice versa SHOULD in principle be viewed as administrative remote access.

Application containers can only access administrative services remotely. Privileged containers can gain access to the host, the host's file system, or the host's network. This is necessary, for example, for the infrastructure services of OpenShift (ingress router). Normal applications (application containers) may not receive such permissions.

There SHOULD NOT be remote administrative access to the container host from a container.

This requirement must be partially implemented organizationally and should be part of the guideline defined in SYS.1.6.A10. There may be exceptions for applications that should/need to make configurations to Kubernetes resources. This means they have administrative remote access to the corresponding Kubernetes resources. Remote access is controlled by Kubernetes and backup takes place via the Kubernetes functionalities (see module APP.4.4). The operating system including Mandatory Access Control is optimized as a runtime environment for Kubernetes. In general, it is possible to limit the provision/post-installation of remote access programs in the container.

Application containers SHOULD not contain any remote maintenance access.

This requirement should also be included in the policy described in SYS.1.6.A10. OpenShift only allows access to the configured ports. A container that provides remote maintenance access to these ports may not be released. Application containers should be administered exclusively via the container runtime. Using a policy, known remote access ports (e.g. 22, RDP, etc.) can be reported via ACS and their use prevented.

Administrative access to application containers SHOULD always take place via the container runtime.

This is standard in OpenShift environments. OpenShift offers a terminal login via the oc administration tool . Communication runs via the control plane to the container and is both authenticated and authorized.

[lichtblaugue]

Is this requirement to be implemented organizationally?

[sluetze]

the only thing I see, which could be checked is:
.spec.containers.ports (https://kubernetes.io/docs/concepts/services-networking/service/#field-spec-ports) and match if they expose well known remote administration ports (like 22, RDP etc.).

But I do not see much value in it, since per default a pod wont be allowed to expose ports <1024 anyway because they need root permissions to do so (if my understanding is correct here). Someone who wants to expose SSH for example will do it on a custom port anyway (like 2222). So there is already a technical feature which contradicts the possible check.

One COULD guess, which >1024 ports are commonly used, but this might trigger many false-positives and few true-positives

[benruland]

I also see it mostly as an organizational implementation.

Section 2 could be checked with SCC-rules such as scc_limit_host_dir_volume_plugin, scc_limit_container_allowed_capabilities, scc_limit_privilege_escalation, ... -> These are effectively required for host access from a container.

Maybe we can also note, that container runtime security tools can detect, alert and remediate, if remote access daemon processes such as SSHd are running in a container.