Allow a Harness to reference a Substrate WorkerPool in another namespace (cross-namespace workerPoolRef)

未关闭
  • 哪里不对？
#3,240 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@hsteude 已经在做这个了。

开始于 2026年11月10日。

  • #3631 来自 @hsteude —— 未关闭

评估

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

调研方向

Start from the Harness.spec.substrate.workerPoolRef field in the api.kagent.dev/v1alpha3 CRD, which today is a LocalObjectReference resolved in the Harness's own namespace. The issue has no agreed design: it proposes an optional namespace plus either a WorkerPool allowedNamespaces selector or a ReferenceGrant-style grant. Done means a maintainer-approved mechanism exists first, then the reference, authorization and credential-namespace scoping are implemented.

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

描述

Summary

Harness.spec.substrate.workerPoolRef (api.kagent.dev/v1alpha3, kagent 1.0.0-alpha13) is a LocalObjectReference. The CRD describes it as "a WorkerPool in the resource's namespace". As a result, every namespace that runs an Agent also needs its own Substrate WorkerPool, and the worker pods run in that namespace.

We'd like the option to point a Harness at a WorkerPool in another namespace. This would be opt-in, and the pool owner would control which namespaces may use it.

Why it matters (multi-tenant clusters)

The worker (ateom) container needs far more than PodSecurity baseline allows. Here is the pod we run on Substrate 0.5.0-alpha2:

{"runAsUser":0,"capabilities":{"add":["NET_ADMIN","SYS_ADMIN","SYS_CHROOT","SYS_PTRACE","SETUID","SETGID","SETPCAP","DAC_OVERRIDE","FOWNER","CHOWN","MKNOD","NET_RAW","SETFCAP"],"drop":["ALL"]},
 "seccompProfile":{"type":"Unconfined"},"appArmorProfile":{"type":"Unconfined"}}

That is expected, since the worker execs gVisor itself. It does mean that in a cluster where tenant namespaces enforce baseline, which is the normal posture for namespaces whose content tenants control, there is no place to put a tenant's Agents. Today the options are:

  1. Relabel every tenant namespace privileged. This weakens the boundary for everything else in that namespace, so it would need an extra ValidatingAdmissionPolicy to pin the worker image and ServiceAccount.
  2. Run all Agents in one platform namespace. This loses per-tenant RBAC, quotas, NetworkPolicy and Secret scoping for the Agent objects.

What we want instead: Agents, Harnesses and AgentTemplates in the tenant namespace (baseline), and workers in a platform-owned, privileged sandbox namespace per tenant, for example one per org.

Proposal

  • Add an optional namespace to workerPoolRef. It defaults to the Harness's namespace, so nothing changes for existing users.
  • Authorise cross-namespace references on the pool side, so a tenant cannot claim someone else's pool. For example, a WorkerPool field allowedNamespaces / a namespace selector, or a Gateway-API-style ReferenceGrant.
  • Define what scopes to which namespace:
    • The actor and session stay attributed to the Harness/Agent namespace (the atespace).
    • The credential-provider namespace policy is keyed on that namespace, not the pool's.
    • The snapshot location stays per Harness.

Context

  • kagent 1.0.0-alpha13 + Substrate 0.5.0-alpha2 on EKS 1.37, in production since 2026-10-16.
  • Related: https://github.com/kagent-dev/kagent/issues/3139 (worker capabilities/seccomp not configurable). Making those configurable would narrow the gap, but SYS_ADMIN + Unconfined can never pass baseline, so the placement question stays open.

Happy to contribute the change if the direction is acceptable.

主要语言
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 摘要。