Merge pull request #11342 from sig-bsi-grundschutz/bsi-app-4.4

Control for BSI APP.4.4

Author: yuumasato

controls/bsi_app_4_4.yml

@@ -0,0 +1,355 @@
+policy: 'BSI-APP-4-4'
+title: 'BSI APP.4.4 Kubernetes'
+id: bsi_app_4_4
+version: '1.0'
+source: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi_it_gs_comp_2022.pdf
+levels:
+  - id: basic
+  - id: standard
+    inherits_from:
+    - basic
+  - id: elevated
+    inherits_from:
+    - standard
+
+controls:
+  - id: APP.4.4.A1
+    title: Planning the Separation of the Applications
+    levels:
+    - basic
+    description: >-
+      Before going live, the manner in which the applications running in the pods in question and
+      their different test and production operating environments will be separated MUST be
+      planned. Based on the protection needs of the applications, the planning MUST determine
+      which architecture of namespaces, meta tags, clusters, and networks adequately addresses the
+      risks at hand and whether virtualised servers and networks should also be used.
+      The planning MUST include provisions separating for networks, CPUs, and persistent
+      volumes. The separation SHOULD also take into account and be aligned with the network
+      zone concept and the protection requirements at hand.
+      Each application SHOULD run in a separate Kubernetes namespace that includes all the
+      programs of the application. Only applications with similar protection needs and similar
+      possible attack vectors SHOULD share a Kubernetes cluster.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A2
+    title: Planning Automation with CI/CD
+    levels:
+    - basic
+    description: >-
+      Automating the operation of applications in Kubernetes using CI/CD MUST ONLY take place
+      after appropriate planning. The planning MUST cover the entire lifecycle from commissioning
+      to decommissioning, including development, testing, operation, monitoring, and updates. A
+      roles and rights concept and the securing of Kubernetes Secrets MUST be part of the planning
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A3
+    title: Identity and Access Management for Kubernetes
+    levels:
+    - basic
+    description: >-
+      Kubernetes and all other control plane applications MUST authenticate and authorise each
+      action taken by a user or, in automated mode, corresponding software. This applies whether
+      the actions are taken via a client, a web interface, or a corresponding API. Administrative
+      actions MUST NOT be performed anonymously.
+      Each user MUST ONLY be granted the permissions they absolutely require. Unlimited access
+      rights MUST be granted in a very restrictive manner.
+      Only a small group of people SHOULD be authorised to define automation processes. Only
+      selected administrators SHOULD be given the right to create or change shares for persistent
+      volumes in Kubernetes.
+    notes: >-
+      TBD
+    status: pending
+    rules:
+      - api_server_anonymous_auth
+      - kubelet_anonymous_auth
+      - kubeadmin_removed
+      - rbac_least_privilege
+
+  - id: APP.4.4.A4
+    title: Separation of Pods
+    levels:
+    - basic
+    description: >-
+      The operating system kernel of nodes MUST have isolation mechanisms to restrict visibility
+      and resource usage among the corresponding pods (cf. Linux namespaces and cgroups). At
+      minimum, this isolation MUST include process IDs, inter-process communication, user IDs,
+      the file system, and the network (including the hostname).
+    notes: >-
+      Since these are OS based requirements, they are included in the rhcos4 bsi profile
+    status: pending
+    # rules:
+
+  - id: APP.4.4.A5
+    title: Backup in the Cluster
+    levels:
+    - basic
+    description: >-
+      A cluster MUST have a backup. The backup MUST include:
+        • Persistent volumes
+        • Configuration files for Kubernetes and the other programs of the control plane
+        • The current state of the Kubernetes cluster, including extensions
+        • Databases of the configuration (namely etcd in this case)
+        • All infrastructure applications required to operate the cluster and the services within it
+        • The data storage of the code and image registries
+        Snapshots for the operation of the applications SHOULD also be considered. Snapshots MUST
+        NOT be considered a substitute for backups.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A6
+    title: Initialisation of Pods
+    levels:
+    - standard
+    description: >-
+      If an initialisation (e.g. of an application) takes place in a pod at start-up, this SHOULD take
+      place in a separate Init container. It SHOULD be ensured that the initialisation terminates all
+      processes that are already running. Kubernetes SHOULD ONLY start the other containers if
+      the initialisation is successful.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A7
+    title: Separation of Networks for Kubernetes
+    levels:
+    - standard
+    description: >-
+      Networks for the administration of nodes, the control plane, and the individual networks of
+      application services SHOULD be separated.
+      Only the network ports of the pods necessary for operation SHOULD be released into the
+      designated networks. If a Kubernetes cluster contains multiple applications, all the network
+      connections between the Kubernetes namespaces SHOULD first be prohibited and only
+      required network connections permitted (whitelisting). The network ports necessary for the
+      administration of the nodes, the runtime, and Kubernetes (including its extensions) SHOULD
+      ONLY be accessible from the corresponding administration network and from pods that need
+      them.
+      Only selected administrators SHOULD be authorised in Kubernetes to manage the CNI and
+      create or change rules for the network.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A8
+    title: Securing Configuration Files on Kubernetes
+    levels:
+    - standard
+    description: >-
+      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
+      be assigned and restricted with particular care.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A9
+    title: Use of Kubernetes Service Accounts
+    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
+      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
+      corresponding tokens.
+      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
+      service account due to similar tasks.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A10
+    title: Securing Automation Processes
+    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.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A11
+    title: Container Monitoring
+    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
+      delete or restart the pods.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A12
+    title: Securing Infrastructure Applications
+    levels:
+    - standard
+    description: >-
+      If a separate registry for images or automation software, persistent volume management,
+      configuration file storage, or similar is in use, its protection SHOULD at least consider:
+        • Use of personal and service accounts for access
+        • Encrypted communication on all network ports
+        • Restrictive assignment of permissions to user and service accounts
+        • Logging of changes
+        • Regular data backups.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A13
+    title: Automated Configuration Auditing
+    levels:
+    - elevated
+    description: >-
+      There SHOULD be an automated audit that checks the settings of nodes, of Kubernetes, and of
+      the pods of applications against a defined list of allowed settings and standardised
+      benchmarks.
+      Kubernetes SHOULD enforce these established rules in each cluster by connecting appropriate
+      tools.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A14
+    title: Use of Dedicated Nodes
+    levels:
+    - elevated
+    description: >-
+      In a Kubernetes cluster, nodes SHOULD be assigned dedicated tasks and only run pods that are
+      assigned to each task.
+      Bastion nodes SHOULD handle all incoming and outgoing data connections of between
+      applications and other networks.
+      Management nodes SHOULD operate control plane pods and only handle control plane data
+      connections.
+      If deployed, storage nodes SHOULD only operate the fixed persistent volume services pods in
+      a cluster.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A15
+    title: Separation of Applications at Node and Cluster Level
+    levels:
+    - elevated
+    description: >-
+      Applications with very high protection needs SHOULD each use their own Kubernetes clusters
+      or dedicated nodes that are not available for other applications
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A16
+    title: Use of Operators
+    levels:
+    - elevated
+    description: >-
+      The automation of operational tasks in operators SHOULD be used for particularly critical
+      applications and control plane programs.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A17
+    title: Attestation of Nodes
+    levels:
+    - elevated
+    description: >-
+      Nodes SHOULD send a cryptographically secured (and, if possible, TPM-verified) status
+      message to the control plane. The control plane SHOULD ONLY accept nodes into a cluster
+      that have successfully proven their integrity.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A18
+    title: Use of Micro-Segmentation
+    levels:
+    - elevated
+    description: >-
+      Pods SHOULD ONLY be able to communicate with each other through the necessary network
+      ports, even within a Kubernetes namespace. There SHOULD be rules within the CNI that
+      disallow all but the necessary network connections within the Kubernetes namespace. These
+      rules SHOULD precisely define the source and destination of the allowed connections using at
+      least one of the following criteria: service name, metadata (“labels”), Kubernetes service
+      accounts, or certificate-based authentication.
+      All the criteria used as labels for a connection SHOULD be secured in such a way that they can
+      only be changed by authorised persons and management services.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A19
+    title: High Availability of Kubernetes
+    levels:
+    - elevated
+    description: >-
+      A Kubernetes operation SHOULD be set up in such a way that if a site fails, the clusters (and
+      thus the applications in the pods) either continue to run without interruption or can be
+      restarted in a short time at another site.
+      Should a restart be required, all the necessary configuration files, images, user data, network
+      connections, and other resources required for operation (including the necessary hardware)
+      SHOULD already be available at the alternative site.
+      For the uninterrupted operation of clusters, the control plane of Kubernetes, the infrastructure
+      applications of the clusters, and the pods of the applications SHOULD be distributed across
+      several fire zones based on the location data of the corresponding nodes so that the failure of a
+      fire zone will not lead to the failure of an application.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A20
+    title: Encrypted Data Storage for Pods
+    levels:
+    - elevated
+    description: >-
+      The file systems containing the persistent data of the control plane (etcd in particular in this
+      context) and the application services SHOULD be encrypted.
+    notes: >-
+      TBD
+    status: pending
+    rules: []
+
+  - id: APP.4.4.A21
+    title: Regular Restart of Pods
+    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
+      hours. The availability of the applications in a pod SHOULD be ensured.
+    notes: >-
+      TBD
+    status: pending
+    rules: []

products/ocp4/profiles/bsi-node.profile

@@ -0,0 +1,31 @@
+documentation_complete: true
+
+title: 'BSI IT-Grundschutz (Basic Protection) Building Block SYS.1.6 and APP.4.4'
+
+platform: ocp4-node
+
+reference: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi_it_gs_comp_2022.pdf
+
+metadata:
+    SMEs:
+        - ermeratos
+        - benruland
+        - oliverbutanowitz
+        - sluetze
+    version: 2022
+
+description: |-
+    This profile defines a baseline that aligns to the BSI (Federal Office for Security Information) IT-Grundschutz
+    Basic-Protection.
+
+    This baseline implements configuration requirements from the following
+    sources:
+
+    - Building-Block SYS.1.6 Containerisation
+    - Building-Block APP.4.4 Kubernetes
+
+
+filter_rules: '"ocp4-node" in platforms or "ocp4-master-node" in platforms or "ocp4-node-on-sdn" in platforms or "ocp4-node-on-ovn" in platforms'
+
+selections:
+    - bsi_app_4_4:all