Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Bind the Role to the Cluster's service account, honoring spec.serviceAccountName

Aperta Adatta ai principianti
  • Qualcosa non va?
#1,117 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
88/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
infrastructure

Direzione di ricerca

Inizia con BuildRoleBinding e i relativi test unitari, quindi esamina EnsureRoleBinding per capire come vengono riconciliati i Subjects. Verifica il Cluster-name subject predefinito e il spec.serviceAccountName subject, preservando il RoleRef esistente; i test dovrebbero passare in entrambi i casi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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)

Lingua principale
Go
Stelle
196
Fork
76
Merge medio
1g 10h
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cloudnative-pg/plugin-barman-cloud

Tutte le issue di cloudnative-pg/plugin-barman-cloud

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.