EXPOSE 仅是镜像元数据标注，不实现白名单通信；真正实现需三层配合：①容器网络隔离（如自定义Docker网络）、②运行时--expose限制端口可见性、③应用层IP/服务名白名单校验。
EXPOSE 本身不能建立白名单通信，它也不参与访问控制或网络策略。这是常见误解的根源。
EXPOSE 只是镜像层面的声明性标注，告诉使用者“这个服务预期监听哪些端口”，不开启网络、不设防火墙、不加权限判断，更不会自动实现白名单机制。微服务间的安全通信需要在运行时、网络层或应用层主动配置。
真正实现“微服务镜像之间端口白名单通信”，需结合以下三层配合：
✅ 明确容器网络隔离边界
Docker 默认 bridge 网络中，同一自定义网络（如 docker network create mynet）内的容器可直接通过容器名和内部端口通信（例如 http://user-service:8080），无需暴露到宿主机。这种通信天然受限于网络范围，本身就是一种“隐式白名单”——只有同网容器能访问。
- 启动时指定网络：
docker run --network mynet --name user-service -d user-image docker run --network mynet --name order-service -d order-image
- 验证通信是否可达（从 order-service 容器内）：
curl -v http://user-service:8080/health
✅ 利用 Docker 的 --expose（非 EXPOSE 指令）限制可见性
注意区分：
-
EXPOSE是 Dockerfile 中的构建指令（只写元数据）； -
--expose是docker run的运行时参数（仅开放端口给同一网络容器，不映射到宿主机）。
✅ 正确用法示例：
docker run --expose 8080 --network mynet -d user-image
这表示：该容器的 8080 端口只对 mynet 内其他容器开放，宿主机和其他网络无法访问——相当于网络级白名单入口。
⚠️ 注意：--expose 不替代防火墙或应用层鉴权，它只是缩小暴露面。
✅ 在应用层实现 IP 或服务名白名单校验
即使网络层已隔离，仍建议在微服务代码中做二次校验，尤其当存在跨网络调用、Sidecar 或多租户场景时。
常见做法包括：
- HTTP 请求头校验（如
X-Service-Name或自定义 token） - 拦截器检查来源容器 IP 是否属于可信子网（如
172.18.0.0/16） - 基于服务注册中心（如 Consul、Nacos）动态获取合法调用方列表
- 使用 Java Chassis 等框架的黑白名单配置（如按
serviceName前缀放行cust*）
示例（Spring Boot 拦截器片段）：
String remoteAddr = request.getRemoteAddr();
if (!allowedSubnets.contains(getSubnet(remoteAddr))) {
response.setStatus(403);
return false;
}
✅ 配合 Docker Compose 实现声明式白名单网络
在 docker-compose.yml 中显式定义专用网络，并约束服务归属：
networks:
internal:
driver: bridge
services:
user-service:
image: user:v1
expose: [8080] # ← 运行时等效 --expose，不映射宿主机
networks: [internal]
order-service:
image: order:v1
networks: [internal]
# 可通过 user-service:8080 直接调用，外部不可达
这样既避免手动 docker network connect，又确保只有声明的服务能加入该通信平面。
不复杂但容易忽略
