containerSecurityContext or similar should also be configureable on init containers

[wodka]

on hardened clusters, qdrant will fail to start because the init containers do not have the right policies assigned.

create Pod qdrant-0 in StatefulSet qdrant failed error: 
pods "qdrant-0" is forbidden: 
violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "ensure-storage-dir-ownership" must set securityContext.allowPrivilegeEscalation=false), 
unrestricted capabilities (container "ensure-storage-dir-ownership" must set securityContext.capabilities.drop=["ALL"]), 
runAsNonRoot != true (pod or container "ensure-storage-dir-ownership" must set securityContext.runAsNonRoot=true), 
seccompProfile (pod or container "ensure-storage-dir-ownership" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

-> either apply the existin gcontainerSecurityContext or allow a separate variable to assign the values

[bashofmann]

The init container needs to run as root to be able to fix file permissions on the volume. The reason this is there is that a previous version of the helm chart was running Qdrant as root. If you just upgrade then to the version not running as root, the permissions on the volume are wrong. I guess you are creating a new cluster. For this, the init container is not necessary. You can set updateVolumeFsOwnership to false (https://github.com/qdrant/qdrant-helm/blob/main/charts/qdrant/values.yaml#L108C1-L108C24) this will deactivate it.

I'll keep this open to evaluate if we should change the default value for this setting to false now that we have a couple releases already since we made the change to not run as root.