{"id": "bsi_sys_1_6", "policy": "BSI-SYS-1-6", "title": "SYS.1.6 Containerisation", "source": "https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi_it_gs_comp_2022.pdf", "definition_location": "/aptdata/openscap/scap-security-guide/controls/bsi_sys_1_6.yml", "controls": [{"id": "SYS.1.6.A1", "levels": ["basic"], "notes": "This requirement must be implemented organizationally. OpenShift supports all of the goals mentioned. Comprehensive handouts are available to carry out and document the planning of container use, security and compliance, architecture and installation on OpenShift (see https://www.redhat.com/en/resources/openshift-security-guide-ebook)", "title": "Planning Container Use", "description": "(1) Before containers are deployed, the goal of such a deployment (e.g. scaling, availability, disposable containers for safety or CI/CD) SHOULD be determined so that all the security- related aspects of installation, operation, and decommissioning can be planned. (2) The planning SHOULD also take into account the operational overhead resulting from container deployment or mixed operation. (3) The planning MUST be adequately documented", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A2", "levels": ["basic"], "notes": "This requirement must be implemented organizationally. Through OpenShift GitOps, OpenShift technically supports this requirement with a standardized approach to deployment, change handling and deprovisioning via kustomize or Helm charts. OpenShift provides further support through operator-based applications and platform management that automates the processes of commissioning, decommissioning and updates.\nSection 4: Start, stop and monitoring is a basic function of OpenShift. It is not possible to bypass the OpenShift methods to start and stop without manually connecting to a Container Host. For monitoring purposes, OpenShift itself offers Prometheus-based monitoring. Using Advanced Cluster Security for Kubernetes (ACS), policy-based rules can also be used to monitor the containers.", "title": "Container Management Planning", "description": "(1) The management of containers MUST ONLY be carried out in line with appropriate planning. (2) This planning MUST cover the entire lifecycle from commissioning to decommissioning, including operation and updates. (3) When planning container management, it MUST be taken into account that the creator of a container is to be considered like an administrator due to the effects they have on parts of the operation. (4) Containers MUST be started, stopped, and monitored via the management software used.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A3", "levels": ["basic"], "notes": "Section 1: 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.\nSection 2: This requirement must be implemented organizationally. Note: OpenShift supports the requirements through strict client separation based on a \u201cProject\u201d (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 \u201crestricted\u201d in the Security Context Constraint (SCC), OpenShift maintains strict client separation.\nSection 3: This requirement must be implemented organizationally. OpenShift supports this requirement by leveraging SELinux with its cgroups to create the container sandbox.\nSection 4: This requirement must be implemented organizationally.\nSection 5: 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, 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.\nSection 6: This requirement must be implemented organizationally. Note: OpenShift provides fine-grained metrics for external capacity management via monitoring.\nSection 7: 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.", "title": "Secure Use of Containerised IT Systems", "description": "(1) In the case of containerised IT systems, consideration MUST be given to how containerisation affects the IT systems and applications operated, in particular the management and suitability of the applications. (2) Based on the protection needs of the applications, it MUST be checked whether the requirements for isolation and encapsulation of the containerised IT systems, virtual networks, and operated applications are sufficiently fulfilled. (3) The mechanisms of the operating system in question SHOULD be included in this check. (4) Since the host performs the function of a network component for virtual networks, the modules of the sub-layers NET.1 Networks and NET.3 Network Components MUST be considered accordingly. (5) Logical and overlay networks MUST also be considered and modelled. (6) Furthermore, the containerised IT systems used MUST meet the requirements at hand regarding availability and data throughput.(7) During operation, the performance and the state of the containerised IT systems SHOULD be monitored (health checks).", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": ["selinux_policytype", "selinux_state", "coreos_enable_selinux_kernel_argument"], "controls": []}, {"id": "SYS.1.6.A4", "levels": ["basic"], "notes": "This requirement must be implemented organizationally. Note: OpenShift supports the requirement through the built-in functionalities and enables the highest possible level of automation. On the one hand, CI/CD tools are delivered with OpenShift pipelines and integrated into the platform. On the other hand, pre-configured build processes based on Red Hat experience are available that are based on Source2Image and thus support planning. The built-in registry allows you to store images and other associated information, such as Helm charts or SBOMs. The abstractions available in Openshift allow the entire image distribution process to be documented and controlled as code. This further allows the image distribution process to be managed via OpenShift GitOps.", "title": "Planning the Provision and Distribution of Images", "description": "The process for the provision and distribution of images MUST be planned and appropriately documented.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A5", "levels": ["basic"], "notes": "Section 1: Hosts and containers are controlled via the Kubernetes API. This is addressed via api. The load balancer used for this is located in the administration network. The load balancer for *.apps. is set up separately in the active network. This means that the administration is appropriately separated. The Console (the OpenShift web UI) is used by all users. Authorization takes place at the API level and is secured via RBAC. The control plane is to be located in an administration network.\nSection 2: The web UI can be configured on another router that is terminated on the administration load balancer and is therefore only accessible from the administration network. This means that it can no longer be reached from the active network.\nSection 3: This is a standard OpenShift feature. The OpenShift documentation contains the necessary communication paths between control plane, infrastructure and worker nodes, as well as the necessary firewall activations of the underlying network stack at hardware or IaaS level. The communication between containers or pods within a client (\u201cProject\u201d) is not restricted by default, but can be regulated with micro-segmentation if necessary or as a service mesh with mTLS authentication be implemented (see APP.4.4.A18).\nExternally exposed services can receive their own IP and thus data traffic can also be separated outside the platform. Inter-node communication is carried out via suitable tunnel protocols (VXLAN, GENEVE) and can also be encrypted using IPSec.", "title": "Separation of Administration and Access Networks for Containers", "description": "(1) Networks for the administration of the host, the administration of the containers, and their access networks MUST be separated according to the protection needs at hand. (2) In principle, at least the administration of the host SHOULD only be possible from the administration network. (3) Only the communication relationships necessary for operation SHOULD be allowed.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": ["service_firewalld_enabled"], "controls": []}, {"id": "SYS.1.6.A6", "levels": ["basic"], "notes": "Section 1: This requirement must be implemented organizationally. Note: OpenShift supports the requirement by allowing only certain sources. This allows the sources from which images come to be restricted and new sources to be added in a controlled process. Quay can also be used to provide your own registry in an open environment as a trustworthy delivery point for external software. Images can also be checked for vulnerabilities here.\nSection 2: This requirement must be implemented organizationally. Note: OpenShift makes it possible to verify the signatures of images before use and thus enforce the identification requirement. Red Hat Advanced Cluster Security for Kubernetes (ACS) can check and optionally enforce signatures as well as certain labels (e.g. MAINTAINER) for images. For images delivered by Red Hat via the official Red Hat Registry, the MAINTAINER label of the container images is always maintained, through which Red Hat can be identified as the creator of the images. Images are also signed with GPG keys.\nSection 3: This requirement must be implemented organizationally. Note: Images from the Red Hat Registry are regularly checked for security vulnerabilities and updated accordingly. The security status of the images is indicated via a health indicator. ACS can perform technical checks through regular scans and report conspicuous containers or containers with identified vulnerabilities, thereby supporting the implementation of the requirement.\nSection 4: This requirement must be implemented organizationally. Note: For discontinued images with appropriate identification (e.g. through labels), policies implemented in ACS can report these violations. ACS also provides policies that report when images have not been scanned for more than 30/60/90 days. However, this means that an image must be built and rolled out at this interval so that the scans during the build process are effective. With a CI/CD pipeline with a high level of automation, this usually does not represent any increased effort.\nSection 5: This requirement must be implemented organizationally. Note: Image-level labels or image tags could be used here.\nSection 6: This requirement must be implemented organizationally for integrated software or self-created software. Note: OpenShift supports Lifecycle Management (OLM) with Operator. Software managed using OLM or Cluster Operator receives updates via the Operator Hub or Cluster Updates. An automated check with automatic or alternatively manual release is possible for this software.", "title": "Use of Secure Images", "description": "(1) It MUST be ensured that all images used originate from trusted sources. (2) The creator of each image MUST be clearly identifiable. (3) Sources MUST be selected on the basis of whether the creator of a given image regularly checks the included software for security problems, fixes and documents them, and provides corresponding guarantees to customers. (4) The utilised version of base images MUST NOT be deprecated. (5) Unique version numbers MUST be provided. (6) If an image with a newer version number is available, a patch and change management process MUST check whether and how it can be rolled out", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A7", "levels": ["basic"], "notes": "OpenShift Logging stores the containers' logging data in a separate log management system. The output of the container is saved as long as it is on STDOUT and STDERR. The logging data can also be forwarded to different log storage depending on the source (e.g. infrastructure or application). It is the responsibility of the applications to write log output to STDOUT and errors to STDERR.", "title": "Persistence of Container Logging Data", "description": "Container logging data MUST be stored outside of the respective container (on the container host at minimum)", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A8", "levels": ["basic"], "notes": "Section 1: OpenShift offers secrets that are only available to the containers and the people authorized via RBAC in the tenant or project (client). Section 2: This requirement must be enforced as part of application development. OpenShift offers suitable mechanisms (secrets) with encryption of the etcd store if necessary. Section 3: OpenShift offers corresponding mechanisms (secrets). Unless the secrets are dynamically generated, third-party/community tools such as SealedSecrets or HashiCorp Vault can help securely deploy the secrets. Section 4: This requirement must be implemented organizationally. All of this information can and should be managed in Secrets.", "title": "Secure Storage of Container Access Data", "description": "(1) Access data MUST be stored and managed in such a way that only authorised persons and containers can access it. (2) In particular, it MUST be ensured that access data is only stored in specially protected locations and not in images. (3) The access data management mechanisms provided by container service management software SHOULD be used. (4) At minimum, the following credentials MUST be stored securely: \u2022 Passwords of any accounts \u2022 API keys for services used by the application \u2022 Keys for symmetric encryption \u2022 Private keys for public key authentication", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A9", "levels": ["standard"], "notes": "Section 1: This requirement must be implemented organizationally. Section 2: This requirement must be implemented organizationally and be part of the application development process. Section 3: This requirement must be implemented organizationally and suppliers must be contractually obliged to comply.", "title": "Suitability for Container Operation", "description": "(1) An application or service to be operated in a container SHOULD be suitable for such operation. (2) It SHOULD be considered that containers can often be terminated unexpectedly, with corresponding consequences for the application run therein. (3) The results of the checking described under SYS.1.6.A3 Secure Use of Containerised IT Systems SHOULD be documented in a comprehensible manner.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A10", "levels": ["standard"], "notes": "These requirements must be implemented organizationally.", "title": "Policy for Images and Container Operation", "description": "(1) A policy SHOULD be established and applied that specifies the requirements for container operation and permitted images. (2) The policy SHOULD also include requirements for the operation and deployment of images.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A11", "levels": ["standard"], "notes": "This requirement must be implemented organizationally.", "title": "Only One Service per Container", "description": "(1) Each container SHOULD only provide one service at a time.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A12", "levels": ["standard"], "notes": "Section 1: The source of images can be restricted by configuring the allowed registries. In addition, this requirement must be implemented organizationally. Section 2: This requirement must be implemented organizationally. Section 3: This requirement is solved using image labels. Red Hat Images contain the labels io.k8s.description, summary, vender, version, url, vcs-ref and vcs-type, through which the delivered images are transparent in their function and history. For internal images, the existence of the labels can be ensured during application development. The existence of the corresponding labels can be ensured via ACS. Section 4: OpenShift can be configured to assign a digital signature to each approved registry. OpenShift then only executes images from this registry that are secured using this signature.", "title": "Distribution of Secure Images", "description": "(1) The sources of images that have been classified as trusted and SHOULD be adequately documented along with the corresponding reasons. (2) In addition, the process of how images or the software components contained in an image are obtained from trusted sources and eventually deployed to a productive environment SHOULD be adequately documented. (3) Images used SHOULD have metadata that makes their function and history traceable. (4) Digital signatures SHOULD secure each image against modification.", "rationale": null, "automated": "no", "status": "partial", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A13", "levels": ["standard"], "notes": "This requirement must be solved organizationally. Note: OpenShift offers various CI/CD solutions that can be used for automation. OpenShift Pipelines (Tekton-based) and traditional Jenkins are available directly in OpenShift. If the user uses gitlab-ci or github Actions, the runners can be executed in OpenShift. If the release process contains specific artifacts such as if you require SBOMs or the ability to statically analyze Dockerfiles, Quay and ACS can provide the necessary functionality.", "title": "Release of Images", "description": "All images for productive operation SHOULD undergo a test and release process in the same way as software products in accordance with module OPS.1.1.6 Software Tests and Approvals", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A14", "levels": ["standard"], "notes": "Section 1: This requirement must be solved organizationally. Best practices use multiple environments (either separate clusters or multiple namespaces on a cluster) to support this process and enable automated testing (e.g. via OpenShift Pipelines or Jenkins ). Section 2: \u201cPersistent\u201d containers contradict the cloud native principle and do not represent \u201cgood practice\u201d. There is also a contradiction with APP.4.4.A21 \u201cRegular restart of pods\u201d. Accordingly, OpenShift does not support updates at the container level. Changes to the container image always result in the pod stopping and a new pod being restarted. With the recommended use of GitOps, this is a reprovisioning of the changed elements and also documents the status of the application at a given point in time. Due to the high level of automation, this usually does not represent any increased effort.", "title": "Updating Images", "description": "(1)When establishing a concept for patch and change management according to OPS.1.1.3 Patch and Change Management, it SHOULD be decided when and how the updates of images or the software or service operated are to be rolled out. (2)For persistent containers, checks SHOULD be made as to whether an update of a container is more appropriate than completely re- provisioning the container in exceptional cases.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A15", "levels": ["standard"], "notes": "Section 1: OpenShift supports the configuration of quotas for a project (client). Applications can have their resources appropriately limited using limits/requests. Network bandwidth is limited at the pod level and can be determined separately according to incoming and outgoing network bandwidth. In addition, outgoing traffic (egress) can be marked at the namespace level with differentiated services code point (DSCP) classifications in order to assign quality of service classes to the outgoing packets in the physical network. Section 2: This requirement must be implemented organizationally. Note: The behavior of OpenShift completely replicates the standard behavior of Kubernetes. If CPU limits are exceeded, the process is slowed down. If volatile memory is exceeded, the process is stopped and restarted by the scheduler. The persistent memory management is responsible for exceeding the persistent memory - OpenShift will not enforce or limit anything here. Compliance with the limited network bandwidth is enforced by dropping packets that exceed the limit.", "title": "Limitation of Resources per Container", "description": "(1) Resources on the host system such as CPU, volatile and persistent memory, and network bandwidth SHOULD be appropriately reserved and limited for each container. (2) How the system should react if these limits are exceeded SHOULD be defined and documented.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A16", "levels": ["standard"], "notes": "Section 1: 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.\nSection 2: 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. Also the container runtime security tools can detect, alert and remediate, if remote access daemon processes such as SSHD are running in a container.\nSection 3: 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.\nSection 4: 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.", "title": "Administrative Remote Access to Containers", "description": "(1)In principle, administrative access from a container to the container host and vice versa SHOULD be considered as administrative remote access. (2) Remote administrative access SHOULD NOT be established from a container to the container host. (3) Application containers SHOULD NOT contain remote maintenance access points. (4) Administrative access to application containers SHOULD always be carried out via the container runtime.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A17", "levels": ["standard"], "notes": "Section 1: With OpenShift, application containers run in the Security Context Constraint (SCC) \u201crestricted\u201d 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.", "title": "Running Containers Without Privileges", "description": "(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. (2) The container runtime SHOULD be encapsulated by additional measures, such as using the virtualisation extensions of CPUs. (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.", "rationale": null, "automated": "no", "status": "partial", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A18", "levels": ["standard"], "notes": "Section 1: With OpenShift, accounts within the container are separated from the host system by SELinux. This includes preventing the use of privileged user and group IDs as well as corresponding rights extensions (SET-UID, Set-GID bit). A range of UIDs/GIDs is provided for use in containers.\nSection 2: Security Context Constraints (SCCs) allow accounts in the container to gain controlled access.\nSection 3: The host system Red Hat CoreOS is immutable. The changes to the host operating system should only be made by OpenShift and should be necessary so that hardening by Red Hat is not inadvertently undermined. Since, in contrast to an unprotected container runtime environment, SELinux enforces the separation between the container runtime and the operating system, this mirroring of account names is not necessary.", "title": "Application Services Accounts", "description": "(1) System accounts within a container SHOULD have no permissions on the host system. (2) If such authorisation is required for operational reasons, it SHOULD only apply to the data and system access that is absolutely necessary. (3) The account in the container that is necessary to exchange data SHOULD be known in the host system", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": ["selinux_policytype", "selinux_state", "coreos_enable_selinux_kernel_argument"], "controls": []}, {"id": "SYS.1.6.A19", "levels": ["standard"], "notes": "Section 1: Applications can access persistent volumes (PVs) and temporary (ephemeral) storage in OpenShift. Persisted volumes are connected as network storage, ephemeral storage serves primarily as volatile, short-lived mass storage and is allocated within the container file system. This configures which PV can be reached and the use of the ephemeral storage is separated per pod. This means that each pod has its own volatile mass storage. Volumes can be limited in size.\nSection 2: OpenShift implements the principle of least privileges. The definition is made via an explicit configuration at the deployment level.\nSection 3: By default, no local storage is included. For reasons of reliability, this is explicitly not recommended.\nSection 4: The network storage dictates the permissions. OpenShift supports this with the dynamically assigned UID/GID of the projects (clients).", "title": "Including Data Stores in Containers", "description": "(1) Containers SHOULD ONLY be able to access the mass storage and directories necessary for operation. (2) Permissions SHOULD only be explicitly assigned where needed. (3) If the container runtime for a container includes local storage, the access rights in the file system SHOULD be restricted to the service account of the container. (4) If network storage is used, the permissions SHOULD be set on the network storage itself", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A20", "levels": ["standard"], "notes": "Section 1: OpenShift only maintains the current version of the configuration. It is therefore recommended to use GitOps, in which the configuration is transferred from a git repository to the OpenShift cluster. OpenShift includes OpenShift GitOps (based on the community project ArgoCD), which supports easy implementation of a GitOps-based administration concept.\nSection 2: With a GitOps approach, all changes are documented in git.", "title": "Protection of Configuration Data", "description": "(1) Descriptions of container configuration data SHOULD be versioned. (2) Changes SHOULD be documented in a comprehensible manner.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A21", "levels": ["elevated"], "notes": "Section 1: By default, OpenShift blocks the containers' permissions (security-by-default).\nSection 2: OpenShift already uses SELinux Mandatory Access Control to restrict permissions by default Using the Security Profiles Operator, workload-dependent SELinux and Seccomp profiles can be created and managed.\nSection 3: These permissions are managed in OpenShift and controlled via Security Context Constraints (SCCs). For tool-based policy management, ACS or Red Hat Advanced Cluster Management (ACM) (with Kyverno or Open Policy Agent) can be used.\nSection 4: OpenShift already meets this requirement as standard (security-by-design).", "title": "Extended Security Policies", "description": "(1) Extended policies SHOULD restrict the permissions of containers. (2) Mandatory Access Control (MAC) or a comparable technology SHOULD enforce these policies. (3) At minimum, policies SHOULD restrict the following types of access: \u2022 Incoming and outgoing network connections \u2022 File system access attempts \u2022 Kernel requests (syscalls) (4) A runtime SHOULD start containers in such a way that the kernel of the host system prevents all activities of the containers that are not allowed by the relevant policy (e.g. by setting up local packet filters or revoking permissions), or at least reports violations appropriately.", "rationale": null, "automated": "yes", "status": "automated", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": ["selinux_policytype", "selinux_state", "coreos_enable_selinux_kernel_argument", "service_firewalld_enabled"], "controls": []}, {"id": "SYS.1.6.A22", "levels": ["elevated"], "notes": "The OpenShift container runtime environment used does not provide a function for creating a memory image of a running container.\nThe running containers can be listed and different parameters can be queried and saved for them.  Further data (such as running processes) can be queried via the host. Using the operating system,  memory dumps (core dump) or file system data (ephemeral and persistent) can also be backed up.\nTo fully address the requirement and automatically capture an image of a container based on rules, one needs to utilize an additional 3rd Party solution.", "title": "Provision for Investigations", "description": "(1) In order to have containers available for later investigation in case they are needed, an image of each container's state SHOULD be created according to specified rules.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A23", "levels": ["elevated"], "notes": "Section 1: This requirement must be implemented organizationally. Note: By default, Red Hat recommends building containers so that the runtime UID does not have write  permissions in the container. If the file system is changed (e.g. for a file system-based cache), this change will be lost when you restart, as the unchangeable image will be loaded again.\nSection 2: By default, local file systems are not mounted in containers. Containers access PVs that are  integrated via OpenShift. Alternatively, ephemeral volumes can be used as volatile storage. The requirement to mount file systems without write permissions must be implemented organizationally: - The container's root file system can be restricted to ReadOnly via the SecurityContext. - Every container's VolumeMount can be specified as read only.", "title": "Container Immutability", "description": "(1) Containers SHOULD not be able to change their file system during runtime. (2) File systems SHOULD not be integrated with write permissions.", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A24", "levels": ["elevated"], "notes": "The requirement is not met by OpenShift itself but requires the implementation of additional  container runtime security solutions such as Red Hat Advanced Cluster Security (ACS).\nNote: At the host level, Red Hat CoreOS supports auditd, which is enabled by default.  Policies for auditd can include network connections, created processes, file accesses and syscalls.  Red Hat CoreOS provides many sample policies that cover all of the areas described.", "title": "Host-Based Attack Detection", "description": "(1) The behaviour of containers and the applications or services running in them SHOULD be monitored. (2) Deviations from normal behaviour SHOULD be noticed and reported. (3) The reports SHOULD be handled appropriately in a centralised process for security incident handling. (4) At minimum, the behaviour to be monitored SHOULD cover:\n  (5) \u2022 Network connections\n  (6) \u2022 Created processes\n  (7) \u2022 File system access attempts\n  (8) \u2022 Kernel requests (syscalls)", "rationale": null, "automated": "no", "status": "does not meet", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A25", "levels": ["elevated"], "notes": "OpenShift offers multiple technical options by default (replicas, pod anti-affinities, topology spread constraints). The applications needs to support this high availability. Clusters can also be distributed across multiple fire zones (failure zones) within a region/location. Multi-Cluster/Multi-Region distribution can be considered additionally, if required.\nThe decision of the most appropriate level needs to be done organizationally per application. No rules are checked here, as no required level of high availability is stated in the requirement. Note: Technical checks for this can be found at APP.4.4.A19: \"High Availability of Kubernetes\"", "title": "High Availability of Containerised Applications", "description": "(1) In cases involving containerised applications with high availability requirements, the necessary level of availability SHOULD be defined (e.g. redundant at the host level)", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}, {"id": "SYS.1.6.A26", "levels": ["elevated"], "notes": "Section 1,2,4: OpenShift offers the option of binding containers (in pods) to specific nodes using node labels and node selectors in the deployment descriptors. Section 3: These can also be made available as virtual machines via hypervisors (via IaaS or via OpenShift Sandboxes). This implements all three assignments mentioned in the requirement.", "title": "Advanced Isolation and Encapsulation of Containers", "description": "(1) If further isolation and encapsulation of containers is required, the following measures SHOULD be considered for increased effectiveness: (2) \u2022 Fixed assignment of containers to container hosts (3) \u2022 Execution of the individual containers and/or the container host by means of hypervisors (4) \u2022 Fixed assignment of a single container to a single container host", "rationale": null, "automated": "no", "status": "manual", "mitigation": null, "artifact_description": null, "status_justification": null, "fixtext": null, "check": null, "tickets": null, "original_title": null, "related_rules": [], "rules": [], "controls": []}], "levels": [{"id": "basic", "inherits_from": null}, {"id": "standard", "inherits_from": ["basic"]}, {"id": "elevated", "inherits_from": ["standard"]}]}