add security self-assessment for project kcp

[SimonTheLeg]

add security self-assessment for project kcp

moved per request from #1815 (comment)

[JustinCappos]

This looks pretty good. Can you address the comments I have and integrate those into the text (not just reply to my comments)?

I think this will be ready to merge soon.

[JustinCappos]

Can you explain more about how this is isolated from other actors? How does one interface with this in a trustworthy manner?

[JustinCappos]

Do you have other performance / side channel concerns as a result? (This likely goes in non-goals for your system as well.)

[SimonTheLeg]

I am a bit stuck, English is not my native language: What is meant by "side channel concerns" in this context?

[JustinCappos]

Sorry for being unclear. There is a type of attack where two things (processes, containers, etc.) running on the same hardware can interfere with each others performance or read information about what computation another process is doing because they share the same hardware. I was just wondering if this vector is a concern here. I assume you consider this to be out of scope.

[JustinCappos]

How are these coordinated? Are these trusted by other shards? What happens if a shard is compromised / buggy?

[JustinCappos]

Is this a trusted component? How does this auth?

[SimonTheLeg]

The single binary is mainly a convenience option for quickstarts and local development. It runs all the components in a single binary and uses loopback and a fixed token for authn and authz. But it is not meant to be run in production.

Under these circumstances, should we remove the single binary part? In production the mentioned components would be run individually.

[JustinCappos]

What if the same API is published for consumption by different parties? Is this namespaced somehow? If so, how is the namespacing securely defined / allocated? If not, what happens if there is a conflict?

[JustinCappos]

I think performance interference + side channels are likely out of scope

[SimonTheLeg]

I have added some of the requested info and bundled it in a separate commit for easier review: 4b0a794 (this PR) or added some follow up questions into the discussion. ptal

[evankanderson]

@realshuting and @JustinCappos - I think the ball is in your court.

[Santoshkumarpuppala]

Thanks for putting this together — the structure is solid and the Actors section is unusually clear about what kcp is and isn't, which makes the boundaries much easier to reason about than most self-assessments.

I read it with one narrow lens, and it's the one I'd offer as the general suggestion: for each isolation boundary the document claims, does it name the single server-side point that enforces it, and what would a negative test look like — a request that should be refused, and is. The goals are described well throughout; the enforcement points and the negative tests are the thin parts, and they're where a reader's confidence actually comes from.

One observation first, because I think it's the most useful thing I can hand back. The two advisories listed under Known Issues land exactly on the two boundaries this document describes least concretely:

GHSA-w2rr-38wv-8rrp (unauthorized create/delete in arbitrary workspaces through the APIExport Virtual Workspace) maps onto the Virtual Workspace Isolation section, which is written as a requirement ("it is therefore critical that virtual workspace implementations properly isolate requests... and use proper impersonation and/or enhanced authN/authZ checks") rather than as a description of what enforces it.

GHSA-c7xh-gjv4-4jgv (impersonation allows access to global administrative groups) maps onto impersonation, which appears once in the document — as a suggested mitigation inside that same section — and is never listed as a security-relevant feature with a guard of its own.

That's the project's own incident history pointing at which boundaries need naming. I'd suggest linking Known Issues back to the relevant boundary sections rather than leaving them as a standalone appendix list, so a reader can see "this boundary failed once, here is what enforces it now."

Specific spots, in rough priority order:

1. Workspace Isolation — the assessment says logical clusters store objects "in disjoint key prefixes, which is the primary mechanism for enforcing isolation." Disjoint storage prefixes are a storage property; they prevent collision and accidental cross-reads, but they aren't what refuses a request. Since the workspace is derived from the URL path, the reader's real question is: when a user with valid credentials changes the path to a workspace they have no access to, which component denies it — the front-proxy, the shard's authorizer, or per-workspace RBAC — and at what point in the request chain? Naming that one component (and stating that the path is untrusted input) would do a lot for the "core security boundary."

2. Virtual Workspace Isolation — this is the section I'd most want expanded, both because the document itself flags it as critical and because of GHSA-w2rr-38wv-8rrp. It notes these components "often have to run with administrative permissions." Two things would help: whether isolation is enforced centrally or is each implementation's own responsibility (if the latter, that's N enforcement points rather than one, and worth saying plainly), and what a new virtual workspace implementation is required to do before it ships. A checklist item is more durable than an adjective.

3. Impersonation — given the prior advisory, I'd list it as a security-relevant feature in its own right: what restricts which users/groups can be impersonated, and specifically what prevents impersonating global administrative groups.

4. Administrative Wildcard Requests — this appears under Actions as an endpoint that lists resources across all logical clusters, "bypassing standard workspace isolation for operational purposes." An explicit, documented isolation bypass belongs in Security Functions with its guard named: who is authorized, what refuses everyone else, and whether use is audited.

5. Permission Claims and Maximal Permission Policy — both are described as consent/upper-bound mechanisms, which is the right design. What's missing is what evaluates them at request time. For PermissionClaims: what refuses a provider access that exceeds what the consumer accepted? For maximalPermissionPolicy: where is the intersection with the consumer's own RBAC computed? These read as declarations today; naming the evaluator makes them controls.

6. APIExport identity — the identity hash is described as part of the etcd storage path, "ensuring complete data segregation." Same distinction as (1): that segregates data at rest. Is the identity also verified on the request path, so a request referencing another provider's identity is refused rather than simply missing its data?

7. Cross-workspace binding — "guarded by RBAC checks" is the right answer; naming the specific verb and resource (which side the check runs on, provider or consumer) would make it verifiable by a reader.

8. Shard trust — each shard gets a client certificate at startup and shards self-register with the root shard via bootstrap credentials. The document addresses malfunctioning shards ("functionality of functioning shards is not affected"), which is an availability property. The authorization question is different: is a shard's identity scoped to the logical clusters it hosts, or can any authenticated shard assert authority over any logical cluster? Worth stating explicitly whether shards are inside the trust boundary by design — that's a legitimate design decision, it just needs to be visible.

Two smaller things:

The Integration Tests section describes CI coverage generally. Given the two known advisories, it would be worth saying whether security regression tests are pinned to them specifically — that's the "negative test" question in its most concrete form, and it's the single strongest signal that a fixed boundary stays fixed.

There's no explicit attacker model. The Security Goals are clear about what should hold, but not about what the adversary is assumed to be able to do — an authenticated tenant in a neighbouring workspace, a malicious API provider, a compromised shard. Even a short paragraph would make the rest of the document easier to evaluate, because most of the questions above resolve once the assumed adversary is stated.

None of this is a finding — it's all "the document asserts a boundary and I can't tell from the text what enforces it." Happy to be pushed back on any of it, especially where the answer is obvious to people who work in the codebase daily and just didn't need writing down.