Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Include all securityContext fields in injection template #17318
Istio's sidecar injection webhook rewrites the pod spec to inject the Istio containers, after the pod spec has been rewritten by the PodSecurityPolicy admission controller to match the applied PSP, but also before the PSP validation (see #12231 for more details). In the case the spec injected by Istio would need to be mutated by the PSP admission controller, esp. if the Istio container specs are missing some fields in their
This problem concerns only automatic sidecar injection. Manual injection doesn't have this problem, because in this case the
To observe the mutations done by the PSP admission controller (and other controllers):
For instance for an injected
The relevant mutations are in the
What annotations and fields are injected depends on which PSP the PSP admission controller matched with the pod spec.
Both the security annotations and the fields in
This issue tracks updating Istio's default injection template to include all the
Injecting custom annotations is tracked in #17331.
Affected product area (please put an X in all that apply)
[x] Configuration Infrastructure
Version (include the output of
All Istio versions.
Environment where bug was observed (cloud vendor, OS, etc)
Any cluster with pod security policy enabled.
Do we have a maintenance problem? Will we need to keep changing Istio as the PSP admission controller has new fields?
Would it be better to figure out a way to invert the PSP admission controller and the Istio sidecar injector webhook? Maybe this is a problem with PSP validation and we should discuss with that project?
Adding all fields in the
This problem only exists when a webhook injects new containers into the pod spec, which is rather specific to Istio.
@rlenglet that's a shame! Is that because of the way that istio/operator, istio/installer and istio/istio were related for 1.4.x releases? (I see that installer & operator have both been subsumed into the main istio repo now.)
Yes, commit SHAs have to be explicitly picked up in each release branch. Istio 1.5 won't have that problem. But we still have to update SHAs manually in