企业官网建设流程全解析

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

Incus 是一个强大的系统容器与虚拟机管理器，其安全模型贯穿守护进程访问控制、容器内核隔离、网络流量防护与远程 API 认证授权四大层面。本文以仓库 doc/security.md 为核心骨架，完整展开其索引的安全主题文档（doc/explanation/security.md、doc/explanation/bpf-tokens.md、doc/authentication.md、doc/authorization.md、doc/howto/server_expose.md），并辅以源码级证据，帮助你从零构建一套生产可用的 Incus 安全基线。读完本文，你将掌握：如何管控本地与远程守护进程访问、如何正确使用非特权容器与 BPF 能力委托、如何利用网桥/路由模式下的防欺骗特性，以及如何通过 TLS 证书、OpenID Connect 与 OpenFGA 实现认证与细粒度授权。

总体安全原则

Incus 官方在 README.md 的 Security 章节中给出了一套简洁的安全检查清单，生产环境部署时应逐条落实：

• 保持操作系统更新：及时安装所有安全补丁，避免因宿主内核或用户态漏洞被容器逃逸利用。
• 仅使用受支持的 Incus 版本：详见下文“受支持版本”一节。
• 限制对 Incus 守护进程与远程 API 的访问：这是整个安全模型的核心。
• 除非必要，不要使用特权容器；如确需使用，必须配套相应的安全措施。
• 配置安全的网络接口：根据所选的网络模式（桥接、路由、macvlan 等）采取对应的防护。

此外，doc/explanation/security.md 强调了一个关键前提：通过 Unix socket 的本地访问始终授予对 Incus 的完全控制权，包括将文件系统路径或设备挂载到任意实例、修改任意实例的安全特性。因此，这类访问只能授予你愿意给予系统 root 权限的用户。远程 API 的安全边界则取决于你所配置的认证与授权方案。

受支持的版本与漏洞报告

SECURITY.md 明确了两类发布周期：

• Feature release（功能发布）：只支持最新的一个版本，通常不做补丁版次发布，用户应等待下一个版本。
• LTS release（长期支持版）：定期发布包含功能版本累积修复的 bugfix 版次，但不包含新功能。

生产环境绝不可以使用不受支持的 Incus 版本。同时该文件界定了漏洞范畴：特权容器不被视为 root 安全，因此逃逸特权容器不被认定为安全漏洞；而非特权容器逃逸（尤其是由 Incus 自身促成的情况）则会被严肃对待。发现安全问题可发送邮件至 security@linuxcontainers.org。

守护进程访问控制

Incus 是一个常驻守护进程，可通过两种 socket 访问：本地的 Unix socket，以及（配置后）基于 TLS 的远程 socket。任何能访问该 socket 的人都拥有 Incus 的完全控制权，包括挂载宿主设备/文件系统、调整所有实例的安全特性，因此必须将访问限制在受信任用户范围内。

本地访问：基于组的访问控制

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

• root用户以及incus-admin组的所有成员可以与本地守护进程交互；
• 仅属于incus组的成员则被限制在与其用户绑定的单个项目中（详见 doc/authorization.md）。

由于本地 socket 访问等价于完全控制，官方在 README.md 的安全提示中再次强调：应只将此访问权授予你愿意信任其拥有系统 root 权限的用户。

远程访问：TLS socket 与生产加固

默认情况下，守护进程只接受本地访问。设置core.https_address配置项即可在同一 API 上启用网络 TLS socket，具体步骤见 doc/howto/server_expose.md。远程客户端连接后可以访问所有标记为公开使用的镜像；要获得完整 API 访问权限，必须通过认证成为受信任客户端（见“远程 API 认证”一节）。

生产环境部署建议：

• 将core.https_address设置为服务器的单一地址（而非宿主的任意地址），避免暴露面扩散；
• 配置防火墙规则，仅允许来自授权主机/子网的流量访问 Incus 端口；
• 将远程访问与细粒度授权（如 OpenFGA）结合，把“谁可以访问”从二元的信任模型升级为最小权限模型。

容器安全

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

