We run this chart on a cluster enforcing strict policies and 2 items flagged-up to change:
- ServiceAccount tokens are always auto-mounted
Qdrant pods never call the Kubernetes API, so there's no need for the SA token to be projected into the pod — it's unnecessary attack surface and gets flagged by kube-bench/CIS scans. Neither the ServiceAccount nor the pod spec set automountServiceAccountToken, so it defaults to true.
The PR suggests adding a serviceAccount.automountServiceAccountToken value (default false) to allow configuration
- initContainers: creates empty key
In statefulset.yaml, the initContainers: key is emitted unconditionally, but the ensure-dir-ownership container underneath it is gated by two nested ifs (updateVolumeFsOwnership, containerSecurityContext.runAsUser). When either is falsy (e.g. updateVolumeFsOwnership: false, or useUnprivilegedImage: true), the rendered manifest has initContainers: with nothing under it — a null key that trips up strict manifest validators (kubeconform, etc.) even though Kubernetes itself tolerates it.
Fix: move the initContainers: key itself inside the outer if so it's omitted entirely when there's nothing to put there.
PR for fixes: #505
We run this chart on a cluster enforcing strict policies and 2 items flagged-up to change:
Qdrant pods never call the Kubernetes API, so there's no need for the SA token to be projected into the pod — it's unnecessary attack surface and gets flagged by kube-bench/CIS scans. Neither the ServiceAccount nor the pod spec set automountServiceAccountToken, so it defaults to true.
The PR suggests adding a serviceAccount.automountServiceAccountToken value (default false) to allow configuration
In statefulset.yaml, the initContainers: key is emitted unconditionally, but the ensure-dir-ownership container underneath it is gated by two nested ifs (updateVolumeFsOwnership, containerSecurityContext.runAsUser). When either is falsy (e.g. updateVolumeFsOwnership: false, or useUnprivilegedImage: true), the rendered manifest has initContainers: with nothing under it — a null key that trips up strict manifest validators (kubeconform, etc.) even though Kubernetes itself tolerates it.
Fix: move the initContainers: key itself inside the outer if so it's omitted entirely when there's nothing to put there.
PR for fixes: #505