安全组是云平台层面的网络访问控制机制，作用于宿主机网卡，仅对容器暴露的端口生效；非root容器不影响安全组规则，但要求配置时只开放必需端口、限制源IP、区分内外网策略，并需与宿主机防火墙（如DOCKER-USER链）、能力限制等协同实现分层防护。
非 root 容器本身不直接参与网络访问控制，安全组和防火墙是宿主机或云平台层面的网络策略工具。它们与容器权限模型属于不同层级：容器用户（如 uid 1001）控制的是进程在容器内能做什么；而安全组/防火墙控制的是“哪些 ip、端口、协议可以进出该宿主机的某端口”。二者需协同设计，但不能互相替代。
安全组（云平台）怎么配合非 root 容器
安全组作用于宿主机网卡入口/出口，对容器暴露的端口生效。非 root 容器不影响安全组规则本身，但会影响你配置时的判断逻辑：
-
只放行业务必需端口：例如容器监听
8080（非 root 可绑定），就在安全组中仅开放8080/TCP，禁用22、3306等无关端口 -
限制源 IP 范围：前端服务只允许负载均衡器 IP 段访问；管理接口（如 Prometheus metrics）只允运维网段（如
10.10.0.0/16） - 区分内外网策略：公网-facing 容器启用严格入站规则；内部微服务间通信可走私有子网+最小化端口白名单
宿主机防火墙（iptables/nftables）如何增强控制
在 Docker 启动后，它会自动操作 iptables 添加链（如 DOCKER-USER），这是插入自定义规则的最佳位置——早于 Docker 默认转发规则，且不受 dockerd 重启影响：
-
在 DOCKER-USER 链中限速或拦截异常连接：
iptables -I DOCKER-USER -p tcp --dport 8080 -m connlimit --connlimit-above 50 -j REJECT -
阻止容器主动外连敏感地址（防横向渗透）：
iptables -I DOCKER-USER -o docker0 -d 192.168.0.0/16 -j DROP（禁止容器访问其他内网网段） -
基于容器进程 UID 做网络标记（需 cgroup v2 + nftables）：
通过cgroup匹配容器所属 UID，再关联网络策略（高级用法，需内核 ≥ 5.10）
为什么不能靠“非 root”实现网络隔离
容器内 UID 是否为 0，完全不影响其发起网络连接的能力。一个以 UID 1001 运行的 curl 或 nc 进程，照样能访问任意外网地址、连接数据库、发起 DNS 查询。网络能力由 Linux capability CAP_NET_RAW 和命名空间决定，Docker 默认保留该能力（除非显式 --cap-drop=NET_RAW）。
- 非 root 用户 ≠ 网络受限用户
- 真正限制外连需结合：
--cap-drop=NET_RAW（禁用原始套接字）、--network none（关闭网络）、或 host 级防火墙 - 若容器需调用外部 API，应通过服务网格（如 Istio）或代理统一管控，而非依赖用户身份
生产环境推荐组合策略
单一手段无法达成细粒度访问控制，需分层叠加：
-
构建层：Dockerfile 中用
USER 1001+--cap-drop=ALL --cap-add=NET_BIND_SERVICE -
运行层：启动时加
--read-only --security-opt no-new-privileges，并指定--network custom_bridge -
网络层：云平台安全组限制入向；宿主机
DOCKER-USER链限制出向与连接数；关键服务前置 Envoy 或 Nginx 做认证/限流 -
可观测层：开启
dockerd --log-driver=syslog，配合 Falco 或 eBPF 工具捕获异常外连行为