默认情况下，Incus 容器是**非特权（unprivileged）**的：容器运行在用户命名空间（user namespace）内部，容器内用户的权限被限制为宿主上普通用户的权限，并且仅拥有其自有设备上的有限特权。这是容器安全的第一道防线。

如果容器之间不需要共享数据，可以启用security.idmap.isolated配置项，为每个容器分配互不重叠的 UID/GID 映射，从而防止某个被攻破的容器对其他容器发起 DoS 攻击（例如通过大量消耗共享 ID 映射资源）。该选项在 doc/config_options.txt 中定义为“为实例使用唯一的 idmap”，仅对非特权容器生效，且不可与security.idmap.base共用同一 base、不可与security.idmap.size/raw.idmap混用冲突配置。在源码 internal/server/instance/drivers/driver_lxc.go 中可以看到，驱动在准备 idmap 时正是读取security.idmap.isolated与security.idmap.base，并在IsFalseOrEmpty时回退到共享映射逻辑。

特权容器：明确的风险边界

Incus 也支持运行特权（privileged）容器，但必须明确：特权容器不是 root 安全的。容器内具有 root 权限的用户可以对宿主发起 DoS，并存在各种途径逃逸隔离（例如利用宿主可写文件系统、设备节点等）。如果业务确实需要特权容器，应将其视为高风险资产，配套独立隔离、严格网络策略与最小软件面等补偿措施。这正是 SECURITY.md 将“特权容器逃逸”排除在漏洞范畴之外的原因——它本身就是已知的边界。

容器名称泄漏防护

默认服务器配置下，任何能读取宿主 cgroup 列表的人都很容易枚举系统上运行的所有容器（从而泄露容器名称）。可以在启动任何容器之前，通过收紧以下路径的权限来阻止这种名称泄漏：

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

/proc/sched_debug会暴露进程调度信息（可间接关联容器），/sys/kernel/slab的访问则与 cgroup 列表枚举有关，收紧两者可显著降低容器名称的暴露面。

BPF 能力委托（BPF token delegation）

Linux 内核 6.9 起引入了 BPF token 机制，允许宿主将部分 BPF 能力安全地委托给非特权命名空间。Incus 在 doc/explanation/bpf-tokens.md 中提供了完整的委托方案：

只要设置了以下任一实例选项，Incus 就会在容器内指定的路径挂载一个 BPF 文件系统，并把配置的能力委托给它：

每个选项接受逗号分隔的值列表，并额外支持通配值any（委托该类型的所有可能值）。可用的具体取值取决于内核版本，可在内核源码树的include/uapi/linux/bpf.h（大多数发行版为/usr/include/linux/bpf.h）中查找对应enum并去掉前缀。挂载路径由security.bpffs.path指定（默认/sys/fs/bpf），该路径必须已存在于容器内；且 BPF 文件系统仅当任一security.bpffs.delegate_*选项被设置时才会挂载（见 doc/config_options.txt）。

示例配置：

生效后在容器内查看挂载信息，可以看到对应的委托参数：

$ mount -t bpf none on /sys/fs/bpf type bpf (rw,relatime,delegate_cmds=map_create:obj_get:link_create,delegate_maps=hash:array:devmap:queue:stack,delegate_progs=socket_filter:kprobe:cgroup_sysctl,delegate_attachs=any)

在源码层面，internal/server/instance/drivers/driver_lxc.go 会从展开后的实例配置中读取security.bpffs.path、security.bpffs.delegate_cmds、security.bpffs.delegate_maps、security.bpffs.delegate_progs、security.bpffs.delegate_attachs，并据此构造 BPF 文件系统挂载参数，与文档描述完全对应。这些选项仅对非特权容器生效且不支持热更新（liveupdate: no）。

网络安全

网络接口的安全配置取决于所采用的网络模式。Incus 默认提供“受管理”的私有网桥模式，另有“路由（routed）”模式可选，两种模式各有不同的威胁模型与防护手段。

桥接 NIC 安全

默认网络模式下，宿主上存在一个名为incusbr0的网桥接口，所有实例接入该网桥。宿主为每个受管理网桥运行一个dnsmasq实例，负责 IP 地址分配，并提供权威与递归 DNS 服务。

dnsmasq的关键防护作用：

• 使用 DHCPv4 的实例会获得 IPv4 地址，并为其实例名创建 DNS 记录——由于记录由dnsmasq依据分配结果生成，实例无法通过在 DHCP 请求中伪造主机名来欺骗 DNS 记录。
• dnsmasq同时提供 IPv6 路由通告能力，实例通过 SLAAC 自动配置 IPv6 地址（无分配）；同时使用 DHCPv4 的实例会获得与 SLAAC IPv6 地址等价的 AAAA DNS 记录（前提是实例未启用 IPv6 隐私扩展）。

尽管如此，默认桥接模式仍有固有风险：

• 实例连接在以太网桥上，可发送任意二层流量，不受信任的实例实质上可以在桥上实施 MAC 或 IP 欺骗。
• incusbr0接口创建时带有accept_ra=2（即使启用了转发也接受路由通告），因此桥接实例可以向桥发送（可能恶意的）IPv6 路由通告，修改 Incus 宿主的 IPv6 路由表（相关语义可参考内核文档 ip-sysctl.txt 中/proc/sys/net/ipv4/*变量说明）。

为应对这些风险，Incus 为桥接 NIC 提供以下安全特性（配置项定义与校验逻辑见 internal/server/device/nic_bridged.go，均通过 nftables 实现）：

这些设置应添加到实例所使用的 profile 中，也可以直接对单个实例设置。可以在 profile 默认值的基础上，对单个实例进行覆盖：

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

组合使用这些特性，可以阻止桥接实例伪造 MAC 与 IP 地址。需要注意以下行为细节：

• 嵌套容器影响：这些选项实际上会阻止嵌套容器以不同的 MAC 地址使用父网络（即使用桥接或macvlanNIC 的场景）。
• IP 过滤范围：IPv4/IPv6 过滤会拦截包含伪造 IP 的 ARP 与 NDP 通告，以及任何包含伪造源地址的数据包。
• 无法分配地址时的行为：如果启用了security.ipv4_filtering或security.ipv6_filtering，但实例无法获得 IP 地址（ipvX.address=none或网桥上没有 DHCP 服务），则该协议的所有 IP 流量都会被阻断。源码 internal/server/network/network_utils.go 在配置校验阶段即对此类组合（启用过滤但地址为空）进行检查。
• IPv6 路由通告阻断：启用security.ipv6_filtering后，实例发出的 IPv6 路由通告会被阻断，从而防止其修改宿主路由表。
• 非 IP 帧丢弃：启用 IPv4/IPv6 过滤时，所有非 ARP、非 IPv4、非 IPv6 的以太网帧都会被丢弃，这可以防止堆叠的 VLAN Q-in-Q（802.1ad）帧绕过 IP 过滤。

在实现层面，internal/server/device/device_utils_network.go 会将security.mac_filtering与 ACL 规则一起交给防火墙的InstanceSetupBridgeFilter下发 nftables 规则，印证了“这些选项通过 nftables 实现”的说明。OVN 网络驱动也有同类过滤逻辑（internal/server/network/driver_ovn.go）。

路由（Routed）NIC 安全

另一种网络模式是“路由（routed）”模式：它在容器与宿主之间建立一对虚拟以太网设备（veth），Incus 宿主充当路由器，并添加静态路由，将发往容器 IP 的流量导向容器的veth接口。

该模式内置两项关键防护：

• 宿主侧创建的veth接口默认禁用accept_ra，防止容器发送的路由通告修改 Incus 宿主的 IPv6 路由表；
• 宿主的rp_filter（反向路径过滤）被设置为1，防止容器对宿主未知的 IP 进行源地址伪造。

相比桥接模式，routed 模式不共享二层广播域，隔离粒度更细，适用于对流量方向有严格要求的场景。

远程 API 认证

远程与 Incus 守护进程的通信基于 HTTPS 上的 JSON。要访问远程 API，客户端必须先通过认证。支持的认证方式有：TLS 客户端证书、OpenID Connect（OIDC）。完整说明见 doc/authentication.md。

TLS 客户端证书

首次启动时，客户端与服务端都会生成密钥对：服务端密钥对用于所有到 Incus socket 的 HTTPS 连接，客户端证书作为客户端证书用于双向通信。删除旧证书即可重新生成。

通信协议要求：必须使用 TLS 1.3 或更高版本。可以通过在客户端和服务端同时设置环境变量INCUS_INSECURE_TLS强制接受 TLS 1.2，但这是不受支持的配置，仅应在被迫使用过时的企业代理时使用。所有通信必须使用完美前向保密（PFS），密码套件仅限强椭圆曲线套件（如 ECDHE-RSA、ECDHE-ECDSA）。生成的密钥应至少为 4096 位 RSA（优先 384 位 ECDSA），签名仅信任 SHA-2 系列——因为客户端与服务端都由 Incus 控制，没有理由兼容任何破损的协议或密码套件。

受信任客户端管理：用incus config trust list查看服务端信任的 TLS 证书列表；添加受信任客户端有以下两种方式：

1. 直接添加证书（推荐）：把客户端证书复制到服务端，用incus config trust add-certificate <file>注册。
2. 信任令牌（token）：在服务端执行incus config trust add <client_name>生成一次性令牌，令牌在可配置的时间（core.remote_token_expiry）后或使用一次后失效；客户端在incus remote add <remote_name> <token>时提供令牌即可完成注册。

整个认证流程与 SSH 类似：用户incus remote add添加服务端时，客户端通过 HTTPS 获取其证书并展示指纹；用户需确认指纹无误（可联系服务端管理员执行 info 命令比对）；随后服务端验证客户端证书——若证书已在信任库中则直接放行，否则提示输入令牌，令牌匹配则将客户端证书加入信任库并放行，否则拒绝。要撤销信任，用incus config trust remove <fingerprint>移除对应证书。

JWT 形式的 TLS 认证：除了直接使用客户端证书，Incus 还支持用户派生 bearer 令牌并通过 HTTPAuthorization头使用。用户需生成一个签名 JWT，其Subject字段设为客户端证书的完整指纹，包含有效的NotBefore与NotAfter，并由客户端证书的私钥签名。

PKI 模式：在 PKI 环境中，管理员用中心 CA 为所有客户端和守护进程签发证书。启用步骤：将client.ca放到客户端配置目录（~/.config/incus），将server.ca放到服务端配置目录（/var/lib/incus）；用 CA 签发的证书替换自动生成的证书；重启服务端。此后所有连接都使用预置的 CA 证书：服务端证书若由该 CA 签发则直接建立连接、不再提示确认；否则回退到正常认证流程。注意：生成的证书不会自动受信任，仍需按上述方式加入信任库。

本地密钥加密：客户端密钥可以用密码加密：

ssh-keygen -p -o -f .config/incus/client.key

加密后每次调用都可能提示输入密码（除非启用 keepalive 模式）。注意命令行工具支持加密密钥，但部分第三方工具（如某些自动化连接插件）不支持。

OpenID Connect 认证

Incus 支持通过 OIDC Identity Provider 认证用户。配置oidc.*系列服务端配置项即可启用，OIDC 提供方必须启用 Device Authorization Grant（设备授权码）流程。客户端执行incus remote add <remote_name> <remote_address>后，会通过浏览器完成认证，确认 Incus 使用的设备码，客户端随后获取并存储 access/refresh 令牌用于后续交互。

两点重要限制：

• 当前没有角色处理：通过 OIDC Identity Provider 认证的任何用户都会获得 Incus 的完全访问权限。要限制用户权限，必须同时配置授权（目前与 OIDC 兼容的唯一授权方法是 OpenFGA）。
• 可选子网限制：Incus 支持自定义 OIDC 声明incus.allowed_subnets（字符串列表）；若设置了该声明，用户只有在连接 IP 属于其中某个 CIDR 子网时才被允许。

TLS 服务端证书（ACME）

Incus 支持通过 ACME 服务（如 Let's Encrypt）签发服务端证书，配置相关服务端选项即可启用，支持HTTP-01与DNS-01两种挑战：

• DNS-01：acme.provider与acme.provider.environment的取值可参考 Incus 底层 ACME 客户端 lego 的 DNS 插件文档。
• HTTP-01：Incus 会让 lego 临时监听 80 端口完成 HTTP 挑战；如果服务端位于反向代理之后，需要反向代理将 HTTP 流量重定向到 HTTPS。
• 需要 External Account Binding（EAB）的 ACME 服务，需同时设置acme.eab.kid与acme.eab.hmac。

认证失败场景

• 服务端证书变更：服务端重装（新证书）或连接被中间人（MITM）劫持都会导致证书变更。此时客户端因指纹不匹配而拒绝连接，用户需联系服务端管理员核实证书是否确实变更；若属实，可替换证书或删除 remote 后重新添加。
• 服务端信任关系被撤销：另一个受信任客户端或本地管理员移除了该客户端的信任条目后，服务端仍使用同一证书，但所有 API 调用返回 403，并提示客户端不受信任。

授权：从“可访问”到“可做什么”

当通过 Unix socket 交互时：incus-admin组成员拥有完整 API 访问权，仅属于incus组的用户被限制到与其用户绑定的单个项目。通过网络交互时（见 doc/howto/server_expose.md），可以进一步认证并限制用户访问。完整说明见 doc/authorization.md，Incus 支持三种授权方法，默认根据客户端的认证协议自动选择，也可通过authorization.client.*定制路由。

TLS 授权（按项目限制）

Incus 原生支持将受信任 TLS 客户端限制到一个或多个项目。被限制的客户端无法进行全局配置变更，也无法修改其被允许访问的项目自身的配置（限额、限制）。操作方式：

incus config trust edit <fingerprint>

将restricted键设为true，并指定限制客户端访问的项目列表；若项目列表为空，客户端将无法访问任何项目。默认情况下，使用受限 TLS 证书认证的客户端走此方法，使用非受限证书的客户端则授予完全访问权限（均可通过客户端路由定制）。

OpenFGA：开放细粒度授权

OpenFGA 是一种高度细粒度的授权方案，例如可以精确到“只允许某个用户访问某个实例”。使用步骤：

1. 自行配置并运行一个 OpenFGA 服务端；
2. 在 Incus 中设置authorization.openfga.*系列服务端配置项（必须全部设置才能启用）；
3. Incus 连接 OpenFGA 服务端、写入授权模型，并对后续所有请求查询该服务端进行授权判断。

无需手工创建授权模型：Incus 会生成完整模型，并写入初始 tupleserver:incus#authenticated@user:*，即仅允许通过认证的用户。模型文件位于 internal/server/auth/driver_openfga_model.openfga，定义了user、group、certificate、instance、project、server、storage_pool、security_tag等类型及其关系（如instance的admin、operator、user、viewer、can_exec、can_access_console、can_manage_backups等，均通过 project 关系级联自上层）。

安全标签（security tags）：实例可通过security.tags配置键打标签（逗号分隔列表）。Incus 自身不做标签授权决策，而是将每个标签在 OpenFGA 中暴露为与 server 相关的security_tag对象，并持有与每个携带该标签实例的tag关系（例如security_tag:pci tag instance:default/web1），供直接操作 OpenFGA 存储的外部工具使用。源码 internal/server/instance/drivers/driver_lxc.go 在实例安全标签变更时会调用授权器的SetInstanceSecurityTags同步到 OpenFGA，印证了该联动机制。

谨慎授予的关系：不要将下列关系授予你不信任其拥有宿主 root 权限的用户：

• server -> admin
• server -> operator
• server -> can_edit
• server -> can_create_storage_pools
• server -> can_create_projects
• server -> can_create_certificates
• certificate -> can_edit
• storage_pool -> can_edit
• project -> admin

其余关系可以授予，但必须配套适当的项目限制（project restrictions）。

Scriptlet 授权：无外部依赖的细粒度规则

Incus 支持在authorization.scriptlet服务端配置项中编写脚本实现细粒度授权，不依赖任何外部工具。脚本需实现一个authorize函数，接收三个参数并返回布尔值：

• details：包含以下属性的对象
  • Username：用户名或证书指纹
  • Protocol：认证协议
  • IsAllProjectsRequest：请求是否针对所有项目
  • ProjectName：项目名
  • Chain：证书链（已解析的 x509 证书列表）
  • Certificate：数据库中存储的证书数据
  • Claims：已验证的 OIDC 令牌声明字典（非 OIDC 客户端为空）
  • URL：客户端原始请求 URL（<path>?<query>）
  • Path：客户端请求的 API 路径
  • Query：查询参数字典（注意值为字符串列表而非单个字符串）
  • Method：请求使用的 HTTP 方法
• object：用户请求授权所针对的对象
• entitlement：用户请求的授权级别

函数返回true/false表示该用户是否拥有对该对象、该授权级别的访问权。此外还可选定义get_instance_access(project_name, instance_name)与get_project_access(project_name)两个函数，返回能访问给定实例/项目的用户列表，以便通过访问 API 列出用户。

客户端路由（Client Routing）

多种授权方法可同时加载，每个请求根据客户端的认证类别路由到其中一种方法，由authorization.client.*系列配置项控制（每种客户端类别一个）：

• authorization.client.unix：通过 Unix socket 连接的本地客户端
• authorization.client.tls：使用非受限客户端证书的客户端
• authorization.client.tls-restricted：使用受限（项目级）客户端证书的客户端
• authorization.client.oidc：OIDC 认证的客户端
• authorization.client.default：上述未设置的所有客户端类别

每个选项可取值：allow（无条件放行）、deny（无条件拒绝）、tls（使用 TLS 授权，仅对tls-restricted有效）、openfga（使用 OpenFGA）、scriptlet（使用脚本授权）。某类未设置时回退到authorization.client.default；默认也未设置时，应用以下固定内置路由：

例如，让 OpenFGA 授权 OIDC 客户端，同时受限 TLS 客户端继续使用 TLS 授权：

incus config set authorization.client.oidc=openfga incus config set authorization.client.tls-restricted=scriptlet

两个必须注意的安全警示：

• tls-restricted改路由有风险：证书级项目限制仅由 TLS 授权方法强制执行。若将authorization.client.tls-restricted设为非tls值，客户端证书的项目列表将不再被参考，受限证书可能获得远超其项目范围的访问权限。只有在你路由到的方法能复现你所依赖的限制时，才应改为其他值。
• default最后设置：default作用于所有未显式配置的类别，一个错误会同时影响全部类别；若设为openfga或scriptlet而该方法配置错误或不可达，或设为deny，则所有远程客户端都会被拒绝。因此应先在确认每个显式配置的类别行为符合预期后，再设置default。另外，root用户始终可以通过 Unix socket 与 API 交互，不受任何授权方法限制——这正是配置出错导致服务端被锁死时能够恢复的兜底机制。

结语：构建你的 Incus 安全基线

综合全文，一套完整的 Incus 安全基线可以归纳为五步：守住入口（Unix socket 仅限incus-admin，远程core.https_address绑定单一地址并加防火墙）、默认隔离（保持非特权容器，按需启用security.idmap.isolated，必要时用 BPF token 委托能力）、防护网络（按模式启用security.mac_filtering/ipv4_filtering/ipv6_filtering，或选择 routed 模式）、认证把关（TLS 证书信任库、令牌或 OIDC，配合 ACME 签发服务端证书）、授权收敛（TLS 项目限制、OpenFGA 细粒度模型或 scriptlet，谨慎配置客户端路由）。每一步的配置项与命令均可在 doc/config_options.txt 与上述各文档中找到权威定义，源码（如 internal/server/device/nic_bridged.go、internal/server/instance/drivers/driver_lxc.go、internal/server/auth 目录）则为这些行为提供了可验证的实现依据。

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