Added Content for BSI rules APP.4.4.A8 to A11

controls/bsi_app_4_4.yml

@@ -144,10 +144,10 @@ controls:
     levels:
     - standard
     description: >-
-      The configuration files of a Kubernetes cluster, including all its extensions and applications,
+      (1) The configuration files of a Kubernetes cluster, including all its extensions and applications,
       SHOULD be versioned and annotated.
-      Access rights to configuration file management software SHOULD be granted in a restrictive
-      manner. Read and write access rights to the configuration files of the control plane SHOULD
+      (2) Access rights to configuration file management software SHOULD be granted in a restrictive
+      manner. (3) Read and write access rights to the configuration files of the control plane SHOULD
       be assigned and restricted with particular care.
     notes: >-
       OpenShift is fully configured using Kubernetes resources including CustomResources (CR). All 
@@ -172,15 +172,15 @@ controls:
     levels:
     - standard
     description: >-
-      Pods SHOULD NOT use the "default" service account. Rights SHOULD NOT be granted to the
-      "default" service account. Pods for different applications SHOULD run under their own service
-      accounts. Access rights for the service accounts of the applications' pods SHOULD be limited
+      (1) Pods SHOULD NOT use the "default" service account. (2) Rights SHOULD NOT be granted to the
+      "default" service account. (3) Pods for different applications SHOULD run under their own service
+      accounts. (4) Access rights for the service accounts of the applications' pods SHOULD be limited
       to those that are strictly necessary.
-      Pods that do not require a service account SHOULD not be able to view it or have access to
+      (5) Pods that do not require a service account SHOULD not be able to view it or have access to
       corresponding tokens.
-      6 Only control plane pods and pods that absolutely need them SHOULD use privileged service
+      (6) Only control plane pods and pods that absolutely need them SHOULD use privileged service
       accounts.
-      Automation programs SHOULD each receive their own tokens, even if they share a common
+      (7) Automation programs SHOULD each receive their own tokens, even if they share a common
       service account due to similar tasks.
     notes: >-
       Section 1-5: This needs to be adressed in the individual application deployments. The
@@ -214,10 +214,10 @@ controls:
     levels:
     - standard
     description: >-
-      All automation software processes, such as CI/CD and their pipelines, SHOULD only operate
-      with the rights that are strictly necessary. If different user groups can change configurations or
-      start pods via automation software, this SHOULD be done for each group through separate
-      processes that only have the rights necessary for the respective user group.
+      (1) All automation software processes, such as CI/CD and their pipelines, SHOULD only operate
+      with the rights that are strictly necessary. (2) If different user groups can change 
+      configurations or start pods via automation software, this SHOULD be done for each group 
+      through separate processes that only have the rights necessary for the respective user group.
     notes: >-
       This control needs to be adressed on an organizational level. All service accounts used by 
       automation software need to adhere to the principle of least privilege.
@@ -229,11 +229,11 @@ controls:
     levels:
     - standard
     description: >-
-      In pods, each container SHOULD define a health check for start-up and operation ("readiness"
-      and "liveness"). These checks SHOULD provide information about the availability of the
-      software running in a pod. The checks SHOULD fail if the monitored software cannot perform
-      its tasks properly. For each of these checks, a time period SHOULD be defined that is
-      appropriate for the service running in the pod. Based on these checks, Kubernetes SHOULD
+      (1) In pods, each container SHOULD define a health check for start-up and operation ("readiness"
+      and "liveness"). (2) These checks SHOULD provide information about the availability of the
+      software running in a pod. (3) The checks SHOULD fail if the monitored software cannot perform
+      its tasks properly. (4) For each of these checks, a time period SHOULD be defined that is
+      appropriate for the service running in the pod. (5) Based on these checks, Kubernetes SHOULD
       delete or restart the pods.
     notes: >-
       The existance of readiness und liveness probes can be validated technically. This check needs