Context
Follow-up to #7 (discover ingestor SA from the ingestionAuthz ConfigMap; drop --ingestor-sa), shipped in #176 and bundled into the develop→main release #164. Surfaced again by Cursor Bugbot on #164 (learned rule: "SA discovery from ingestionAuthz ConfigMap must stay best-effort and handle multi-SA policies").
Problem
cluster.discoverIngestorSAName (internal/cluster/discover.go) selects the ingestor SA only when the namespace maps to exactly one distinct service_account. When the ingestionAuthz.allowed[] policy names multiple SAs in the same namespace scoped by table_prefixes (a supported chart configuration — see tracebloc/client templates/ingestion-authz-configmap.yaml), discovery treats it as ambiguous and falls back to the chart default ingestor.
Since --ingestor-sa was removed from data ingest / cluster info, a multi-SA deployment then:
- mints a token for
ingestor, which may not be in the policy at all → jobs-manager rejects the submit (auth/RBAC), and
- runs stage/teardown pods under the wrong SA,
with no CLI workaround.
This is a deliberate tradeoff accepted for the #164 release (the common single-SA case works; ambiguous → safe default). This ticket tracks the proper fix.
Proposed fix
Make ingestor-SA discovery table-aware for the paths that know the target table (data ingest, data delete):
- Among
allowed[] entries for the mint namespace, pick the SA whose table_prefixes match the target table (longest-prefix / unique match).
- Keep the current "exactly one, else default" behavior for
cluster info (no specific table).
- Stay best-effort: never error; fall back to the default when no entry matches.
Likely touches: thread the table into DiscoverParentRelease → discoverIngestorSAName (or do SA selection at the ingest/delete call site where the table is known), plus tests for the multi-SA-per-namespace + prefix-match cases.
Acceptance criteria
- A policy with two SAs in one namespace scoped by distinct
table_prefixes selects the correct SA for a given target table on data ingest and data delete.
cluster info behavior unchanged.
- No regression to the single-SA and no-ConfigMap (default
ingestor) paths.
Refs: #7, #176, #164, Bugbot BUG_ID a4591cf1-14bd-4a40-b312-2a4fb1db6991
Context
Follow-up to #7 (discover ingestor SA from the ingestionAuthz ConfigMap; drop
--ingestor-sa), shipped in #176 and bundled into the develop→main release #164. Surfaced again by Cursor Bugbot on #164 (learned rule: "SA discovery from ingestionAuthz ConfigMap must stay best-effort and handle multi-SA policies").Problem
cluster.discoverIngestorSAName(internal/cluster/discover.go) selects the ingestor SA only when the namespace maps to exactly one distinctservice_account. When theingestionAuthz.allowed[]policy names multiple SAs in the same namespace scoped bytable_prefixes(a supported chart configuration — seetracebloc/clienttemplates/ingestion-authz-configmap.yaml), discovery treats it as ambiguous and falls back to the chart defaultingestor.Since
--ingestor-sawas removed fromdata ingest/cluster info, a multi-SA deployment then:ingestor, which may not be in the policy at all → jobs-manager rejects the submit (auth/RBAC), andwith no CLI workaround.
This is a deliberate tradeoff accepted for the #164 release (the common single-SA case works; ambiguous → safe default). This ticket tracks the proper fix.
Proposed fix
Make ingestor-SA discovery table-aware for the paths that know the target table (
data ingest,data delete):allowed[]entries for the mint namespace, pick the SA whosetable_prefixesmatch the target table (longest-prefix / unique match).cluster info(no specific table).Likely touches: thread the table into
DiscoverParentRelease→discoverIngestorSAName(or do SA selection at the ingest/delete call site where the table is known), plus tests for the multi-SA-per-namespace + prefix-match cases.Acceptance criteria
table_prefixesselects the correct SA for a given target table ondata ingestanddata delete.cluster infobehavior unchanged.ingestor) paths.Refs: #7, #176, #164, Bugbot BUG_ID a4591cf1-14bd-4a40-b312-2a4fb1db6991