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

Defined notes for BSI SYS.1.6.A17 #12530

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please do not add the same content, which is already existing in other PRs / commits. just rebase on that branch or wait until the other branch is merged

Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@

title: Ensure that Sandboxed Containers Operator is Configured

description: |-
{{{ weblink(link="https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.7",
text="The Sandboxed Containers Operator") }}}
provides containers with a dedicated kernel by running them in a virtual machine. This allows for extended separation, as no kernel is shared. This is done by using RHCOS cluster extension and is only available on RHCOS nodes.

It is only active, if it is correctly configured with a KataConfig AND you configured each pod spec with <pre>runtimeClassName: kata</pre>.

Be advised, that on AWS, Azure, IBM Z and IBM LinuxOne you need to enable PeerPods and confiugre additional resources.

rationale: |-
Using separate kernels for each container provides for better isolation, and makes it harder for adveseries to move laterally to other containers or the container-host.

severity: medium

identifiers:
cce@ocp4: CCE-87430-5

ocil_clause: 'Sandboxed Containers Operator is not configured'

ocil: |-
Run the following command to check if a KataConfig for the cluster exists:
<pre>$ oc get kataconfigs openshift-sandboxed-containers-operator</pre>
Make sure at least one KataConfig exists.

warnings:
- general: |-
{{{ openshift_cluster_setting("/apis/kataconfiguration.openshift.io/v1/kataconfigs?limit=5") | indent(4) }}}

template:
name: yamlfile_value
vars:
ocp_data: "true"
filepath: /apis/kataconfiguration.openshift.io/v1/kataconfigs?limit=5
yamlpath: ".items[:].metadata.name"
entity_check: "at least one"
values:
- value: ".*"
operation: "pattern match"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please do not add the same content, which is already existing in other PRs / commits. just rebase on that branch or wait until the other branch is merged

Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@

title: Ensure that Sandboxed Containers Operator exists in the cluster

description: |-
{{{ weblink(link="https://docs.redhat.com/en/documentation/openshift_sandboxed_containers/1.7",
text="The Sandboxed Containers Operator") }}}
provides containers with a dedicated kernel by running them in a virtual machine. This allows for extended separation, as no kernel is shared. This is done by using RHCOS cluster extension and is only available on RHCOS nodes.

rationale: |-
Using separate kernels for each container provides for better isolation, and makes it harder for adveseries to move laterally to other containers or the container-host.

severity: medium

identifiers:
cce@ocp4: CCE-86496-7

ocil_clause: 'Sandboxed Containers Operator is not installed'

ocil: |-
Run the following command to check if a subscription for the operator exists in the system:
<pre>$ oc get sub -n openshift-sandboxed-containers-operator</pre>
Make sure the Sandboxed Containers Operator is installed.

warnings:
- general: |-
{{{ openshift_cluster_setting("/apis/operators.coreos.com/v1alpha1/subscriptions") | indent(4) }}}

template:
name: yamlfile_value
vars:
ocp_data: "true"
filepath: '/apis/operators.coreos.com/v1alpha1/subscriptions'
yamlpath: ".items[:].status.installedCSV"
check_existence: "at_least_one_exists"
values:
- value: "sandboxed-containers-operator.*"
operation: "pattern match"
entity_check: "at least one"
40 changes: 33 additions & 7 deletions controls/bsi_sys_1_6.yml
Original file line number Diff line number Diff line change
Expand Up @@ -429,17 +429,43 @@ controls:
levels:
- standard
description: >-
A container runtime and any instantiated containers SHOULD only be executed by a non-
(1) A container runtime and any instantiated containers SHOULD only be executed by a non-
privileged system account that does not have (and cannot gain) elevated rights to the
container service or host operating system. The container runtime SHOULD be encapsulated
container service or host operating system. (2) The container runtime SHOULD be encapsulated
by additional measures, such as using the virtualisation extensions of CPUs.
If containers are to take over tasks of the host system in exceptional cases, privileges on the
host system SHOULD be limited to the minimum necessary. Exceptions SHOULD be
(3) If containers are to take over tasks of the host system in exceptional cases, privileges on the
host system SHOULD be limited to the minimum necessary. (4)Exceptions SHOULD be
adequately documented.
notes: >-
ToDo
status: manual
#rules:
Section 1: With OpenShift, application containers run in the Security Context Constraint (SCC) “restricted” by default.
Section 2: 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.
Section 3: 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.
Section 4: 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.
status: partial
rules:
# Section 1 and 3
- scc_drop_container_capabilities
- scc_limit_container_allowed_capabilities
- scc_limit_host_dir_volume_plugin
- scc_limit_host_ports
- scc_limit_ipc_namespace
- scc_limit_net_raw_capability
- scc_limit_network_namespace
- scc_limit_privilege_escalation
- scc_limit_privileged_containers
- scc_limit_process_id_namespace
- scc_limit_root_containers
# Section 2
- sandboxed_containers_operator_exists
- sandboxed_containers_operator_configured

- id: SYS.1.6.A18
title: Application Services Accounts
Expand Down
Loading