在 Rootless 容器中如何暴露 80 端口（<1024 限制） - 问题详情 - 创脉思

解读

国内一线互联网与金融企业在落地“非特权容器”合规要求时，普遍要求以普通用户身份启动 Docker Engine（Rootless 模式），但业务镜像又习惯监听 80/443。Linux 内核禁止非 root 进程绑定 1–1023 端口，因此面试题考察的是“在 Rootless 场景下，如何既满足合规又保证业务端口不变”的工程化能力，而非简单“跑起来”。

知识点

Rootless Docker 原理：dockerd 以当前用户命名空间运行，容器主进程 UID≠0，宿主机侧由 slirp4netns/rootlesskit 做 NAT。
内核 CAP_NET_BIND_SERVICE 仅对 root 有效，非 root 命名空间内仍受限。
setcap/ping_group_range 等方案在 Rootless 命名空间内无效，因为 VFS capability 会被重新计算为 0。
可行路径只有两条：
A. 容器内改监听高端口 → 宿主机侧 rootlesskit 做 “高端口→80” 的 forward；
B. 宿主机侧 rootlesskit 自带“allow 80/443”补丁（国内阿里云 ACK-Edge、腾讯云 TKE Edge 已集成）。
国内 CI/CD 现状：Jenkins、GitLab-Runner 的 Kubernetes 插件已支持 “securityContext.runAsNonRoot + runAsUser=1000”，但端口冲突常导致健康检查失败，因此必须掌握“高端口+端口映射”的灰度方案。

答案

步骤一：让业务进程在容器里监听 8080（或任意 >1023）端口，Dockerfile 中写

EXPOSE 8080

步骤二：Rootless 启动时，利用 rootlesskit 内置的 “--port-driver=builtin” 转发能力：

docker run -d --name web \
  -p 127.0.0.1:80:8080 \
  --userns=keep-id \
  my/nginx:alpine

rootlesskit 会自动在宿主机侧 bind 0.0.0.0:80（由 rootlesskit 子进程持有，具备 CAP_NET_BIND_SERVICE），再把流量转发到容器命名空间的 8080，容器主进程仍为非 root，满足合规。

若宿主机内核 <5.6 或 rootlesskit 版本 <1.1.0，则改用 authbind 的命名空间感知补丁（国内 Debian 10/11 源已集成），命令如下：

docker run -d --name web \
  -p 127.0.0.1:80:80 \
  --security-opt label=disable \
  --env AUTHBIND_ENABLED=1 \
  my/nginx:alpine-authbind

镜像入口脚本通过 authbind --deep nginx -g 'daemon off;' 实现 80 端口绑定，宿主机侧无需 root，但镜像需预装 authbind 并 setuid 包装，维护成本高于方案一，因此生产推荐“高端口+rootlesskit forward”组合。

拓展思考

国内信通院《容器安全能力要求》明确把“禁止容器进程以 UID 0 运行”列为三级条款，Rootless 成为过评必选项；面试时可补充“我们利用 Kyverno 策略强制 runAsNonRoot，并通过 OPA Gatekeeper 审计端口暴露范围”，体现合规深度。
若业务硬编码 80 端口且无法改代码，可在 ENTRYPOINT 加 setpriv --reuid=1000 --regid=1000 --inh-caps=-all 启动，再用 socat TCP-LISTEN:80,fork,reuseaddr TCP:127.0.0.1:8080 & 做本地转发，镜像增大 <5 MB，但需评估 socat 进程崩溃后的自愈（supervisor/s6-overlay）。
服务网格场景：Istio 1.18+ 的 CNI 插件在 Rootless 节点上已支持“redirect 80→15006”，面试可回答“Sidecar 通过 iptables 在容器 netns 内完成转发，无需业务改端口，但要求节点启用 istio-cni-plugin 并关闭 istio-init 容器”，展示对云原生最新进展的跟踪。