行业背景与痛点
当前多用户AI开发场景中，权限隔离一直是基础架构层面的核心难题。多数AI开发平台选择共享集群资源，通过应用层逻辑实现权限控制，一旦应用层出现漏洞，用户的核心开发资源将直接暴露。
部分平台尝试为每个用户单独分配独立集群，这种方案资源利用率极低，成本会提升数倍，无法支撑大规模的多用户场景。如果需要整合不同用户的技能模型、数据文件、运行脚本，还要兼顾数据持久化和运行时隔离，现有架构很少能给出兼顾成本和安全性的方案。
Fulling针对这一问题给出了一套全新的基础实现，重新定义了多用户AI工作空间的隔离模型，将权限边界下沉到Kubernetes层面，同时保持了单集群的资源利用率，其设计思路值得深入研究。
项目概述
Fulling是FullAgent团队开发的开源项目，核心目标是构建专属AI工作空间，这类工作空间属于持久化环境，整合了AI技能、数据文件、记忆模块、运行脚本和运行环境。当前发布的v3版本是整个产品模型的基础层，专注于提供身份管理和Kubernetes凭证隔离能力，为后续完整工作空间功能搭建底层框架。
技术架构深度分析
整体架构设计思路
v3版本没有直接推出完整的AI工作空间产品，而是优先搭建基础身份和权限边界，这种分层迭代的设计方式降低了早期开发的复杂度，也让底层能力可以单独被其他项目复用。项目明确不兼容旧版本的产品模型和认证体系，从v3开始使用全新的基线 schema，避免了历史代码包袱对架构演进的拖累，保证了设计的纯粹性。
项目的核心设计思路是将用户权限边界直接建立在Kubernetes层面，而不是在应用层做逻辑隔离。每个用户拥有独立的kubeconfig，所有对Kubernetes资源的访问都直接经过Kubernetes原生的认证体系校验，应用层不需要维护复杂的权限规则，也避免了应用层权限绕过的风险。
当前v3的用户级kubeconfig只是过渡方案，项目文档明确说明，最终的工作空间运行时所有权模型会进一步调整，当前基础层的设计保留了足够的演进空间。
技术选型分析
前端和应用层基于Node.js开发，要求使用最新的Node.js 24版本，搭配自带的npm 11，选择最新版本 runtime 可以直接使用很多原生的最新特性，不需要额外的转码和兼容处理，适合底层基础项目的迭代。
用户数据、第三方提供商账户和会话信息全部存储在PostgreSQL中，依托PostgreSQL的事务一致性和数据可靠性保证身份数据的安全，比使用轻量存储更适合多用户身份场景。认证环节使用Better Auth实现仅支持GitHub的登录体系，不需要自己从头开发OAuth流程，降低了认证模块的开发复杂度，也保证了认证流程的安全性。
凭证校验使用Kubernetes原生的SelfSubjectReview接口完成kubeconfig的有效性验证，不需要自己实现凭证解析和校验逻辑，完全依托Kubernetes原生能力，减少了项目自己的安全攻击面，也保证了校验逻辑的标准性。ORM层使用Prisma管理数据库schema，简化了数据库迁移和数据访问的开发流程。
核心功能详解
基于Better Auth的GitHub专属登录
该项目仅开放GitHub渠道的登录认证，依托Better Auth框架完成整个OAuth流程，不需要自行开发认证逻辑，简化了项目部署和维护成本。对于面向开发人员的AI工作空间场景，仅保留GitHub登录可以降低用户注册的门槛，也可以依托GitHub的身份体系减少垃圾账号注册。整个认证逻辑和用户身份体系深度绑定，所有后续权限都基于GitHub登录身份生成。
PostgreSQL持久化存储身份数据
所有用户信息、第三方提供商账户关联数据和会话信息都存储在PostgreSQL中，保证身份数据的持久化和一致性。PostgreSQL的ACID特性可以避免会话冲突、数据丢失等问题，适合存储核心的身份信息，相较于内存存储或者轻量NoSQL，数据可靠性更高。项目不强制公开应用必须配置PostgreSQL，仅在需要 legacy 认证工作空间时才要求配置，降低了体验项目的门槛。
受保护的应用工作空间入口
所有工作空间访问入口都经过身份校验，未通过认证的请求无法进入工作空间，从入口层面实现了基础的隔离防护。入口校验逻辑和底层Kubernetes凭证隔离形成双层防护，即使应用层入口出现绕过漏洞，底层Kubernetes的权限边界依然可以阻挡非法访问。这种分层防护的设计，提升了整体系统的安全性，不需要把所有安全逻辑都集中在应用层。
单用户独立明文kubeconfig
系统为每个用户生成单独的kubeconfig文件，每个用户的kubeconfig只对应自己的权限范围，用户可以直接使用原生kubectl或者Kubernetes客户端操作自己权限内的资源，不需要适配平台专属的客户端。这种设计对开发人员非常友好，符合开发人员的使用习惯，也不需要学习新的工具链。当前采用明文存储，后续会调整所有权模型，当前设计作为基础层验证了整体架构的可行性。
Kubernetes原生kubeconfig校验
所有kubeconfig的有效性校验都通过Kubernetes原生的SelfSubjectReview接口完成，不需要项目自行解析凭证或者做权限判断，整个校验过程由Kubernetes原生完成，安全性更高。依托Kubernetes原生能力减少了项目自身的代码量，也避免了自定义校验逻辑可能出现的安全漏洞。校验通过后才会允许用户使用Kubernetes客户端操作资源，保证了凭证的有效性。
用户级Kubernetes客户端边界
每个用户的Kubernetes客户端都在自己的权限边界内运行，只能访问自己权限范围内的Kubernetes资源，实现了单集群内的用户资源隔离。这种设计保留了单集群的资源利用率，不需要为每个用户单独开辟独立集群，大幅降低了多用户场景下的基础设施成本。用户资源的隔离由Kubernetes本身保证，隔离的可靠性远高于应用层逻辑隔离。
项目地址：https://github.com/fullstackagent/fulling
⭐ Stars：2446
🔍 来源：GitHub
Fulling is an AI-powered Full-stack Engineer Agent. Built with Next.js, Claude, shadcn/ui, and PostgreSQL. Use kubernetes as infra.
微信扫一扫，打赏作者吧～
网友评论