核心思路是网络隔离打底、运行时权限控制加固、服务网格实现七层细粒度策略，三者协同防越权；需废弃默认bridge网，用语义化自定义网络分域，容器以非root用户最小权限运行，并通过istio等服务网格校验jwt、限制api路径与方法，辅以主机iptables兜底防护。
核心思路是：用网络隔离打底，再叠加运行时权限控制与服务网格策略，三者协同才能实现“极细粒度防越权访问”。单纯靠Docker原生网络（如bridge或自定义网络）只能做到服务级连通性控制，无法识别“哪个API、哪个用户、哪个HTTP方法”是否该被放行——这必须靠上层策略介入。
1. 用多网络+显式连接切断默认互通
Docker默认bridge网络下所有容器可互访，这是越权访问的温床。必须废弃默认网络，改用语义化自定义网络，并严格控制容器接入：
- 为不同安全域创建独立网络，例如：
docker network create --driver bridge frontend-net、docker network create --driver bridge backend-api-net、docker network create --driver bridge db-internal-net - 启动容器时只挂载必需的网络，禁止“一容器多网”滥用：
docker run --network frontend-net --name web nginx；docker run --network backend-api-net --network db-internal-net --name order-svc my-order-service - 数据库容器只接入
db-internal-net，不连任何其他网络，从网络层杜绝前端直连DB可能
2. 在容器内启用运行时最小权限约束
网络隔离只是第一道门，容器内部若以root运行、文件系统可写、能力全开，攻击者一旦突破网络层，仍可横向提权或篡改配置：
- 镜像中固定非root用户：
USER 1001:1001，并在docker run中显式指定：--user 1001:1001 - 禁用全部Linux能力，仅按需添加：
--cap-drop=ALL --cap-add=NET_BIND_SERVICE（仅允许绑定端口） - 根文件系统设为只读：
--read-only，配合--tmpfs /run --tmpfs /tmp提供必要临时空间 - 禁止提权：
--security-opt no-new-privileges，防止进程通过setuid等机制获取更高权限
3. 引入服务网格（如Istio）接管七层流量策略
Docker原生网络工作在三层/四层，无法识别HTTP路径、Header、JWT声明等。要实现“只允许user-svc调用auth-svc的POST /v1/token/verify”，必须依赖服务网格：
- 将所有微服务注入Istio Sidecar，使所有进出流量经Envoy代理
- 用AuthorizationPolicy定义细粒度规则，例如限制某服务只能调用另一服务特定路径和方法：
kind: AuthorizationPolicy
metadata:
name: auth-verify-only
namespace: default
spec:
selector:
matchLabels:
app: auth-svc
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/user-svc"]
to:
- operation:
methods: ["POST"]
paths: ["/v1/token/verify"]
- 配合RequestAuthentication校验JWT签名与issuer，确保调用方身份真实可信
4. 补充主机层防火墙（iptables/nftables）作为兜底
当容器逃逸或Sidecar失效时，宿主机防火墙是最后一道防线。可在Docker启动后，对容器虚拟网卡（如vethxxx）或网桥（如br-xxxx）设置链路层过滤：
- 禁止非授权源IP访问敏感端口：
iptables -A FORWARD -i br-backend -o br-db -s 172.20.0.0/16 -d 172.21.0.0/16 -p tcp --dport 5432 -j DROP - 仅允许backend子网内的特定容器MAC地址访问DB网桥：
iptables -A FORWARD -i br-backend -o br-db -m mac --mac-source xx:xx:xx:xx:xx:xx -j ACCEPT - 所有规则应置于DOCKER-USER链中，避免被Docker自动规则覆盖
