Bind the Role to the Cluster's service account, honoring spec.serviceAccountName
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 88/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- go, kubernetes
调研方向
从 BuildRoleBinding 及其单元测试开始，然后检查 EnsureRoleBinding，以了解 Subjects 是如何协调的。验证默认的 Cluster-name subject 和 spec.serviceAccountName subject，同时保留现有的 RoleRef；两种情况下测试都应通过。
由索引模型根据 Issue 内容生成。
描述
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.serviceAccountNameset, where the subject is that account and the RoleRef is unchanged
Related: #649 (Azure Workload Identity setup questions)
- 主要语言
- Go
- 星标
- 196
- 派生
- 76
- 平均合并
- 1 天 10 小时
- 30 天内合并 PR
- 5
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
cloudnative-pg/plugin-barman-cloud 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 86/100
cloudnative-pg/plugin-barman-cloud#1104 · 4 个 reaction ·
维护者通常 2 天内回复
-
难度 1/5 1 小时以内 新手友好度 82/100
cloudnative-pg/plugin-barman-cloud#1102 ·
维护者通常 2 天内回复
-
Catalog maintenance deletes completed Backup objects after a short barman-cloud-backup-list result未关闭
难度 4/5 3-5 天 新手友好度 48/100
cloudnative-pg/plugin-barman-cloud#1115 · 1 条评论 ·
维护者通常 2 天内回复
-
难度 3/5 1-2 天 新手友好度 65/100
cloudnative-pg/plugin-barman-cloud#1113 · 2 条评论 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 15/100
cloudnative-pg/plugin-barman-cloud#1111 ·
维护者通常 2 天内回复
查看 cloudnative-pg/plugin-barman-cloud 的全部 Issue
相似的 Issue
-
area: global bug dx priority: low
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 68/100
grafana/mcp-grafana#1267 ·
维护者通常 1 天内回复
-
automation models
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
coverage-gap good-first-pattern help wanted
难度 2/5 1-3 小时 新手友好度 78/100
GoogleCloudPlatform/k8s-aibom#114 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
txn2/mcp-data-platform#1984 ·
维护者通常 1 天内回复