I have a question related to security policies applied to Istio Control Plane.
In our product, we are trying to reduce the pods with privileged rights as mush as possible.
We defined 2 PSPs one unprivileged another privilege and updated the securityContext for all workloads to ensure the minim security privilege principle/approach to be followed.
Once Istio is installed and all related resources are deployed, we observed that istiod pod from the istio-system namespace does not contain in its securityContext all properties we have set.
We are looking for a possibility to set the following securityContext properties:
I think if you install istiod, you should see security context already specified in the deployment pod spec with something like fsGroup: 1337.
Maybe you specify the securityContext before that and YAML would override the same field if specified later again.
I am not aware of anything else that require more privilege for istiod. Let us know if that such permission would fail.
Also my understanding for PSP: if you set the PSP and clusterole binding correctly it does not matter what the securityContext specified in the workload, such as istiod, right? The PSP admission controller would deny the pod creation if asking for more privelege the workloads specify? You shouldn’t have to modify the istiod’s pod spec?
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 allowPrivilegeEscalation and 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.
Summary:
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.