Skip to content

fix(nextcloud): run the pods as the chart's own service account by default - #896

Open
martin-mat wants to merge 1 commit into
nextcloud:mainfrom
martin-mat:dedicated-serviceaccount
Open

martin-mat wants to merge 1 commit into
nextcloud:mainfrom
martin-mat:dedicated-serviceaccount

Conversation

@martin-mat

Copy link
Copy Markdown

Description of the change

The chart's service account is now created whenever rbac.serviceaccount.create is true (the default), independent of rbac.enabled, and the Nextcloud Deployment and the cron CronJob always run as it:

  • templates/serviceaccount.yaml: rendered on rbac.serviceaccount.create alone.
  • templates/_helpers.tpl: a nextcloud.serviceAccountName helper. The name defaults to the release's full name; a name set in rbac.serviceaccount.name is kept; with create: false the name is required and must name an existing account.
  • templates/deployment.yaml, templates/cronjob.yaml: serviceAccountName always set from the helper; templates/rbac.yaml: the RoleBinding subject from the same helper.
  • values.yaml: rbac.serviceaccount.name defaults to "" (the release's full name), with comments; README rows corrected; chart 9.4.0 → 9.5.0.

The PSP Role behind rbac.enabled is unchanged.

Benefits

The pods no longer run as the namespace's default service account, so:

  • they don't share its permissions with every other pod in the namespace;
  • rbac.serviceaccount.annotations works without rbac.enabled, for cloud identity (IRSA, Workload Identity) to S3 primary storage;
  • audit entries name Nextcloud;
  • CIS 5.1.5 and the CNTi Test Suite's dedicated_service_account test are satisfied.

Two releases in one namespace no longer collide on a fixed account name.

Possible drawbacks

  • Installs with rbac.enabled: true and the old default name nextcloud-serviceaccount get an account named after the release instead. Roles bound to nextcloud-serviceaccount outside the chart keep working if rbac.serviceaccount.name: nextcloud-serviceaccount is set.
  • create: false without a name now fails at render time with a clear message, instead of silently running as default.

Applicable issues

Additional information

Verified on a fork, on the current main:

  • helm lint on the defaults and all nine test-values sets. Renders 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.
  • This repository's 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 and passes with this change; the essential tests are unchanged at 15 of 19.

Checklist

🤖 Generated with Claude Code

…fault

The chart creates a service account only with rbac.enabled, which is off by
default, so the Nextcloud pods run as the namespace's default service
account. rbac.enabled binds the privileged PodSecurityPolicy, which
Kubernetes removed in 1.25; the account itself has nothing to do with it.

The service account is now created whenever rbac.serviceaccount.create is
true (the default), whatever rbac.enabled says, and the Nextcloud Deployment
and the cron CronJob always run as it. Its name defaults to the release's
full name, so two releases in one namespace don't collide; a name set in
rbac.serviceaccount.name is kept, and with create set to false that name is
required and must name an existing account.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Martin Matyas <martin.matyas@tieto.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant