Problem
BuildRoleBinding always binds the <cluster>-barman-cloud Role to a ServiceAccount named after the Cluster (cluster.Name). When a Cluster sets spec.serviceAccountName, the instance pods run as that account instead, so the RoleBinding points at an account nobody uses. The sidecar then can't read the ObjectStore or its Secrets:
objectstores.barmancloud.cnpg.io "<name>" is forbidden: User "system:serviceaccount:<ns>:<shared-sa>" cannot get resource "objectstores" ...
As a result, WAL archiving and backups fail, and a replica restoring from the archive can't start.
A shared service account is how you use cloud workload identity (Azure Workload Identity, EKS IRSA/Pod Identity, GKE Workload Identity) with a service account whose name stays stable. The federated credential or IAM binding is tied to the service account's name, so a per-Cluster account means creating a new cloud-side credential every time a Cluster is renamed, recreated for a major upgrade, or recovered under a new name. The CNPG operator's own RoleBinding already follows spec.serviceAccountName. Only the plugin's doesn't.
The current workaround is a hand-written RoleBinding for each Cluster that grants the plugin's Role to the shared account.
Fix
Use cluster.GetServiceAccountName() (from the CNPG API) for the RoleBinding subject. It returns spec.serviceAccountName when set and falls back to cluster.Name otherwise, so Clusters that don't set the field keep exactly the same RoleBinding they have today.
Existing Clusters that already set spec.serviceAccountName also pick up the fix on the next reconcile. EnsureRoleBinding treats Subjects as additive, so it adds the correct account alongside the old per-Cluster one without removing anything.
Tests
Added BuildRoleBinding unit tests covering:
- the default, where the subject is the Cluster name
spec.serviceAccountName set, where the subject is that account and the RoleRef is unchanged
Related: #649 (Azure Workload Identity setup questions)
Problem
BuildRoleBindingalways binds the<cluster>-barman-cloudRole to a ServiceAccount named after the Cluster (cluster.Name). When a Cluster setsspec.serviceAccountName, the instance pods run as that account instead, so the RoleBinding points at an account nobody uses. The sidecar then can't read the ObjectStore or its Secrets:As a result, WAL archiving and backups fail, and a replica restoring from the archive can't start.
A shared service account is how you use cloud workload identity (Azure Workload Identity, EKS IRSA/Pod Identity, GKE Workload Identity) with a service account whose name stays stable. The federated credential or IAM binding is tied to the service account's name, so a per-Cluster account means creating a new cloud-side credential every time a Cluster is renamed, recreated for a major upgrade, or recovered under a new name. The CNPG operator's own RoleBinding already follows
spec.serviceAccountName. Only the plugin's doesn't.The current workaround is a hand-written RoleBinding for each Cluster that grants the plugin's Role to the shared account.
Fix
Use
cluster.GetServiceAccountName()(from the CNPG API) for the RoleBinding subject. It returnsspec.serviceAccountNamewhen set and falls back tocluster.Nameotherwise, so Clusters that don't set the field keep exactly the same RoleBinding they have today.Existing Clusters that already set
spec.serviceAccountNamealso pick up the fix on the next reconcile.EnsureRoleBindingtreats Subjects as additive, so it adds the correct account alongside the old per-Cluster one without removing anything.Tests
Added
BuildRoleBindingunit tests covering:spec.serviceAccountNameset, where the subject is that account and the RoleRef is unchangedRelated: #649 (Azure Workload Identity setup questions)