-
Notifications
You must be signed in to change notification settings - Fork 695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BSI APP.4.4.A14+A15 #12158
base: master
Are you sure you want to change the base?
BSI APP.4.4.A14+A15 #12158
Conversation
Hi @sluetze. Thanks for your PR. I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
🤖 A k8s content image for this PR is available at: Click here to see how to deploy itIf you alread have Compliance Operator deployed: Otherwise deploy the content and operator together by checking out ComplianceAsCode/compliance-operator and: |
QE: /lgtm
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sluetze This looks great.
It just needs a rebase/conflict resolution though.
2a52623
to
10ff141
Compare
88bc69d
to
48d4f52
Compare
2bde234
to
024b942
Compare
This datastream diff is auto generated by the check Click here to see the full diffNew content has different text for rule 'xccdf_org.ssgproject.content_rule_general_network_separation'.
--- xccdf_org.ssgproject.content_rule_general_network_separation
+++ xccdf_org.ssgproject.content_rule_general_network_separation
@@ -7,6 +7,9 @@
[reference]:
APP.4.4.A7
+
+[reference]:
+APP.4.4.A14
[reference]:
SYS.1.6.A3
OCIL for rule 'xccdf_org.ssgproject.content_rule_general_network_separation' differs.
--- ocil:ssg-general_network_separation_ocil:questionnaire:1
+++ ocil:ssg-general_network_separation_ocil:questionnaire:1
@@ -1,3 +1,5 @@
Create separate Ingress Controllers for the API and your Applications. Also setup your environment in a way, that Control Plane Nodes are in another network than your worker nodes. If you implement multiple Nodes for different purposes evaluate if these should be in different network segments (i.e. Infra-Nodes, Storage-Nodes, ...).
+Also evaluate how you handle outgoing connections and if they have to be pinned to
+specific nodes or IPs.
Is it the case that Network separation needs review?
New content has different text for rule 'xccdf_org.ssgproject.content_rule_general_node_separation'.
--- xccdf_org.ssgproject.content_rule_general_node_separation
+++ xccdf_org.ssgproject.content_rule_general_node_separation
@@ -5,9 +5,14 @@
[description]:
Use Nodes or Clusters to isolate Workloads with high protection requirements.
-Run the following command and review the pods and how they are deployed on Nodes. $ oc get pod -o=custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace,APP:.metadata.labels.app\.kubernetes\.io/name,NODE:.spec.nodeName --all-namespaces | grep -v "openshift-"
+Run the following command and review the pods and how they are deployed on Nodes.
+$ oc get pod -o=custom-columns=NAME:.metadata.name,NAMESPACE:.metadata.namespace,APP:.metadata.labels.app\.kubernetes\.io/name,NODE:.spec.nodeName --all-namespaces | grep -v "openshift-"
You can use labels or other data as custom field which helps you to identify parts of an application.
-Ensure that Applications with high protection requirements are not colocated on Nodes or in Clusters with workloads of lower protection requirements.
+Ensure that Applications with high protection requirements are not colocated on Nodes or in Clusters
+with workloads of lower protection requirements.
+
+[reference]:
+APP.4.4.A14
[reference]:
APP.4.4.A15
@@ -16,4 +21,10 @@
SYS.1.6.A3
[rationale]:
-Assigning workloads with high protection requirements to specific nodes creates and additional boundary (the node) between workloads of high protection requirements and workloads which might follow less strict requirements. An adversary which attacked a lighter protected workload now has additional obstacles for their movement towards the higher protected workloads.
+Assigning workloads with high protection requirements to specific nodes creates and additional
+boundary (the node) between workloads of high protection requirements and workloads which might
+follow less strict requirements. An adversary which attacked a lighter protected workload now has
+additional obstacles for their movement towards the higher protected workloads.
+
+[ident]:
+CCE-88903-0 |
Code Climate has analyzed commit 33a1da5 and detected 0 issues on this pull request. The test coverage on the diff in this pull request is 100.0% (50% is the threshold). This pull request will bring the total coverage in the repository to 59.5% (0.0% change). View more on Code Climate. |
Description:
To check against BSI APP4.4.A14 this PR adds a new rule
master_taint_noschedule.
This rule checks, if the masters taint is set on master nodes. As we never know what kind of setup it is, it only checks if it is set at_least_once, since we can conclude that it might mostly be controlled by the schedulers component and be identical for each master node.
This PR also adds ad missing identifier and sets the bsi profile for automatic referencing.
Rationale:
Review Hints:
while we could also check if
.spec.mastersSchedulable
is set in the schedulers.config.openshift.io manifest, this key is not set by default. Thats why I moved to checking the effect instead of the configuration.