[BUG] Pod spec security contexts are being mutated

[tspearconquest]

Components and versions
[ ] Controller, version: x.x.x (docker image tag)
[ x ] Env-Injector (webhook), version: 1.5.0 (docker image tag)
[ ] Other

Describe the bug
#548 Introduces a hard-coded default for the pod security context to force the pod's security context read only root filesystem value to false. This causes the webhook to mutate pods which may have already set the security context to true, and users have no option to prevent this behavior.

To Reproduce
Deploy and use the env-injector.

Expected behavior
Expected behaviour would be for the AKV2K8S webhook to NOT mutate the pod-level security context, which may be set true for some workloads and false for some other workloads.

Additional context
We could set the webhook_pod_spec_security_context_non_root field to true through the webhook, then it will force all pod specs to true, which is not what we want.

AKV2K8S should not mutate pod spec securityContext fields in the pods it's mutating, and should only have added the security context for its own containers.

[HammerNL89]

Yes, we noticed the same behavior, the webhook is modifying/overwriting 'every' pod securityContext even if the pod isn't using any @azurekeyvault references.
The webhook should not modify the securityContext of 'users' pods, apart from it's own 'copy' initContainer.

Would be nice if the linked PR could be merged asap, because we need the newer version for workload identity.

[slushysnowman]

This is pretty important, would be good if this could be looked at

[tspearconquest]

Hi all, I've pinged in the team's slack channel to ask a maintainer to take a look. They are based in EU time and my ping was at the end of their day, so hopefully they will take a look tomorrow.

[slushysnowman]

@181192 thanks for merging, any chance we can get a helm release with this fix in it?

[tspearconquest]

#592 (comment)