Repository navigation
fix(apps/postgres): CNPG ServiceAccount lacks RBAC to read projected cozy-backups-creds Secret on first backup #3246
Description
Activity
- added a commit that references this issue
on Jul 21, 2026 Superseded. Closing after verifying against
main(04b742670) — please reopen if the caveat at the bottom reproduces on a cluster.The consumer this was filed against no longer exists. PR #3313 "fix(backups): support cnpg-operator with barman plugin" (
e73ad68a8, merged 2026-07-21) moved the driver off the deprecated nativespec.backup.barmanObjectStorepath — removed from thestandardimage variant in CNPG 1.29 — onto the barman-cloud plugin:applyClusterPluginBackupininternal/backupcontroller/cnpgstrategy_controller.goserver-side-applies abarmancloud.cnpg.io/ObjectStoreand patchesspec.plugins. The projectedcozy-backups-credsSecret is therefore read by the plugin, not by the instance-manager running under thepostgres-<release>ServiceAccount whose missing Role this issue is about.The vendored plugin ships its own RBAC rather than relying on the app chart:
packages/system/postgres-operator/charts/plugin-barman-cloud/templates/rbac.yamlgrants cluster-widesecrets: create,delete,get,list,watchplus theroles/rolebindingsverbs it needs to provision per-cluster sidecar RBAC.Caveat, stated plainly because it is the reason this is "superseded" and not "fixed": the literal complaint is still literally true — there is no
Role/RoleBindingforcozy-backups-credsanywhere underinternal/backupcontroller/orpackages/apps/postgres/. Under the plugin path that Role is simply not the mechanism any more. Whether the plugin path has an equivalent permission gap cannot be settled statically from this repo, since it depends on upstream plugin behaviour; it needs one platform-flow (useSystemBucket: true+cozy-default) BackupJob on a live cluster. If that run fails on reading the projected Secret, reopen this rather than filing anew.Found during an audit of all open backup issues.
Summary
With the platform-managed backup flow (
backup.useSystemBucket: true+cozy-defaultBackupClass), the first Postgres BackupJob fails because the CNPG instance-manager Pod cannot read the projectedcozy-backups-credsSecret:cannot get secret cozy-backups-creds ... forbidden. No Role/RoleBinding grants the Postgres cluster ServiceAccount read access to that Secret.Evidence
internal/backupcontroller/(credentials_projector.go,cnpgstrategy_controller.go) contains noRole/RoleBindingcreation (grep forRoleBindingreturns nothing).spec.backup.barmanObjectStoreonto the live Cluster with asecretKeyReftocozy-backups-creds(internal/backupcontroller/cnpgstrategy_controller.go), which the instance-manager then reads under thepostgres-<release>ServiceAccount.packages/apps/postgres/templates/dashboard-resourcemap.yaml, grantsgeton Secrets only forresourceNames: [<release>-credentials], and its subjects are tenantuse-tier users, not the CNPG ServiceAccount. It does not covercozy-backups-creds.Impact
cozy-defaultfails with aforbiddenerror on a fresh platform-managed Postgres backup setup. The backup path does not work out of the box until the missing RBAC is added.Proposed fix
Emit a Role + RoleBinding in the Postgres chart (or have the backup controller create it alongside the projected Secret) granting the CNPG cluster ServiceAccount
geton thecozy-backups-credsSecret in the tenant namespace, created before/atomically with the projected Secret so the instance-manager never hits aforbiddenwindow.