Reaching burrowd grants burrowd's permissions, not the caller's

[incognick]

TL;DR

Reaching burrowd is the whole grant. burrowd acts as itself, not as the caller — so a person whose kubeconfig is read-only in an app namespace can write it through burrowd.

• Contained, and deliberately: burrowd's write is namespaced, its ClusterRole is read-only, and it holds zero rbac.authorization.k8s.io grants, so it cannot escalate itself or grant anyone anything.
• Still a confused deputy. Kubernetes RBAC stops being the ceiling the moment a caller goes through burrowd.
• A security review would flag this. Not the current ICP — filed so it is a decision rather than a discovery.

What I need from you

Nothing. Recorded for when enterprise becomes real.

---

What burrowd actually holds

Every Role and ClusterRole in cmd/burrow/manifests/install.yaml.tmpl:

Grant	Scope	Notable
burrowd-builds	namespaced	jobs create/delete, pods + logs read, secrets get/create/delete
burrowd-addons	namespaced	deployments/services/PVCs/configmaps full write, secrets get/create/update/delete, CNPG clusters and backups
burrowd-credentials	namespaced	get/update on one named Secret
burrowd-cluster-capabilities	cluster	get/list only — nodes, pods, storageclasses, ingressclasses, deployments

Two properties worth stating because they are better than they need to be:

• No rbac.authorization.k8s.io anywhere. No roles, no clusterroles, no bindings, at any scope. burrowd cannot widen its own access and cannot grant access to anyone. Whatever else is true, privilege escalation through burrowd's own RBAC is not available.
• The cluster-scoped grant is genuinely read-only, with no secrets in it.

So the blast radius is the four namespaces Burrow owns, which is the containment the design intends.

The problem an auditor will name

The caller's identity is used to reach burrowd and then discarded.

services/proxy RBAC decides whether you may reach the burrowd Service. That is binary. Once through, every action runs under burrowd's ServiceAccount — so the effective permission of any caller is burrowd's, not their own.

Concretely: a person granted read-only access to an app namespace, who can also reach burrowd, can deploy to that namespace, read its Secrets, and delete its workloads. Their kubeconfig forbids all three. Nothing in Kubernetes' authorization model is consulted for the operation itself.

Guardrails are the only thing that narrows it, and they narrow burrowd's ceiling rather than raising a floor under each caller. That is a different guarantee from the one an enterprise expects, which is:

whatever Burrow lets me do is a subset of what my Kubernetes RBAC already lets me do

That statement is false today, and it is the statement a reviewer will test.

Why it is like this

The API-server proxy authenticates the caller and then makes a plain request to burrowd, forwarding no identity. burrowd cannot learn who was just authenticated even if it wanted to. So acting as the caller is not a matter of reading a header — it requires burrowd to impersonate, which means holding impersonate on users and groups.

That grant is close to become anyone, and it is exactly what a platform team refuses. Trading a namespaced ServiceAccount for cluster-wide impersonation makes the audit worse, not better, even though it makes the model more honest.

Options, none of them free

Impersonation. burrowd acts as the caller, so RBAC becomes the real ceiling and the enterprise statement above becomes true. Costs a very powerful grant and an argument with every platform team. Also breaks the parts of Burrow that legitimately act on their own behalf — reconciliation, the auto-deploy poller, anything unattended has no caller to impersonate.

A per-principal ceiling recorded in Burrow. With ADR-0084's principal table, Burrow could record what each principal may do and refuse beyond it. Honest about what it is — Burrow's own authorization, not Kubernetes' — and does not pretend to inherit RBAC. Cheaper, and it is a second thing to keep in agreement with the cluster.

Accept and document. State plainly that reaching burrowd grants burrowd's permissions within the namespaces Burrow owns, and that Burrow's RBAC is the boundary rather than the caller's. Correct, and it is the answer that gets written down rather than discovered.

A SubjectAccessReview pre-check. Before acting, burrowd asks the API server whether the caller would be allowed. Needs the caller's identity, which the proxy does not forward — so it only works if identity arrives another way, and it adds a round trip per operation.

Not now

