Bsi app 4.4 a20to21

applications/openshift/general/kube_descheduler_interval.var

@@ -0,0 +1,15 @@
+documentation_complete: true
+
+title: 'Maximum number of seconds between descheduler runs'
+
+description: |-
+   You can configure the maximum amount of time between descheduler runs in seconds.
+
+type: string
+
+operator: equals
+
+interactive: true
+
+options:
+   default: "86400"

applications/openshift/general/kube_descheduler_lifecycle_policy/rule.yml

@@ -0,0 +1,40 @@
+documentation_complete: true
+
+title: Ensure that the LifecycleAndUtilization Profile for the Kube Descheduler Operator is Enabled
+
+description: |-
+    If there is an increased risk of external influences and a very high need for protection, pods should be stopped and restarted regularly.
+    No pod should run for more than 24 hours. The availability of the applications in the pod should be ensured.
+
+rationale: |-
+    If there is an increased risk of external influences and a very high need for protection, pods should be stopped and restarted regularly.
+
+identifiers: {}
+
+severity: medium
+
+ocil_clause: "The LifecycleAndUtilization profile for the Kube Descheduler operator is not enabled, the Interval is too high or mode is not set to automatic"
+
+ocil: |-
+    Run the following command to edit the KubeDescheduler object:
+    <pre>$ oc get kubedeschedulers.operator.openshift.io --all-namespaces </pre>
+    Make sure the LifecycleAndUtilization profile is listed under .spec.profiles and the correct time between descheduler runs is set under .spec.deschedulingIntervalSeconds. Furthermore ensure that .spec.mode is set to 'Automatic'
+
+{{% set jqfilter = '[ .items[].spec | if any(.profiles[]; . =="LifecycleAndUtilization") and .deschedulingIntervalSeconds &lt;= {{.kube_descheduler_interval}} and .mode == "Automatic" then true else false end]' %}}
+
+warnings:
+- general: |-
+    {{{ openshift_filtered_cluster_setting({'/apis/operator.openshift.io/v1/kubedeschedulers': jqfilter}) | indent(4) }}}
+
+template:
+  name: yamlfile_value
+  vars:
+    ocp_data: "true"
+    filepath: {{{ openshift_filtered_path('/apis/operator.openshift.io/v1/kubedeschedulers', jqfilter) }}}
+    yamlpath: "[:]"
+    check_existence: "all_exist"
+    entity_check: "all"
+    values:
+      - value: "true"
+        operation: "equals"
+        entity_check: "at least one"

applications/openshift/general/kube_descheduler_operator_exists/rule.yml

@@ -0,0 +1,37 @@
+documentation_complete: true
+
+title: Ensure that the Kube Descheduler operator is deployed
+
+description: |-
+    If there is an increased risk of external influences and a very high need for protection, pods should be stopped and restarted regularly.
+    No pod should run for more than 24 hours. The availability of the applications in the pod should be ensured.
+
+rationale: |-
+    If there is an increased risk of external influences and a very high need for protection, pods should be stopped and restarted regularly.
+
+identifiers: {}
+
+severity: medium
+
+ocil_clause: "the Kube Descheduler operator is not installed"
+
+ocil: |-
+    To check if the Kube Descheduler Operator is installed, run the following command:
+    <pre>oc get sub --all-namespaces | grep cluster-kube-descheduler-operator</pre>
+    the output should return at least one entry that represents the installed operator.
+
+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: "clusterkubedescheduleroperator.*"
+      operation: "pattern match"
+      entity_check: "at least one"

applications/openshift/general/kube_descheduler_podlifetime/rule.yml

