Thanks for your reply and provided details as well as questions.
Regarding PSPs and PSP Admission Controller, we did not force yet denying of privileged containers creation/deployment and just evaluate which infrastructure workloads could run in unprivileged mode, to gather more details.
There is one important aspect regarding the
securityContext properties I mentioned above
privileged. They both are related to the container’s security context.
At the same time, according to the documentation, Istio supports only security context related to Pod, that does not contain the properties above mentioned in its specification.
I also did a test. After istio control plane was properly deployed, I edited the
istiod deployment by adding mentioned above properties to the
securityContext at container spec level. As result a new
istiod pod was provisioned that finally contained exactly the expected properties in the container’s securityContext:
In this case, having 2 PSPs registered to the service account used to deploy istio, new deployed
istiod pod was properly validated by the unprivileged PSP. The right PSP was chosen by taking in consideration the container’s securityContext with properly set privileged related configs.
Regarding the test of well operating Istio after this changes, we will do more evaluation.
- Istio does not expose the container’s securityContext configuration that could be used before installation
- Manually editing the istiod deployment by adding privilege related properties to the container spec, allowed to provision new istiod pod with expected securityContext on container level that is a prerequisite for validating by unprivileged PSP.
- Not clear yet if adjusting the istiod container’s securityContext does not affect the Istio proper operating.
Any knowledge sharing, recommendations for this topic are more than welcomed.
Thanks in advance.