Security(H-04): privileged in-cluster NFS server (abandoned-image repack) enabled by default

Summary

The in-cluster NFS server fallback is enabled by default and runs a privileged container built from a repack of an abandoned upstream image. It exposes NFS, mountd, and rpcbind with no NetworkPolicy, no image digest, no seccomp profile, no resource limits, and no ServiceAccount-token opt-out.

Severity: High · CWE-250 (Execution with Unnecessary Privileges)
Validation: Confirmed against HEAD f932d80 on 2026-07-14 (assessed at 69c84f7; unchanged since).

Evidence

• Both toggles default true: values.yaml:171 sharedStorage.enabled: true, values.yaml:189 sharedStorage.nfsServer.enabled: true. The gating helper (templates/_helpers.tpl:69-77) renders the server whenever sharedStorage.storageClass is empty (default ""), so a default install with no explicit storage class does deploy it.
• Image is a mutable tag described in-repo as an abandoned-upstream repack: values.yaml:193-200 (quay.io/nebari/volume-nfs:0.8-repack, a repack of the abandoned gcr.io/google-containers/nfs-server:0.8). templates/nfs-server.yaml:78 references repository:tag, no digest.
• Privileged container: templates/nfs-server.yaml:89-90 securityContext: { privileged: true }. Ports 2049 (nfs), 20048 (mountd), 111 (rpcbind) on both container (nfs-server.yaml:79-88) and Service (nfs-server.yaml:34-43).
• Missing controls: no NFS-scoped NetworkPolicy (only hub-nebi-networkpolicy.yaml and singleuser-gateway-egress.yaml exist, neither targets NFS); no automountServiceAccountToken: false; no seccompProfile: RuntimeDefault; no capability drops; no container resource limits.

The repo documents this as transitional and tracked for removal in #29, which is a process mitigation, not a runtime control.

Impact

Compromise or mutation of the NFS image can expose or alter all group-shared data. Because the container is privileged, impact can extend to the node where host controls permit it. Cluster-wide reachability also gives any compromised workload a network path to the NFS ports.

Remediation

• Disable the in-cluster NFS fallback by default; require a maintained CSI ReadWriteMany service for production.
• If an in-cluster server is retained, use a maintained, digest-pinned, signed image with dedicated nodes, a strict NetworkPolicy, token opt-out, resource controls, and the least privilege technically possible.
• Document backup, encryption, recovery, and migration.

Acceptance criteria

• The default chart creates no privileged NFS pod.
• Production installation fails without an approved RWX class.
• Only authorized user pods can reach the NFS ports.
• The image is immutable, supported, signed, scanned, and admission-verified.

Related

• #129 asks to document the privileged NFS justification in user-facing docs (linking #29 as the exit plan). This issue is broader: it covers disabling by default, digest pinning, NetworkPolicy, seccomp, token opt-out, and resource limits, none of which #129 addresses.
• #29 (NFS removal exit plan)

_{Source: data-science-pack 0.1.0 security assessment (pinned commit 69c84f72df259ec755ed40bfc83f20158c550d55), finding H-04.}

Start with values.yaml, templates/_helpers.tpl, and templates/nfs-server.yaml to trace when the NFS server is enabled and how its pod is rendered; compare the existing hub-nebi-networkpolicy.yaml and singleuser-gateway-egress.yaml policies. Done means the acceptance criteria are met, including no privileged NFS pod by default, approved RWX enforcement, authorized-only NFS access, and an immutable supported image with the required controls.