[FEATURE] Webhook implementations of the controller's authorizer and egress policy compiler

未关闭
#3,326 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
go, kubernetes

调研方向

Start by reading the controller's app.Options extension points and the existing authorizer and egress compiler implementations referenced by issues #2658 and #3263. Then trace how authorization checks and compiled policies reach their current callers. Done means both opt-in webhook clients support the described request and response behavior, including failure handling; the issue leaves the compiler payload type unresolved.

由索引模型根据 Issue 内容生成。

描述

📋 Prerequisites
📝 Feature Summary

app.Options lets an embedding binary supply its own Authorizer (#2658) and egress policy compilers (#3263). Add opt-in webhook implementations of both, so a deployer can run that logic as a separate service and keep the stock controller image.

❓ Problem Statement / Motivation

Today the only way to use these extension points is to build your own controller binary around app.Run: pin a kagent commit, follow app.Run changes at each upgrade, and build and ship a separate controller image.

The gateway (extAuthz, as discussed in #1890) can't replace them:

  • Scope filters collection reads per namespace. A gateway can only refuse a whole call.
  • Check needs controller state, such as the namespace of the Agent a new Session runs on.
  • The egress policy is a Substrate proto sent to ate-api, not a Kubernetes object, so no admission webhook sees it.
💡 Proposed Solution

Two clients, off unless configured, similar to the Kubernetes authorization and admission webhooks:

  • Authorizer: POST each Check (principal, verb, resource) and Scope (principal, verb, resource type) to a URL, and read back allowed/denied or an AuthorizationScope. Cache decisions briefly. A webhook that doesn't answer is Unavailable, not PermissionDenied. The actor policy from #3282 still applies on top.
  • Egress compiler: POST the compiler input and the built policy to a URL, and read the policy back. Compilers already have no side effects and may run more than once, so this fits a webhook. A failed call fails that actor's start.

Open question: should the compiler webhook carry Substrate's proto as it is, or a kagent-owned type?

🔄 Alternatives Considered

No response

🎯 Affected Service(s)

Controller Service

📚 Additional Context

Related: #1270, #1890, #2658, #3263, #3282

🙋 Are you willing to contribute?
  • I am willing to submit a PR for this feature
主要语言
Go
星标
4.2k
派生
890
平均合并
1 天 6 小时
30 天内合并 PR
189

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

kagent-dev/kagent 的其他 Issue

查看 kagent-dev/kagent 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。