Nextcloud pods run as the namespace's default service account: the chart's account is only created with rbac.enabled, which binds the removed PodSecurityPolicy

Start in templates/serviceaccount.yaml, where the account is rendered only when rbac.enabled is set, and in the Deployment and cron CronJob templates, where serviceAccountName is set only under that same condition. Make the account render whenever rbac.serviceaccount.create is true, default its name to the release's full name, and fail with a clear error when create is false and no name is given. Done when helm template with default values shows serviceAccountName on both pods and the account exists, and the create: false case errors out.

Today

With the chart's defaults, the Nextcloud Deployment (and the cron CronJob, when enabled) runs as the namespace's default service account. The chart has its own account, rbac.serviceaccount, with create: true by default, but templates/serviceaccount.yaml renders it only when rbac.enabled is also true, and the pod templates set serviceAccountName only then.

rbac.enabled is off by default, and it isn't about the service account at all: it creates a Role and RoleBinding granting use on the privileged PodSecurityPolicy, in the extensions API group. PodSecurityPolicy was removed from extensions in Kubernetes 1.16 and removed entirely in 1.25. So on every supported cluster the RBAC part does nothing, and the service account is held back by a switch for a feature that no longer exists.

Why running as default matters

• Shared permissions: every pod in the namespace without its own account uses default. A Role bound to it by another chart, an operator or an admin also applies to Nextcloud, and its mounted token can use it.
• Cloud identity is blocked: a dedicated account is how a pod gets cloud credentials without static keys: an IRSA annotation on EKS, Workload Identity on GKE, the same on AKS. For Nextcloud that's the natural way to reach S3 primary storage. Today rbac.serviceaccount.annotations only takes effect with rbac.enabled, which also creates the obsolete PSP Role.
• No attribution: the API server's audit log records calls by account, so Nextcloud can't be told apart from anything else running as default.
• Hardened clusters flag it: CIS Kubernetes Benchmark 5.1.5 ("Ensure that default service accounts are not actively used") is commonly enforced by admission policies. The CNTi Test Suite's dedicated_service_account test checks the same and fails on the chart's defaults.

Proposal

1. Create the service account whenever rbac.serviceaccount.create is true (already the default), independent of rbac.enabled, and always set serviceAccountName on the Nextcloud pods: the Deployment and the cron CronJob.
2. Default the account's name to the release's full name instead of the fixed nextcloud-serviceaccount: once the account is always created, a fixed name would make two releases in one namespace collide. A name set in rbac.serviceaccount.name is kept.
3. With create: false, require rbac.serviceaccount.name, with a clear error, since it must name an existing account.

The PSP Role behind rbac.enabled is left as it is: removing or repurposing it is a separate decision.

Compatibility:

• Installs with rbac.enabled: false (the default) move from default to the chart's own account, which needs no permissions; nothing changes for Nextcloud itself.
• Installs with rbac.enabled: true and the old default name get an account named after the release instead; anyone who bound roles to nextcloud-serviceaccount outside the chart can keep the name by setting rbac.serviceaccount.name.

Verified

On a fork, with the change on the current main (chart 9.4.0 → 9.5.0):

• helm lint passes on the defaults and on all nine test-values sets. Renders were checked for the defaults, two releases in one namespace, an existing account, rbac.enabled with the old name, the cron CronJob, and create: false without a name (clear error).
• The chart's own Lint and Test Charts workflow, on GitHub-hosted runners: ct lint and all eight install cases pass (run 38956730034).
• CNTi Test Suite (run 38956812911): dedicated_service_account fails on main ("sets no serviceAccountName, so its pods run as the namespace's default service account") and passes with the change; the essential tests are unchanged at 15 of 19.

Related, and not part of this: Nextcloud doesn't use the Kubernetes API, so the account's token could also stay unmounted (automountServiceAccountToken: false, CIS 5.1.6). Once the account exists by default, that's a one-line follow-up.