The current ICP is a self-hoster who owns their cluster and holds admin on it. For them this is not a finding at all: burrowd's permissions and theirs are the same set.

It becomes real the first time somebody wants Burrow in an organisation where the person using it is deliberately not a cluster admin — which is the same population ADR-0084 exists to serve. Worth revisiting when that stops being hypothetical, and worth not claiming otherwise in the meantime.

Related

• ADR-0038 — the agent's scoped credential, which solves the adjacent and more urgent problem: an agent inheriting a high-privilege human's reach
• ADR-0019 — where the namespaced-write posture is described
• #450 — principals and admin, the seam a per-principal ceiling would attach to

[incognick]

Two things that change how urgent this is, and one caveat about all of it.

A dedicated cluster is the likely trial shape, and it mostly defuses this

An enterprise evaluating Burrow would not install it into an existing cluster. They would stand up a new one — companies at that size run hundreds or thousands of clusters, so another is routine rather than a project.

On a cluster dedicated to Burrow, the people using it are the team that owns it. burrowd's reach and theirs are the same set, so there is no gap for the deputy to be confused about. The scenario in the body above — read-only in an app namespace, writing it through burrowd — needs a shared cluster to exist at all.

It does not disappear. A team lead granting a colleague Burrow access without cluster admin recreates it inside the team, which is the same population ADR-0084 exists to serve. But it stops being an adoption blocker and becomes an internal-delegation question.

The target model holds up under this too, which was worth checking: a company has thousands of clusters, a team trying Burrow has one or two. Nobody's burrow auth status lists four hundred targets.

The likelier thing to lose an evaluation is admission, not RBAC

A new enterprise cluster is not a blank cluster. It comes off a platform template, and arrives with mandatory Kyverno or Gatekeeper policies, a service mesh injecting sidecars, PodSecurity enforced at a level the platform team chose, default-deny NetworkPolicies, and an image-registry allowlist.

Burrow then wants to run build pods under a gVisor RuntimeClass that may not exist there, create its own NetworkPolicies into namespaces whose defaults are already set, put PodSecurity labels on namespaces a policy engine is enforcing independently, pull from ghcr.io, and install CNPG and its CRDs — a cluster-scoped act a platform team may reserve to itself.

Any of those can be refused at admission. The failure would surface as a rejected manifest rather than a Burrow message, so the first experience of Burrow in an enterprise would be a Kubernetes error with no account of what Burrow wanted or why. That loses an evaluation faster than anything in this issue's body, and the fix is cheaper: a pre-flight in burrow cluster install that names what is missing before it starts applying.

The caveat, which is why neither of these is filed as work

All of this is guessing. Nobody has asked for Burrow in an enterprise, so every requirement above is inferred from how such organisations usually operate rather than from anything a real evaluator said. Building against inferred requirements is how you end up with the wrong abstraction defended by sunk cost.

Recorded here so the thinking is not lost and so the trade-offs are visible when it stops being hypothetical. The changes an actual enterprise needs will be knowable when one turns up, and are likely to differ from these in ways that matter.

[incognick]

Re-checked against main at fef77bf, because ADR-0097 now rests on the premise this issue disputes. The issue is not stale. It got more load-bearing, and there are two escapes in it that the body does not name — both about the agent rather than the human.

What is still true

burrowd still acts as itself, and the caller's identity still stops at the door. Every /v1 route resolves the caller from X-Burrow-Token alone (controlplane/api/identity.go:265), and nothing carries a Kubernetes subject: there is no impersonate verb anywhere in the tree, and no SubjectAccessReview.

The RBAC table in the body is accurate as written. Namespaced writes in the app namespace (cmd/burrow/manifests/approle.yaml.tmpl:12), the build namespace (cmd/burrow/manifests/install.yaml.tmpl:55), the add-on namespace (install.yaml.tmpl:106), get/update on one named Secret (install.yaml.tmpl:270), one read-only ClusterRole (install.yaml.tmpl:369). No rbac.authorization.k8s.io grant at any scope. The containment claim holds: burrowd cannot widen itself and cannot grant anybody anything.

