企业官网建设流程全解析

• 后端
• 虚拟化
• 容器运行时

导读

本文以 Incus 官方安全说明文档 doc/explanation/security.md 为骨架，系统讲解在生产环境中保障 Incus 安装安全的关键措施：守护进程与远程 API 的访问控制、基于用户命名空间的非特权容器隔离、以及桥接/路由两种网络模式下的 MAC/IP 防欺骗过滤配置。读完本文，你将掌握 Incus 的安全基线清单、版本支持策略、incus-admin组权限模型、security.idmap.isolated与security.mac_filtering/security.ipv4_filtering/security.ipv6_filtering等核心配置项的用法与底层实现原理，能够独立完成一套生产级的安全加固部署。

安全基线：五个必须落实的方面

Incus 官方在 README.md 的 Security 章节中给出了一套简洁的安全基线，doc/explanation/security.md 将其作为安全说明的起点。在生产环境中，以下五个方面缺一不可：

1. 保持操作系统及时更新，安装所有可用的安全补丁；
2. 只使用受支持的 Incus 版本（见下文"版本支持策略"）；
3. 限制 Incus 守护进程与远程 API 的访问（见"守护进程访问控制"）；
4. 除非确有必要，不要使用特权容器；如必须使用，要部署相应的安全防护措施；
5. 配置安全的网络接口（见"网络与防欺骗安全"）。

这五条基线是后续所有章节的总纲，其中第 3、4、5 条在本文中有对应的详细配置与源码级解释。

版本支持策略：生产环境只用受支持版本

SECURITY.md 明确要求：绝不要在生成环境中使用不受支持的 Incus 版本。Incus 的发布分为两类：

• 功能版本（Feature releases）：仅最新一个版本受支持，官方通常不发布补丁版本，用户需要等待下一个版本发布来获得修复；
• LTS 版本：定期发布累积了各功能版本 bug 修复的补丁版本，此类补丁版本不包含新功能。

在版本选择上，生产环境应优先考虑 LTS 版本以获得持续的 bug 修复，功能版本则适合希望快速体验新特性的场景。

关于安全问题的界定，SECURITY.md 还有一个值得注意的原则：Incus 官方不认为特权容器是 root 安全的，因此任何利用特权容器逃逸的漏洞都不会被认定为安全漏洞（但官方仍会关注此类逃逸的预防）；而非特权容器逃逸（尤其是由 Incus 自身导致的）则会被严肃对待。这与下文"容器安全"章节中的警告完全一致。

守护进程访问控制

Incus 是一个守护进程（daemon），可通过本地 Unix socket 访问，也可在配置后通过 TLS socket 远程访问。任何人只要能够访问该 socket，就等同于拥有对 Incus 的完全控制权——包括向任意实例挂载宿主机设备与文件系统、调整所有实例的安全特性。因此，必须把守护进程的访问严格限制在可信用户范围内。

本地访问：Unix socket 与 incus-admin 组

Incus 守护进程以 root 身份运行，并通过 Unix socket 提供本地通信。访问控制基于组（group）成员关系：

• root 用户；
• 所有incus-admin组成员。

这两类主体都可以与本地守护进程交互。README 中有一段被安全文档引用的重要安全说明（Include start security note），值得反复强调：

通过 Unix socket 对 Incus 的本地访问始终授予对 Incus 的完全访问权，包括向任意实例挂载文件系统路径或设备、调整任意实例的安全特性。因此，你只应把这种访问权授予那些你愿意赋予其系统 root 权限的用户。

从实现上看，守护进程的本地通信入口集中在 cmd/incusd 的 daemon 与 endpoints 模块中，Unix socket 的管理、TLS 配置与访问判定逻辑可参见 internal/server/endpoints 与 internal/server/daemon。结论很直接：在把用户加入incus-admin组之前，请先问自己是否放心把 root 权限交给他。

远程 API 访问：core.https_address 与防火墙

默认情况下，守护进程只允许本地访问。通过设置core.https_address配置项，可以在网络上以 TLS socket 暴露同一套 API（操作指引见 doc/howto/server_expose.md）。开启后，远程客户端可以连接 Incus，并访问任何标记为 public 使用的镜像。

远程客户端的可信认证有多种方式，详见 doc/authentication.md。在生产环境中有两条硬性建议：

• 将core.https_address设置为服务器应对外提供服务的单一地址，而不是监听宿主机的任意地址；
• 设置防火墙规则，仅允许来自授权主机/子网的流量访问 Incus 端口。

