Bsi app 4.4 a20to21 #11997
Bsi app 4.4 a20to21 #11997
Conversation
|
Hi @ermeratos. 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. |
|
Start a new ephemeral environment with changes proposed in this pull request: ocp4 (from CTF) Environment (using Fedora as testing environment) Fedora Testing Environment Oracle Linux 8 Environment |
|
🤖 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: |
| interactive: true | ||
|
|
||
| options: | ||
| default: "86400" |
There was a problem hiding this comment.
Please, ensure that all files have a "new line" at the end.
|
|
||
| ocil: |- | ||
| Run the following command to retrieve the customresourcedefinitions objects in the system: | ||
| <pre>$ oc get crds </pre> |
There was a problem hiding this comment.
I think we could specify the CRD name explicity?
| <pre>$ oc get crds </pre> | |
| <pre>$ oc get crds kubedeschedulers.operator.openshift.io</pre> |
or use grep:
| <pre>$ oc get crds </pre> | |
| <pre>$ oc get crds | grep descheduler</pre> |
| 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 |
There was a problem hiding this comment.
The default podLifetime is 24h, but it can be changed.
There could be a rule to check that podLifetime is 24h.
There was a problem hiding this comment.
I have currently no idea how to check the podLifetime. By default there is no field fpr podLifetime in the yaml, also from what I understand the value can be formatted differently. So I have to either check for the field not existing at all, for a value less than "24h" (I think the type is time.Duration) or something like "86400s"
I would rather leave this as is for now and maybe expand on this later.
| @@ -0,0 +1,42 @@ | |||
| documentation_complete: true | |||
|
|
|||
| title: Ensure that the LifecycleAndUtilization profile for the Kube Descheduler operator is enabled | |||
There was a problem hiding this comment.
I feel like this rule should be split into two,
- one rule that ensures the descheduler is run once a day: deschedulingIntervalSeconds == 86400
- one rule configuring the lifetime criteria used to deschedule: podLifetime == 24h
There was a problem hiding this comment.
I have currently no idea how to check the podLifetime. By default there is no field fpr podLifetime in the yaml, also from what I understand the value can be formatted differently. So I have to either check for the field not existing at all, for a value less than "24h" (I think the type is time.Duration) or something like "86400s"
I would rather leave this as is for now and maybe expand on this later.
|
/test e2e-aws-ocp4-bsi |
There was a problem hiding this comment.
Not required right now, but it would be nice to have e2e tests.
Something similar to container_security_operator/tests .
| name: yamlfile_value | ||
| vars: | ||
| ocp_data: "true" | ||
| filepath: {{{ openshift_filtered_path('/apis/apiextensions.k8s.io/v1/customresourcedefinitions?limit=500', jqfilter) }}} |
There was a problem hiding this comment.
By the way, would it be more reliable and simpler to check for the operator's subscription instead of looking for its CRDs?
Check what container_security_operator_exists rule does.
Description:
Notes / Rules for BSI APP4.4.A21 added.
Rationale:
As we have multiple customers asking for a BSI profile to be included in the compliance-operator, we are contributing a profile. To provide a better review process, the individual controle are implemented as separate PRs.