Posts

Dify 深度玩法（二）：云版还是自托管？部署决策与模型 Key 清单

Dify 深度玩法（二）：云版还是自托管？部署决策与模型 Key 清单

上一篇：Dify 适合做什么。 本篇回答第二个实际决策：在哪跑、接什么模型。

先澄清一个常见误解

很多人以为云版免费额度限制的是"调用量"。真实情况是：自带 API Key 的调用不消耗 Dify 的 message credits（credits 只在使用 Dify 内置供应商时消耗）。云版免费版（Sandbox）真正的瓶颈是：

维度云版 Sandbox（免费）自托管 Community
应用数5 个不限
知识库50 篇文档 / 50 MB取决于你的磁盘
本地模型（llama.cpp / Ollama）访问不到你的 localhost容器内直连
费用0（够用要升级到约 59 美元/月）0（电费与磁盘）
维护无升级需读 release note、改环境配置后重启

结论很直接：多项目 + RAG 的组合，云版免费版装不下。应用数和知识库容量这两个上限，恰好卡在个人开发者的典型需求上。

三阶段部署路径

不建议二选一，建议分三步走：

flowchart TD A["第 1 步：云版免费账号<br/>用 0 到 2 天"] --> B["第 2 步：本机 Docker 自托管<br/>正式开发"] B --> C["第 3 步：迁移到 VPS<br/>需要对外服务时"] A -.- A1["目的：熟悉节点与画布<br/>不绑自己的 Key，不建知识库"] B -.- B1["目的：无配额限制<br/>直连本机 llama.cpp 或 Ollama"] C -.- C1["目的：Web App 与 API 常在线<br/>本地模型改走云端 API"]

第 1 步不要投入任何东西——云版只用来确认"画布的工作方式你是否接受"。第 2 步才是正式开发环境。第 3 步等真的要给别人用时再做，因为自托管应用可以导出 DSL 迁移，前期投入不会浪费。

read more
Posts

容器并非沙箱：为什么 Docker 组权限即是 Root？

在多用户 Linux 环境中，常听到一种说法：将开发者加入 docker 组只是为了方便运行容器，不必输入 sudo。然而，从安全审计的角度来看，将用户加入 docker 组本质上等同于赋予其宿主机的 Root 权限。

为什么 Docker 组 = Root？

Docker 守护进程（dockerd）默认以 root 用户身份运行。由于 docker.sock 套接字文件通常被设置为 root:docker 用户组权限（660），任何属于该组的用户都可以直接通过该套接字与 daemon 通信。

这不仅仅是“方便”的问题。一旦拥有了 docker.sock 的读写权限，你就可以操纵守护进程执行以下操作来实现“容器逃逸”：

  1. 挂载宿主机根目录：你可以启动一个挂载了宿主机 / 的容器，在容器内执行 chroot。此时，宿主机的完整文件系统就在你的掌握之中。
    docker run -v /:/host -it alpine chroot /host
  2. 启动特权容器：通过 --privileged 参数，容器可以直接访问宿主机的硬件设备（如 /dev/sda），轻易地绕过 Namespace 隔离。

容器不是天然的安全边界

容器技术的本质是 Linux 内核特性的“协同工作”：Namespace 负责隔离进程视图，Cgroup 负责限制资源消耗。但它们并非严密的安防屏障：

  • 共享内核：所有容器与宿主机共享同一个内核。一旦发生提权逃逸，攻击者可以直接与内核交互，完全无视 Namespace 的限制。
  • Daemon 权限滥用：Docker 的设计哲学是将 daemon 作为系统的“全权委托者”。能够指示 daemon 工作，也就意味着获得了系统的最高控制权。

总结与防御

为了防止因 Docker 权限配置不当引发的系统级风险，建议采取以下防范措施：

  1. 最小权限原则：严格审计 docker 组，移除不必要的用户。
  2. Rootless Docker：在支持的发行版上使用无根模式，这样即使 daemon 被劫持，它也仅拥有当前用户的权限，无法直接侵害系统核心。
  3. 拥抱 daemon-less：如使用 Podman，它默认无需守护进程，从架构上彻底消除了 docker.sock 带来的 root 等效问题。

作为开发者，我们不仅要利用好工具的便利性，更要看透其背后的权限契约。在 AI 环境部署和 presales 工具链的设计中，始终将“权限最小化”作为第一原则。

read more
Posts

VPS 安全加固：从 0 到三层防御实战记录

一台裸奔的海外 VPS，跑着 new-api、x-ui、Hermes Agent 三个服务，端口审计发现 3000 + 50404 公网监听——我是怎么一步步把它变成铁桶的。

背景：一台裸奔的 VPS

上个月整理 GCP 免费赠金 VPS，发现上面跑着：

  • new-api（端口 3000）— AI API 代理网关
  • x-ui（端口 50404）— 代理面板
  • Hermes Agent（内部端口）— 个人 AI 助理

三个服务全部 0.0.0.0 绑定，直接暴露在公网。用 nmap 扫了一下自己的 IP：

$ nmap -Pn <my-ip>
PORT      STATE SERVICE
3000/tcp  open  ppp
50404/tcp open  unknown

更要命的是，new-api 后台后来审计发现了 7 个陌生 bot 账号，说明已经被扫到了。ROOT_PASSWORD 还是默认的弱密码。

这篇文章记录我从"裸奔"到"三层防御"的完整过程，每一步都是真实踩坑后的总结。

第一层：GCP Firewall — 在流量进主机前挡住

核心思路：在 GCP 层面直接拒绝，流量根本不到你的主机。

GCP Firewall 支持按 instance tag 匹配规则。我先创建了一个 tag secure-server，然后写规则：

# 拒绝所有入站，只允许特定端口
gcloud compute firewall-rules create deny-all-ingress \
  --direction=INGRESS \
  --priority=65534 \
  --network=default \
  --action=DENY \
  --rules=all \
  --target-tags=secure-server \
  --source-ranges=0.0.0.0/0

踩坑：规则创建后测试 nc -zv <ip> 3000，发现还是通的。排查半小时发现——instance 没打 tag。规则存在但没 target，等于没配。

read more