Fulling 的 Kubernetes 凭据边界设计：一个 AI 全栈工程师代理的基石
Fulling is an AI-powered Full-stack Engineer Agent. Built with Next.js, Claude, shadcn/ui, and PostgreSQL. Use kubernetes as infra.
秒懂
- 它是什么？
- Fulling 是一个基于 Next.js 和 Claude 的 AI 全栈工程师代理，当前版本聚焦于身份与 Kubernetes 凭据边界。本文解析其架构、运行方式与安全取舍。
- 适合谁用？
- Fulling 适合需要为 AI 代理提供持久工作区，并愿意接受 Kubernetes 凭据明文存储风险的开发团队。不适合对凭据安全要求极高、或需要多用户细粒度权限隔离的场景。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 30 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个为 AI 代理准备的 Kubernetes 凭据边界
Fulling 自称是 AI 驱动的全栈工程师代理，但 v3 基础版本的实际交付物并非一个能自动写代码的完整代理。它更像一个地基：GitHub 登录、PostgreSQL 存储、以及一个用户级的 Kubernetes 凭据边界。README 明确指出，这个基础版本是为未来的 Workspace 模型提供身份和凭据边界。换句话说，你现在拿到的是骨架，不是成品。适合的受众是那些想自己搭建 AI 编程环境，并且需要控制代理访问 Kubernetes 资源的团队。
从 GitHub 登录到 SelfSubjectReview 的验证链
登录流程只支持 GitHub，通过 Better Auth 实现。每个用户对应一个明文 kubeconfig，存储在 PostgreSQL 中。关键的安全机制是验证环节：系统调用 Kubernetes 的 SelfSubjectReview API，确认这个 kubeconfig 对应的身份是真实有效的。验证过程会拒绝多种危险配置，包括可执行凭据插件、auth-provider 插件、本地文件凭据字段、代理设置、非 HTTPS 的 API 服务器、重定向以及匿名身份。但 README 也承认，通过验证的用户仍然可以指向任何网络地址上的 HTTPS API 服务器，这意味着 SSRF 风险是设计上接受的。
本地开发与部署：两条路径的差异
本地开发有两种模式。第一种是直接运行 npm ci 和 npm run dev，启动的是公开应用，登录被禁用，不需要数据库。第二种是复制 .env.template 到 .env.local，填入数据库、Better Auth 和 GitHub 的值，再运行 npm run prisma:migrate 和 npm run dev，才能体验带认证的工作区。注意，这个版本使用新的基线 schema，不会迁移 v2 数据，必须用新数据库或明确重置过的数据库。部署到 Vercel 时，公开应用可以零配置构建，但 GitHub 登录和 kubeconfig 相关流程会保持禁用，直到完整的遗留配置出现。
明文 kubeconfig 的存储取舍
kubeconfig 以明文形式存在 PostgreSQL 里，这是 README 直接承认的事实。数据库读取权限等于 Kubernetes 凭据访问权。作为补偿，浏览器端 API 从不返回保存的内容，日志也被禁止包含 token、密钥、证书或 kubeconfig 内容。这个设计把安全重心完全压在数据库访问控制上。对于生产环境，这意味着一旦数据库被拖库，攻击者直接获得所有用户的集群凭据。如果你所在的组织对凭据存储有合规要求，这个设计可能一开始就不合适。另一个隐含问题是，每个用户只有一个 kubeconfig，没有细粒度的 RBAC 映射，多租户隔离完全依赖外部集群配置。
v2 到 v3 的断裂式升级
Fulling 的版本演进不是平滑的。v1.0.0 是 MVP，v2.0.0 在 2026 年 5 月发布，但 v3 基础版本（当前 main 分支）明确不包含对前代产品模型或认证系统的兼容层。升级意味着重置数据库，而且重置 Fulling 数据库不会删除 v2 创建的 Kubernetes 资源。仓库提供了 docs/v2-resource-inventory.md 来指导部署重置，但这个过程是手动的。如果你正在运行 v2，升级前必须盘点所有集群资源，否则会留下孤儿资源。这种断裂式设计简化了代码，但把迁移成本转嫁给了使用者。
替代方案的差异：从零搭建与托管平台
如果你不想接受 Fulling 的明文存储和单用户 kubeconfig 模型，可以考虑自己用开源组件搭建。核心区别在于，Fulling 把凭据边界内建到应用层，而自建方案通常依赖 Kubernetes 原生的 ServiceAccount 和 RBAC。例如，你可以用 Next.js 加 Better Auth 实现 GitHub 登录，然后用 Kubernetes 的 TokenRequest API 为每个用户动态生成短时 token，而不是存储静态 kubeconfig。这样避免明文长期凭据，但你需要自己实现 token 刷新和代理逻辑。Fulling 的 SelfSubjectReview 验证是静态检查，无法处理凭据轮换，所以自建方案在安全性和灵活性上更有优势，代价是更多的工程工作。
维护成本与许可证考量
项目采用 MIT 许可证，这对商业使用友好，没有 copyleft 约束。维护成本集中在几个方面：Prisma schema 变更需要手动运行迁移，且基线迁移不兼容旧数据；Node.js 版本要求严格，必须是 24 及以上，包括其内置的 npm 11，环境升级可能带来兼容性问题。测试命令覆盖 Vitest 和 Playwright，但 README 没有提供测试覆盖率的数字，所以无法判断测试的充分性。另外，v3 的架构文档指向 docs/architecture.md，但实际内容未提供，未来的 Workspace 模型细节仍不透明。如果你计划长期依赖，需要自己补读文档并跟踪每次提交的变化。
编辑结论
Fulling 适合需要为 AI 代理提供持久工作区，并愿意接受 Kubernetes 凭据明文存储风险的开发团队。不适合对凭据安全要求极高、或需要多用户细粒度权限隔离的场景。采用前应验证 kubeconfig 校验逻辑是否覆盖所有拒绝条件，并确认数据库访问控制足以保护明文凭据。当前版本不迁移 v2 数据，升级需明确重置流程。
社区笔记