chart: api-syncagent Role/RoleBinding leaked into 'default' namespace instead of release ns

Open Beginner friendly
#161 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
helm, kubernetes
Domain
devops, infrastructure

Research direction

Start by locating the api-syncagent chart templates that emit the Role and RoleBinding, then render them with the reported helm template command using --namespace my-agent. Confirm both resources use the release namespace rather than default, and verify the rendered output shows namespace: my-agent for each.

Written by the indexing model from the issue text.

Description

Problem

When helm template (or install) the api-syncagent chart against a target --namespace X, most resources correctly land in X, but the Role and RoleBinding for the events leader-election lock emerge with namespace: default instead of namespace: X.

Reproducer:

helm template test api-syncagent/api-syncagent --version 0.4.2 --namespace my-agent | grep -B1 -A10 'kind: Role'

Impact

  • On shared clusters, every sync-agent install quietly writes into default ns.
  • Multiple sync-agents collide on the same names in default (leader-election lock, etc.).
  • Violates least-privilege posture — operators targeting a dedicated namespace don't expect cluster-wide or other-ns writes.

Suspected cause

Helm templates omit .metadata.namespace on Role/RoleBinding. Helm then defaults the namespace to the --namespace flag, unless a release-namespace override is applied somewhere (e.g., {{ .Release.Namespace }} missing from the template, --create-namespace not honored, or a namespace: default literal sneaking in).

Fix

Set namespace: {{ .Release.Namespace }} on the Role + RoleBinding in the templates, matching every other namespace-scoped resource the chart emits.

Noticed at

apeirora/showroom-msp-dati during cluster-infra bring-up for a new dati-syncagent. Same behavior observed for private-llm-sync-agent and cncf-postgres-sync-agent on the same shared MSP cluster (msp03 cc-d2).

Dominant language
Go
Stars
25
Forks
30
Avg merge
3d 9h
Merged PRs (30d)
2

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from kcp-dev/api-syncagent

All issues in kcp-dev/api-syncagent

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.