@@ -0,0 +1,19 @@
+documentation_complete: true
+
+title: 'Set Pod Lifetime for the Deschedulers'
+
+description: |-
+    If there is an increased risk of external influences and a very high need for protection, pods should be stopped and restarted regularly.
+    No pod should run for more than 24 hours. The availability of the applications in the pod should be ensured.
+
+rationale: |-
+    If there is an increased risk of external influences and a very high need for protection, pods should be stopped and restarted regularly. With this an attacker who gained control over a pod loses it and the pod gets restarted from a known good state (the image).
+
+severity: medium
+
+ocil_clause: 'podLifetime Values of Deschedulers need review'
+
+ocil: |-
+    Run the following command and review the kubedeschedulers and how they are configured. <pre>$ oc get kubedeschedulers.operator.openshift.io --all-namespaces -o=custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,deschedulingIntervalSeconds:.spec.deschedulingIntervalSeconds,podLifetime:.spec.profileCustomizations.podLifetime,Profiles:.spec.profiles </pre>
+
+    Ensure that each kubedescheduler, which defines the LifecycleAndUtilization Profile also defines a podLifetime of none or below your company threshold (i.e. 24h)

applications/openshift/general/kube_descheduler_podlifetime/tests/ocp4/e2e.yml

@@ -0,0 +1,2 @@
+---
+default_result: MANUAL

controls/bsi_app_4_4.yml

@@ -225,18 +225,18 @@ controls:
       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 
+      OpenShift is fully configured using Kubernetes resources including CustomResources (CR). All
       resources that are created after the initial cluster installation can be considered configuration
-      files as described in this control. 
+      files as described in this control.
 
       Section 1: This control needs to be adressed on an organizational level. To achieve versioning,
-      the configuration files should be stored in a Git repository. The Git repository is considered 
+      the configuration files should be stored in a Git repository. The Git repository is considered
       the only source of truth and provides a visible and auditable trail of changes. To automatically
       apply the configuration, GitOps processes and tools like OpenShift GitOps can be used.
 
       Section 2: This control needs to be adressed in the respective external systems. Access rights
       to the Git repository and GitOps controller should be granted in a restrictive manner.
-      
+
       Section 3: The relevant Kubernetes resources for configuring the control plane are inherently
       protected by Kubernetes RBAC and can only be modified by cluster administrators.
     status: manual
@@ -261,11 +261,11 @@ controls:
       Section 1-5: This needs to be adressed in the individual application deployments. The
       associated rules provide additional guidance.
 
-      Section 6: The usage of privileged service accounts is controlled by Security Context 
-      Constraints (SCC), which should be configured and granted according to the principle of least 
+      Section 6: The usage of privileged service accounts is controlled by Security Context
+      Constraints (SCC), which should be configured and granted according to the principle of least
       privilege.
 
-      Section 7: This control needs to be adressed on an organizational level.      
+      Section 7: This control needs to be adressed on an organizational level.
     status: partial
     rules:
       # Section 1-3:
@@ -297,8 +297,8 @@ controls:
     - standard
     description: >-
       (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 
+      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
@@ -320,7 +320,7 @@ controls:
     notes: >-
       Section 1-3: The existance of readiness und liveness probes can be validated technically. This
       check needs to be performed for each container in every pod individually.
-      Section 4: The adequacy of the checks and the configured time periods needs to be ensured by 
+      Section 4: The adequacy of the checks and the configured time periods needs to be ensured by
       the application owner.
       Section 5: This functionality is inherently met by OpenShift.
     status: manual
@@ -475,10 +475,16 @@ controls:
     levels:
     - elevated
     description: >-
-      Pods SHOULD be stopped and restarted regularly if there is an increased risk of external
-      interference and a very high need for protection. No pod SHOULD run for more than 24
+      (1) Pods SHOULD be stopped and restarted regularly if there is an increased risk of external
+      interference and a very high need for protection.
+      (2) No pod SHOULD run for more than 24
       hours. The availability of the applications in a pod SHOULD be ensured.
     notes: >-
       TBD
     status: pending
-    rules: []
+    rules:
+      # Section 1
+      - kube_descheduler_operator_exists
+      # Section 2
+      - kube_descheduler_lifecycle_policy
+      - kube_descheduler_podlifetime