背景:原先的各模型提供商的API Key是直接配置在openclaw.json中的,但这样不安全,因为所有的Agent可以读取openclaw.json的文件内容,但你方环境变量中其实也不安全,或者是你放在服务的配置中也不安全,agent都可以读到这些文件,哪里有安全的方式?
方式,密钥落地,谁能读到,安全等级
1、明文写 openclaw.json,明文文件,所有能读配置的 Agent / 工具,最低(告警就是因为这个)
2、你手动 export 全局变量,内存 + 可能写进 shell 配置,所有进程 / 所有用户(如果权限不严格),低
3、openclaw secrets configure(env 模式),存在 OpenClaw 内部加密存储,只有 OpenClaw 网关进程内部可见;技能能读,但不是全局,中(比上面安全)
4、file / exec provider,加密文件 / 外部 vault,可控权限,网关按需解密,高(生产推荐)
用第3种方式:但这种方式目前只有env模式,未实际解决安全问题,实际上还是把API Key存在环境变量里面,多绕了个圈,暂时不考虑。
目前先简单点,在openclaw.json中不写明文,直接引用环境变量。
改了之后,openclaw服务起不来,原因是用户级的systemd在启动服务的时候,不会去读用户会话层的环境变量,这导致了gateway启动失败。
解决方案:
网关起不来,看状态,能看到最直接的原因:
systemctl --user status openclaw-gateway.service
接着:
1、先看当期作为系统服务的openclaw-gateway.service 能拿到哪些变量?
systemctl --user show openclaw-gateway.service --property=Environment
发现没有我们要在openclaw.json用的那些 API KEY的变量。
2、systemctl --user cat openclaw-gateway.service 命令可以看openclaw-gateway.service 的具体内容。
3、systemctl --user edit --full openclaw-gateway.service 可以编辑service文件,把我们的API KEY都作为环境变量输入进去
4、重载并重启
systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
5、再检查 openclaw status --all , 可以看到gateway 好了,reachable