add security self-assessment for project kcp - #2209
Conversation
github-actions
Bot
added
needs-triage
github-actions
Bot
added
the
needs-group
Signed-off-by: Simon Bein <simontheleg@gmail.com> Co-authored-by: Marvin Beckers <mail@embik.me>
evankanderson
added
tag/security-and-compliance
JustinCappos
left a comment
JustinCappos
left a comment
There was a problem hiding this comment.
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.
|
|
||
| #### kcp Server Components | ||
|
|
||
| * **Workspaces**: The primary user-facing unit of tenancy and isolation. From a user's perspective, a Workspace is a fully-isolated, Kubernetes-like cluster with its own unique API endpoint, CustomResourceDefinitions (CRDs), and RBAC policies. |
There was a problem hiding this comment.
Can you explain more about how this is isolated from other actors? How does one interface with this in a trustworthy manner?
|
|
||
| * **Workspaces**: The primary user-facing unit of tenancy and isolation. From a user's perspective, a Workspace is a fully-isolated, Kubernetes-like cluster with its own unique API endpoint, CustomResourceDefinitions (CRDs), and RBAC policies. | ||
|
|
||
| * **Logical Clusters**: The underlying implementation construct for a Workspace. A logical cluster is a logical partition within the kcp data store (etcd), ensuring that objects from different workspaces are stored in disjoint key prefixes, which is the primary mechanism for enforcing isolation. The goal is to make creating a logical cluster as cheap and fast as creating a Kubernetes namespace. |
There was a problem hiding this comment.
Do you have other performance / side channel concerns as a result? (This likely goes in non-goals for your system as well.)
There was a problem hiding this comment.
I am a bit stuck, English is not my native language: What is meant by "side channel concerns" in this context?
There was a problem hiding this comment.
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.
|
|
||
| * **Virtual Workspaces**: Endpoints that provide a Kubernetes-like API interface, but are not backed by a logical cluster for storage. They provide a computed "view" of certain resources across logical clusters. The exact semantics depend on the virtual workspace implementation, different virtual workspace endpoints provide different views according to their role. Access to virtual workspace endpoint is guarded by RBAC. | ||
|
|
||
| * **Shards**: A running instance of the kcp server process. Each shard hosts a set of logical clusters, and a full kcp installation can be composed of many shards to achieve horizontal scalability. |
There was a problem hiding this comment.
How are these coordinated? Are these trusted by other shards? What happens if a shard is compromised / buggy?
|
|
||
| ##### kcp Components | ||
|
|
||
| * **kcp**: The `kcp` binary provides the means to run a kcp shard (see above). It can either be launched completely standalone and then embeds a "mini" front-proxy, virtual-workspaces and a cache-server to run a fully functional kcp instance, or be run just to serve API endpoints and run controller loops. |
There was a problem hiding this comment.
Is this a trusted component? How does this auth?
There was a problem hiding this comment.
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.
|
|
||
| kcp provides resources dedicated to managing available APIs in a Workspace. | ||
|
|
||
| * **APIExport**: Allows a service provider in one workspace to publish an API for consumption by other workspaces. |
There was a problem hiding this comment.
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?
|
|
||
| #### Security Goals | ||
|
|
||
| * **Strict Workspace Isolation:** Ensure that tenants in one Workspace cannot see, access, or affect resources in another Workspace unless explicitly authorized. This is the core security boundary of the system. |
There was a problem hiding this comment.
I think performance interference + side channels are likely out of scope
Signed-off-by: Simon Bein <simontheleg@gmail.com>
|
I have added some of the requested info and bundled it in a separate commit for easier review: |
4 participants
add security self-assessment for project kcp
moved per request from #1815 (comment)