Authentication is still binary for operations. A credential that authenticates reaches every route. The only authorization in the engine is the admin bit, and it answers exactly three questions — create a principal, issue a credential, revoke one (controlplane/authorize.go:37). There is no per-app, per-environment, or per-namespace authorization anywhere.

What is stale

"Not the current ICP" is the part that expired. The body reads as though a per-principal model is a future option; it shipped on 2026-08-09 (43aaf93). The shape the body calls hypothetical — somebody using Burrow who is deliberately not a cluster admin — is now the documented way to add a second person. burrow auth invite records them, they exchange it on their own machine (cmd/burrow/authinvite.go, controlplane/identity.go:205, :259), and the credential they carry means they never read the install Secret (connect/connect.go:166). Their entire cluster grant can be get/create on services/proxy for one Service. That is exactly the confused deputy the body says needs a shared enterprise cluster to exist — reachable now in a two-person self-host install, which is the install the feature was built for.

The premise is now written into the code. controlplane/guardrails.go:736 short-circuits user and machine to allow before any policy lookup, on the stated grounds that Kubernetes RBAC is the ceiling and anything refused there can be done with kubectl a second later. True of the operator who installed Burrow. False of an invited principal, whose RBAC is one proxy verb.

docs/HARDENING.md is behind main on two counts — it still documents --binds, which ADR-0097 removed, and still says Policy.enforce takes no caller. Separate from this issue, but it is the file a reader checks for this answer.

The actual exposure

For a caller whose entire cluster grant is reaching burrowd:

• deploy any image reference into any environment namespace (controlplane/api/api.go:86)
• run an arbitrary argv in the app's image and read the captured stdout (api.go:128, controlplane/results.go:168) — which is every value in the app's env Secret, plus whatever the app can reach on the cluster network
• write and unset app secrets and config (api.go:163, api.go:149)
• delete an app, detach or remove an add-on, restore a backup, run arbitrary SQL against an attached database (api.go:73, :268, :332, :353)
• register a vendor provider token (api.go:209)
• rewrite every guardrail disposition and every operational limit (api.go:182, api.go:207)
• read the audit log (api.go:396)

Bounded to the namespaces Burrow owns, as the body says. Within them it is total.

Two escapes the body does not name

1. guard set has no caller check at all. PUT /v1/guard/{code} (api.go:182) reaches Engine.SetGuardrail (controlplane/engine.go:2998), which validates the code, the disposition and the binding, and never asks who is calling. Keeping the verb off the burrow-agent binary is a surface control (ADR-0065 tier 1) and ADR-0084's Context already says a surface control is not a boundary — but two comments in the tree state it as one: controlplane/domain.go:367 ("that lever is on the operator CLI only, so relaxing it is a deliberate human act the agent cannot perform") and install.yaml.tmpl:309 ("the guardrails in burrowd become binding by construction"). The scoped credential confines the agent to burrowd; burrowd's API then hands it the policy table.

2. The credential kind can be laundered. An admin's agent credential belongs to the admin principal (controlplane/identity.go:167), and the admin bit is read from the principal row, never from the kind (controlplane/authorize.go:70). So on the ordinary single-operator install an agent credential can POST /v1/auth/invitations for a new principal and POST /v1/auth/redeem with the invitation it just received, ending with a non-expiring user credential (controlplane/identity.go:205, :259). Every disposition then resolves to allow at guardrails.go:736. HARDENING.md:177 already records the first half — an admin's agent credential is an admin's credential — but its guardrail consequence only arrived with ADR-0097.

The sharper statement of the hole is therefore not only that a person gets more than their RBAC. It is that the credential kind, the axis all the guardrail work now rests on, is reachable by the party being held.

What bounds a caller today, precisely

Mechanism	Constrains
Token / credential (api/identity.go:265)	who may call. Never what.
Credential kind (caller.go:69)	read only by the guardrail and the audit row (audit.go:161). Holds the agent, and only while the agent cannot obtain another kind.
Guardrail dispositions (guardrails.go:727)	what the agent may ask for. user and machine short-circuit to allow.
Operational limits (ADR-0068)	values, not callers — and settable by anyone authenticated (api.go:208).
Lock (api.go:120)	the object, every caller, explicitly not a security control.
Kubernetes RBAC	the route, and burrowd's own actions. Never the caller's operation.
Admin bit (authorize.go:37)	three identity-model verbs. The only per-caller authorization in the product.