容器安全

默认非特权容器：用户命名空间隔离

Incus 容器默认是**非特权（unprivileged）**的：它们运行在用户命名空间（user namespace）内，将容器内用户的权限限制为宿主机上的普通用户级别，且只对容器自身拥有的设备拥有有限权限。这是容器安全的第一道也是最重要的一道防线，相关的 ID 映射配置（如security.idmap.base、security.idmap.size、raw.idmap）可参见 doc/userns-idmap.md。

隔离 UID/GID 映射：security.idmap.isolated

如果容器之间不需要共享数据，可以启用security.idmap.isolated配置项（实例安全配置，完整参数表见 doc/reference/instance_options.md）。启用后，每个容器将使用互不重叠的 UID/GID 映射，从而防止某个容器通过共享映射发起对其他容器的 DoS（拒绝服务）攻击。

源码层面，internal/server/instance/drivers/driver_lxc.go 会根据security.idmap.isolated与security.idmap.base计算并写入 LXC 的 idmap 配置；同时 internal/server/instance/instance_utils.go 规定了一个使用约束：security.idmap.base不能与security.idmap.isolated同时使用，二者互斥。

特权容器的警告：非 root 安全

Incus 也支持运行特权（privileged）容器。但必须明确：特权容器不是 root 安全的——容器内拥有 root 权限的用户既可以 DoS 宿主机，也能找到突破隔离（escape confinement）的方法。因此：

• 除非确有必要，不要使用特权容器；
• 必须使用时，请部署相应的安全措施（AppArmor、Seccomp、受限的设备挂载等），并接受官方安全策略中"特权容器逃逸不算安全漏洞"的界定。

关于容器安全及所用内核特性的更多细节，可参考 Linux Containers 社区维护的 LXC 安全文档（本文不转载外部内容，仅提示方向）。

容器名称泄漏防护

默认的服务器配置使得本机上的任何人都能轻松枚举系统中的所有 cgroup，进而列出所有正在运行的容器——这被称为容器名称泄漏（container name leakage）。

在启动任何容器之前执行以下两条命令即可封堵该泄漏路径：

chmod 400 /proc/sched_debug chmod 700 /sys/kernel/slab/

其原理是收紧/proc/sched_debug与/sys/kernel/slab这两个内核接口的权限，使其不再可被普通用户读取，从而无法通过遍历 cgroup 与内核调试信息推导出容器名称与运行状态。

网络与防欺骗安全

网络接口的加固措施取决于所选的网络模式。Incus 主要有两类与安全强相关的模式：桥接（bridged）与路由（routed）。下面分别展开。

桥接网络（Bridged NIC）安全

默认网络模式是提供一个"受管"的私有网络桥，每个实例都连接到该桥上，宿主机上对应名为incusbr0的接口。宿主机为每个受管桥运行一个dnsmasq实例，负责 IP 地址分配以及权威与递归 DNS 服务。

在此模式下，有几个安全要点：

• DHCPv4 分配与防 DNS 欺骗：使用 DHCPv4 的实例会被分配 IPv4 地址，并为其实例名创建 DNS 记录。这样实例就无法通过在 DHCP 请求中伪造主机名来伪造（spoof）DNS 记录。
• IPv6 与 SLAAC：dnsmasq同时提供 IPv6 路由器通告（RA）能力，实例使用 SLAAC 自动配置自身的 IPv6 地址，dnsmasq不做分配；使用 DHCPv4 的实例还会为等价的 SLAAC IPv6 地址创建 AAAA DNS 记录（前提是实例未启用 IPv6 隐私扩展）。
• 二层流量风险：虽然默认配置下 DNS 名称无法被伪造，但实例连接在以太网桥上，可以发送任意二层流量，因此不受信任的实例实际上可以在桥上做 MAC 或 IP 欺骗。
• IPv6 路由表风险：默认配置下，桥上的实例还能通过向桥发送（可能是恶意的）IPv6 路由器通告来篡改 Incus 宿主的 IPv6 路由表。原因在于incusbr0接口创建时其/proc/sys/net/ipv6/conf/incusbr0/accept_ra被设为2——即使forwarding已启用，宿主仍会接受路由器通告。

针对上述风险，Incus 为桥接 NIC 提供了三个安全过滤选项，建议添加到实例使用的 profile 中，也可以按实例单独设置。选项定义与说明如下表（参数定义来源于 internal/server/device/nic_bridged.go 中的配置键声明，各键的校验逻辑位于 internal/server/device/nic.go）：

