Fix creation of OVA server pod under enforced restricted namespaces

[bkhizgiy]

When a new namespace is created in OpenShift, it is automatically labeled with pod-security.kubernetes.io/audit, which refers to a secondary, restricted security level. The situation diffrent in Kubernetes and for the default namespace, where such automatic labeling does not occur. When a namespace is marked as restricted, an additional label, pod-security.kubernetes.io/enforce, is added. This label represents the highest security level, where violations are not permitted. When deploying an OVA server pod, it is created with standard settings across all namespaces, except those marked only with the enforce option. In these cases, extra configuration is required to eliminate any potential security violations.

[liranr23]

Did you check other pods we create(virt-v2v, populators)? In my opinion they work in the default namespace. I don't remember we ever checked the restriction level. Can the OVA provider work with the additional restriction here without checking the namespace?

[bkhizgiy]

After testing it with virt-v2v pod its working without the extra configuration, but it seams that the difference relays on the fact the ova server runs as a deployment while the virt-v2v created directly as a pod. for the deployment in the highest security level there is extra enforcement for the user that can run the pod while for the others its not required and determine automatically.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[liranr23]

After testing it with virt-v2v pod its working without the extra configuration, but it seams that the difference relays on the fact the ova server runs as a deployment while the virt-v2v created directly as a pod. for the deployment in the highest security level there is extra enforcement for the user that can run the pod while for the others its not required and determine automatically.

so, can we do it as restricted all the time on any namespace?

[bkhizgiy]

After testing it with virt-v2v pod its working without the extra configuration, but it seams that the difference relays on the fact the ova server runs as a deployment while the virt-v2v created directly as a pod. for the deployment in the highest security level there is extra enforcement for the user that can run the pod while for the others its not required and determine automatically.

so, can we do it as restricted all the time on any namespace?

No, for the audit security level when specifying the user + not root the pod creation being blocked, plus I've tried to specify what is the the permitted UID range as part of the controller SCC but its allowed for use only when setting the security to enforce (so same behavior).