Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SYS.1.6.A17 #17

Open
sluetze opened this issue Nov 7, 2023 · 1 comment
Open

SYS.1.6.A17 #17

sluetze opened this issue Nov 7, 2023 · 1 comment
Assignees

Comments

@sluetze
Copy link

sluetze commented Nov 7, 2023

No description provided.

@sluetze
Copy link
Author

sluetze commented Jul 17, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

2 participants