Merge pull request ComplianceAsCode#12441 from sig-bsi-grundschutz/sy…

…s-1-6-A14

Add new version of conntrols file for SYS.1.6.A14

controls/bsi_sys_1_6.yml

@@ -386,15 +386,24 @@ controls:
     levels:
     - standard
     description: >-
-      When establishing a concept for patch and change management according to OPS.1.1.3 Patch
+      (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. For persistent containers, checks SHOULD be
+      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.
     notes: >-
-      ToDo
+      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: “Persistent” containers contradict the cloud native principle and do not represent “good practice”.
+      There is also a contradiction with APP.4.4.A21 “Regular restart of pods”.
+      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.
     status: manual
-    #rules:
+    rules: []
 
   - id: SYS.1.6.A15
     title: Limitation of Resources per Container