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 0 forks source link

SYS.1.6.A3 #3

Open sluetze opened 10 months ago

sluetze commented 1 month ago

(1) For containerized IT systems, it MUST be taken into account how containerization affects the IT systems and applications being operated, in particular the administration and suitability of the applications.

This requirement must be implemented organizationally.

Note: This requirement is actively supported by OpenShift. For example, OpenShift does not allow applications with fixed UID/GID settings as standard; on the contrary, these IDs are assigned dynamically (security-by-design). The behavior can be adjusted by administrators, for example for system tasks.

(2) Based on the protection needs of the applications, it MUST be checked whether the requirements for isolation and encapsulation of the containerized IT systems and the virtual networks as well as the applications operated are sufficiently met.

This requirement must be implemented organizationally.

Note: OpenShift supports the requirements through strict client separation based on a “Project” (an extension to the Kubernetes namespace). The containers are separated from each other and from the host system via cgroups using SELinux. As long as all applications run “restricted” in the Security Context Constraint (SCC), OpenShift maintains strict client separation.

(3) The operating system's own mechanisms SHOULD be included in this test.

This requirement must be implemented organizationally.

OpenShift supports this requirement by leveraging SELinux with its cgroups to create the container sandbox.

(4) For virtual networks, the host performs the function of a network component. The building blocks of the sub-layers NET.1 networks and NET.3 network components MUST be taken into account accordingly.

This requirement must be implemented organizationally.

(5) Logical and overlay networks MUST also be considered and modeled.

This requirement must be implemented organizationally.

Note: OpenShift supports different network infrastructures via the CNI plugin interface (e.g. OVN-Kubernetes, OpenShift-SDN, hardware networks etc.) OVN-Kubernetes, OpenShift-SDN, hardware networks etc.) The underlying network is abstracted by the network model in Openshift and usage is consistent across containers. This allows OpenShift to uniformly implement network security features such as: Firewall rules over network policies.

(6) Furthermore, the containerized IT systems used MUST meet the requirements for availability and data throughput.

This requirement must be implemented organizationally.

Note: OpenShift provides fine-grained metrics for external capacity management via monitoring.

(7) During ongoing operations, the performance and condition of the containerized IT systems SHOULD be monitored (so-called health checks).

OpenShift offers automated checks for the availability and health of an application. If the LivenessProbe (Health) repeatedly receives a negative result or is not reachable, the affected pod with the container is restarted. Using ReadinessProbe, a container can control whether it is ready to accept HTTP(S) based requests or not.

Note: Monitoring is considered in APP.4.4.A11.

even though this is mostly organizational we might be able to add some checks.


# Section 2:
rules:
    - general_namespace_separation
    - general_node_separation
    - general_network_separation

# Section 3:
rules:
    - coreos_enable_selinux_kernel_argument
    - selinux_state
    - selinux_policytype
# Section 7
rules:
    - liveness_readiness_probe_in_workload