core: define empty securityContext for pods to fix CIS 5.7.3 #14823
Conversation
|
If it is possible, please add "backport-release-1.14" label due to we are using rook 1.14 version |
prazumovsky
changed the title
Resolves CIS benchmark rule 5.7.3, Pods part. SecurityContext should be explicitly defined in pod level of Pod spec section. It is sufficient to specify empty securityContext to satisfy CIS 5.7.3 rule. 5.7.3 Apply Security Context to Your Pods and Containers When designing your containers and pods, make sure that you configure the security context for your pods, containers, and volumes. Signed-off-by: Peter Razumovsky <prazumovsky@mirantis.com>
prazumovsky
force-pushed
the
fix-cis-5-7-3-1
branch
from
650ee85 to
516eab4
Compare
| @@ -162,6 +162,7 @@ func (c *ClusterController) cleanUpJobTemplateSpec(cluster *cephv1.CephCluster, | |||
| Volumes: volumes, | |||
| RestartPolicy: v1.RestartPolicyOnFailure, | |||
| PriorityClassName: cephv1.GetCleanupPriorityClassName(cluster.Spec.PriorityClassNames), | |||
| SecurityContext: &v1.PodSecurityContext{}, | |||
There was a problem hiding this comment.
If we set the pod SecurityContext, we need to text thoroughly that it does not break the container security context that is already set. While if both are set, I understand the container security context will override the pod security context, we must confirm that this does not cause issues with the volumes that are mounted. IIRC the pod security context may only be used for volumes, which could break the volumes. See where we are setting container security context with the controller.PodSecurityContext() method. The best way to test this will be on an openshift cluster where the security contexts are necessary. Do you have an openshift cluster for testing?
There was a problem hiding this comment.
Do you have an openshift cluster for testing?
I have no openshift cluster for testing, we tested this on our side on metal3 bare metal cluster ((clusterapi provider) and bm-operator)) with rook-ceph chart installed and got nothing to be worried about. However I understand that it is not a proof (even we could not share the results of testing) and I understand your worry therefore asking back - how can I get openshift cluster for free to test changes? Maybe there any upstream jobs to test such changes?
There was a problem hiding this comment.
We don't have any upstream jobs to test openshift, unfortunately. I can potentially test it on an openshift cluster, it will just take me a few days to get to it. I'll plan on it next week.
There was a problem hiding this comment.
I can potentially test it on an openshift cluster, it will just take me a few days to get to it. I'll plan on it next week.
it would be brilliant, many thanks! I'll wait the results then.
There was a problem hiding this comment.
The testing looks good in my openshift cluster, I could not see any side effects of setting the pod's securitycontext to empty like this. It also seems low risk enough to go ahead and backport to 1.15.
There was a problem hiding this comment.
great news, thanks for merging!
| @@ -162,6 +162,7 @@ func (c *ClusterController) cleanUpJobTemplateSpec(cluster *cephv1.CephCluster, | |||
| Volumes: volumes, | |||
| RestartPolicy: v1.RestartPolicyOnFailure, | |||
| PriorityClassName: cephv1.GetCleanupPriorityClassName(cluster.Spec.PriorityClassNames), | |||
| SecurityContext: &v1.PodSecurityContext{}, | |||
There was a problem hiding this comment.
The testing looks good in my openshift cluster, I could not see any side effects of setting the pod's securitycontext to empty like this. It also seems low risk enough to go ahead and backport to 1.15.
core: define empty securityContext for pods to fix CIS 5.7.3 (backport #14823)
core: define empty securityContext for pods to fix CIS 5.7.3 (backport #14823)
Is this a bug report or feature request?
What should the feature do:
Rook deployments should be CIS compliant.
Currently having rook/rook fail to pass some Kubernetes CIS tests/recommandations.
What is use case behind this feature:
Almost all Rook deployments / daemonsets / jobs have no securityContext defined on a pod level (
spec.template.spec). These objects could satisfy CIS 5.7.3 rule even with empty securityContext explicitly defined on a pod level.