search

sig-bsi-grundschutz / content

Security automation content in SCAP, Bash, Ansible, and other formats
https://www.open-scap.org/security-policies/scap-security-guide
Other
7 stars 1 forks source link

APP.4.4.A1 #27

Closed sluetze closed 8 months ago

sluetze commented 11 months ago

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.

- not checkable, since planning is outside of technical checkable actions

The separation SHOULD also take into account and be aligned with the network zone concept and the protection requirements at hand.

- not checkable, since network zone concept is unkown

Each application SHOULD run in a separate Kubernetes namespace that includes all the programs of the application. 

- MANUAL Check

Only applications with similar protection needs and similar possible attack vectors SHOULD share a Kubernetes cluster.

- not checkable, since we can only make checks in ONE cluster.
benruland commented 11 months ago

I see limited value in providing a manual rule to check if applications run in different namespaces. From my perspective this is an org-only control.

edit: I might need to reconsider the relevance of manual checks. If we do not provide those, the controls will not be visible to the OpenShift admins, will they? Then, providing guidance in the form of manual checks might indeed be valuable here.

sluetze commented 11 months ago

will take this over to a customer meeting to get some feedback from them.

sluetze commented 8 months ago

https://github.com/ComplianceAsCode/content/pull/11501 was merged