Repo structure to host proposals, apis#119
Conversation
✅ Deploy Preview for kube-agentic-networking ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: HarshithaMS005 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @HarshithaMS005. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
LiorLieberman
left a comment
There was a problem hiding this comment.
Looks great to me overall, left a few small nits. Thank you @HarshithaMS005 !
|
/ok-to-test |
chuangw6
left a comment
There was a problem hiding this comment.
Thank you @HarshithaMS005 for your contribution!
|
Thanks @HarshithaMS005! ping me when you had a chance to fix the comments and I will approve |
b1f44fb to
077bbe4
Compare
|
@LiorLieberman I have made necessary changes as per the comments please review. |
|
Hi @LiorLieberman , Can you please review this PR ? I have made necessary changes. |
Signed-off-by: Harshitha MS <harshitha.ms@ibm.com>
077bbe4 to
61007f0
Compare
|
/assign @robscott can you take a look? |
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
robscott
left a comment
There was a problem hiding this comment.
Thanks for the great work on this @HarshithaMS005! While there's a lot of really great content in here, I'm worried that some of it will become stale since the project is still moving pretty quickly. Have recommended omitting some portions of this for now and revisiting as the project and APIs stabilize a bit more.
| @@ -0,0 +1,60 @@ | |||
| # Repository structure | |||
There was a problem hiding this comment.
While I see the value in a doc like this, unfortunately I think it would go stale very quickly, especially with such a relatively young project. Mind leaving this out of this PR?
| | Proposal | Description | | ||
| |----------|-------------| | ||
| | [0008-ToolAuthAPI.md](0008-ToolAuthAPI.md) | Tool Authorization API | | ||
| | [0017-DynamicAuth.md](0017-DynamicAuth.md) | Dynamic Auth | | ||
| | [0059-AccessPolicyTargetRefs.md](0059-AccessPolicyTargetRefs.md) | AccessPolicy TargetRefs | |
There was a problem hiding this comment.
I think this is very useful to have, but again very worried about it going stale. Maybe we could autogenerate the list here? For example, Gateway API autogenerates this list for GEPs, but it does admittedly rely on a GEP metadata file. We could potentially copy most of this over, but that may be better for a standalone PR since it could get quite large: https://github.com/kubernetes-sigs/gateway-api/blob/main/tools/geps/main.go.
| @@ -0,0 +1,38 @@ | |||
| # API design | |||
|
|
|||
| This document describes the design of the project’s custom APIs and how they fit with the Gateway API. | |||
There was a problem hiding this comment.
| This document describes the design of the project’s custom APIs and how they fit with the Gateway API. | |
| This document describes the design of the project’s custom APIs and how they fit with the Gateway API. Note that this API is still in an early alpha state and could still change significantly. |
| - **XBackend** — describes a backend (e.g. an MCP server) that HTTPRoutes can reference via BackendRef. | ||
| - **XAccessPolicy** — describes who can access what: it targets one or more XBackends and defines rules (sources and authorization) that the data plane enforces. | ||
|
|
||
| Type definitions and generated code live under [`api/`](../../api/) and [`k8s/`](../../k8s/). For a short “what lives where” guide, see [repo_structure.md](repo_structure.md). |
| @@ -0,0 +1,38 @@ | |||
| # API design | |||
There was a problem hiding this comment.
Is this intended to be part of the website? If so, I'd recommend putting it in the site-src directory
|
|
||
| ## XBackend | ||
|
|
||
| An **XBackend** represents a backend that agents or tools call into—for example, an MCP server. It is namespaced and is referenced by HTTPRoute `BackendRef`s (and by XAccessPolicy targetRefs). The controller and translator use XBackends to configure the data plane (e.g. clusters, RBAC) so that traffic to that backend is correctly routed and authorized. |
There was a problem hiding this comment.
Recommend leaving out any implementation details here and just focusing on what the API does
| An **XBackend** represents a backend that agents or tools call into—for example, an MCP server. It is namespaced and is referenced by HTTPRoute `BackendRef`s (and by XAccessPolicy targetRefs). The controller and translator use XBackends to configure the data plane (e.g. clusters, RBAC) so that traffic to that backend is correctly routed and authorized. | |
| An **XBackend** represents a backend that agents or tools call into—for example, an MCP server. It is namespaced and is referenced by HTTPRoute `BackendRef`s (and by XAccessPolicy targetRefs). |
|
|
||
| ## XAccessPolicy | ||
|
|
||
| An **XAccessPolicy** is an authorization policy: it defines *who* can access *what* for the backends it targets. It targets XBackends via `targetRefs` and contains rules that describe allowed (or denied) sources and optional authorization (e.g. which tools or methods). The translator turns XAccessPolicy into data-plane configuration (e.g. Envoy RBAC) so that only allowed callers can reach the targeted backends. |
There was a problem hiding this comment.
| An **XAccessPolicy** is an authorization policy: it defines *who* can access *what* for the backends it targets. It targets XBackends via `targetRefs` and contains rules that describe allowed (or denied) sources and optional authorization (e.g. which tools or methods). The translator turns XAccessPolicy into data-plane configuration (e.g. Envoy RBAC) so that only allowed callers can reach the targeted backends. | |
| An **XAccessPolicy** is an authorization policy: it defines *who* can access *what* for the backends it targets. It targets Gateways or XBackends via `targetRefs` and contains rules that describe allowed (or denied) sources and optional authorization (e.g. which tools or methods). |
| Key design points: | ||
|
|
||
| - One XBackend per logical backend (e.g. one MCP server). | ||
| - Backend identity can be specified by Kubernetes Service name (in-cluster) or by hostname (external). | ||
| - The data plane uses XBackend to know where to send traffic and how to secure it (e.g. mTLS, path). |
There was a problem hiding this comment.
These details feel like they could become stale pretty quickly, recommend omitting.
| Key design points: | ||
|
|
||
| - Targets one or more XBackends via `targetRefs`. | ||
| - Rules combine a source (e.g. service account, namespace) with optional authorization (e.g. allowed tools/methods). | ||
| - If no XAccessPolicy targets an XBackend, the data plane does not enforce RBAC for that backend (allow-all behaviour). If at least one XAccessPolicy targets it, the translated rules are enforced. |
There was a problem hiding this comment.
These details could become stale pretty quickly, recommend omitting.
|
@HarshithaMS005: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Added repo-structure documentation so contributors know where to find and add proposals, APIs, and docs. It adds docs/REPO_STRUCTURE.md, docs/api/README.md (API types, CRDs, clients, and relation to Gateway API), updates docs/proposals/README.md, and updates the main README with links to proposals, APIs, and the structure doc. This gives a single place to look for layout and contribution conventions.
Which issue(s) this PR fixes:
*Automatically closes linked issue when PR is merged.
Fixes #14
Does this PR introduce a user-facing change?: