search

sig-bsi-grundschutz / content

Security automation content in SCAP, Bash, Ansible, and other formats
https://www.open-scap.org/security-policies/scap-security-guide
Other
7 stars 1 forks source link

SYS.1.6.A17 #17

Open sluetze opened 11 months ago

sluetze commented 3 months ago

The container runtime and all instantiated containers SHOULD only be run by a non-privileged system account that does not have or can obtain elevated rights to the container service or the host system's operating system.

With OpenShift, application containers run in the Security Context Constraint (SCC) “restricted” by default.

The container runtime SHOULD be encapsulated through additional measures, such as using CPU virtualization extensions.

OpenShift supports encapsulation by using SELinux. If necessary, entire nodes can also be encapsulated via underlying virtualization. This is always necessary when application containers require extended security context constraints (SCCs).

With the sandbox function based on Kata Containers, OpenShift provides a convenient way to isolate containers using virtualization technology.

If containers are to take over tasks of the host system in exceptional cases, the privileges on the host system SHOULD be limited to the necessary minimum.

OpenShift offers several SCC to restrict access to the network, file system or the host itself. This should only be allowed for administrative applications such as SIEM scanners or other infrastructure services that require access to the host. These SCCs should never be given to application containers.

Exceptions SHOULD be appropriately documented.

These exceptions must be documented in the operational documentation. A list of pods with the corresponding SCC annotation can serve as the basis for the documentation.