Repository navigation
fix(apps/postgres): CNPG ServiceAccount lacks RBAC to read projected cozy-backups-creds Secret on first backup #3246
Description
Summary
With the platform-managed backup flow (backup.useSystemBucket: true + cozy-default BackupClass), the first Postgres BackupJob fails because the CNPG instance-manager Pod cannot read the projected cozy-backups-creds Secret: cannot get secret cozy-backups-creds ... forbidden. No Role/RoleBinding grants the Postgres cluster ServiceAccount read access to that Secret.
Evidence
- The backup controller projects the credentials Secret but creates no accompanying RBAC for the consuming SA:
internal/backupcontroller/(credentials_projector.go,cnpgstrategy_controller.go) contains noRole/RoleBindingcreation (grep forRoleBindingreturns nothing). - The CNPG driver SSA-patches
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. - The only Role emitted by the Postgres chart,
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. - No other template or controller creates a Role granting the CNPG SA read access to the projected Secret.
Impact
- The first BackupJob against
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 get on the cozy-backups-creds Secret in the tenant namespace, created before/atomically with the projected Secret so the instance-manager never hits a forbidden window.
Activity
fix(backups): support cnpg-operator with barman plugin (#3313)
androndo commentedon Aug 3, 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.