可以在 profile 默认设置的基础上，按实例覆盖桥接 NIC 的安全设置：

incus config device override <instance> <NIC> security.mac_filtering=true

这三个选项组合使用，可以阻止连接在桥上的实例伪造 MAC 与 IP 地址。它们基于nftables实现——Incus 的防火墙驱动实现在 internal/server/firewall/drivers/drivers_nftables.go，桥接过滤规则的组装入口是nic_bridged.go中的InstanceSetupBridgeFilter调用（见 internal/server/device/nic_bridged.go）。

使用这些过滤选项时，还需注意以下行为细节：

• 嵌套容器影响：这些选项会阻止嵌套容器以不同 MAC 地址使用父网络（即使用 bridged 或macvlanNIC）；
• IP 过滤机制：IP 过滤会阻断包含伪造 IP 的 ARP 与 NDP 通告，以及任何含伪造源地址的数据包；
• 无 IP 可分配时全堵：若启用了security.ipv4_filtering或security.ipv6_filtering，而实例无法被分配 IP 地址（因为ipvX.address=none或桥上未启用 DHCP 服务），则该协议的所有 IP 流量都会被实例阻断；
• IPv6 RA 阻断：启用security.ipv6_filtering时，来自实例的 IPv6 路由器通告会被阻断，这正好封堵了上文提到的"篡改宿主 IPv6 路由表"风险路径；
• 非标准帧丢弃：启用任一 IP 过滤后，所有非 ARP、IPv4 或 IPv6 的以太网帧都会被丢弃，从而防止堆叠 VLAN Q-in-Q（802.1ad）帧绕过 IP 过滤。

路由网络（Routed NIC）安全

另一种可选的网络模式称为"路由（routed）"。它在容器与宿主之间提供一对虚拟以太网设备（veth pair）；在此模式下，Incus 宿主充当路由器，宿主机上会添加静态路由，将发往容器 IP 的流量导向容器的veth接口。

该模式内置两项默认安全设置（实现见 internal/server/device/nic_routed.go）：

• 禁用 accept_ra：宿主上创建的veth接口默认将accept_ra禁用（即写入net/ipv6/conf/<veth>/accept_ra=0），防止容器发送的路由器通告修改 Incus 宿主的 IPv6 路由表；
• 开启 rp_filter：宿主将rp_filter设为1，防止针对宿主未知容器 IP 的源地址欺骗（source address spoofing）。

这两项设置在 internal/server/device/nic_routed.go 中通过SysctlSet在设备挂载时写入，属于路由模式开箱即用的安全兜底。桥接与路由模式的完整设备参数对比可参考 doc/reference/devices_nic.md，路由 NIC 在虚拟机场景的用法见 doc/howto/instances_routed_nic_vm.md。

安全事件报告

如果在使用中发现了安全漏洞，请按照 SECURITY.md 中的说明报告：可通过邮件联系security@linuxcontainers.org，也可通过 GitHub 的 Security Advisories 渠道提交。报告前请先确认该问题是否符合官方对安全漏洞的界定（例如，特权容器逃逸不会被认定为安全漏洞）。

小结：一份可直接落地的安全检查清单

综合全文，生产环境下的 Incus 安全加固可归纳为以下清单：

1. 保持操作系统更新，仅使用受支持的 Incus 版本（生产环境优先 LTS）；
2. 本地访问仅授予 root 与可信的incus-admin组成员——因为本地访问即等同 root 权限；
3. 远程 API 仅在必要时通过core.https_address暴露，绑定单一地址并用防火墙限制来源；
4. 默认保持非特权容器；无需跨容器数据共享时启用security.idmap.isolated（注意其与security.idmap.base互斥）；避免使用特权容器；
5. 启动容器前执行chmod 400 /proc/sched_debug与chmod 700 /sys/kernel/slab/防止容器名称泄漏；
6. 桥接网络按需启用security.mac_filtering/security.ipv4_filtering/security.ipv6_filtering（可用incus config device override按实例覆盖），并理解其对嵌套容器、无 DHCP 场景及 Q-in-Q 帧的连带影响；
7. 路由网络依赖其默认的accept_ra禁用与rp_filter=1设置，无需额外干预即可防止 RA 路由篡改与源地址欺骗。

以上每一项均可在 doc/explanation/security.md、README.md、SECURITY.md 及 internal/server/device 的源码中得到印证，可作为安全审计与运维排障的直接依据。

• 后端
• 虚拟化
• 容器运行时