Nothing in that table is a floor under a caller. Everything in it is a ceiling on burrowd or on the agent.

Options, and what each now costs

Impersonation costs more than it did when this was filed. ADR-0084 §2 deliberately decoupled Burrow identity from cluster identity, so an invited principal may have no Kubernetes subject to impersonate at all — nothing to act as, for exactly the population the option exists to serve. On top of the impersonate grant a platform team refuses, and the unattended paths (reconcile, the auto-deploy poller) that have no caller.

A SubjectAccessReview pre-check is the cheaper half of the same idea. create subjectaccessreviews is cluster-scoped but far weaker than impersonate — a SAR names a subject and asks a question, it does not act. It needs the same principal→subject mapping, so it has the same missing-subject problem, plus a round trip per operation, plus the fact that one Burrow operation is several Kubernetes verbs and a partial answer is worse than none.

Aggregation is the honest answer to "the proxy forwards no identity". An APIService registered through the aggregation layer does receive the caller as X-Remote-User/X-Remote-Group under the requestheader client CA — so the body's premise that identity cannot arrive is true of the service proxy and not true of Kubernetes. It buys a real caller identity for both options above, and costs an APIService registration, certificate plumbing, and giving up the property ADR-0014 chose the proxy for: connectivity that needs nothing. It still says nothing about a principal with no cluster identity.

A per-principal ceiling in Burrow is what the managed side already built. Honest about being Burrow's own authorization rather than an inheritance of the cluster's. The cost is a second model that can disagree with the cluster, and a design question nobody has answered: what its unit is — environment, app, or verb.

Fixing the agent half is cheap and independent of all of the above. Refuse guard set and the credential-minting routes to an agent credential. Small, local, and it restores the property ADR-0097 assumes rather than adding a model. It does nothing for the human question.

Accept and document is still available, but the sentence has changed. It is no longer "a self-hoster is their own admin, so this is not a finding". It is "an invited principal gets burrowd's namespaced reach regardless of what their kubeconfig permits, and the guardrails do not hold them".

The managed product

A category error there, deliberately. A tenant holds no cluster credential (cloud ADR-0006 §6); the boundary is the control plane's per-request tenant scoping (§5), and burrowd-cloud's credential is broad precisely because scoping, not RBAC, is the boundary. Both escapes above are closed on that side: PUT /v1/guard is refused as an absent route (internal/tenantguard/absent.go:85), an agent's confirm is stripped (internal/tenantguard/confirm.go), the kind comes from the cloud credential row (internal/tenantapi/router.go:235), and X-Burrow-Token is deleted before the request reaches the open-source handler (router.go:238) — so nothing an identity route minted could ever be presented. Those routes are inert there anyway: the cloud engine wires no token source (internal/tenantengine/factory.go:338), so a claim or an invitation returns ErrNotImplemented. Everything in this issue is a self-hosted question.

Not determined

• Whether any real install has a second principal yet. Nothing in the repository answers it.
• Whether the aggregation route works through this install shape. That needs a cluster; none was touched for this.
• What a per-principal ceiling's unit should be. A design question, not a finding.
• How much the laundering escape matters in practice, given that revoking a credential still has no CLI (HARDENING.md:166) — so today the answer to a laundered credential is rotating the install, which is the lever this record was supposed to replace.

Recommendation

Keep it open. Two things follow, and they are different sizes:

1. The agent half is a defect against an accepted record, not a future enterprise concern. ADR-0097 §1 says a disposition holds the agent; two routes let the agent stop being held. That wants a record and a fix.
2. The human half is the question this issue was filed for, and it is now reachable in a two-person self-host rather than hypothetical in an enterprise. It wants a decision — impersonation, aggregation, a Burrow-side ceiling, or a written acceptance — before anything else leans on "your RBAC is the ceiling".

Neither should be coded before the record exists.