docker compose 不提供端到端加密，需通过自定义 bridge 网络、服务内嵌 tls 或反向代理（如 caddy）实现加密通信，并强制数据库等敏感服务启用 ssl/tls 连接。
用自定义 bridge 网络打下安全通信基础
默认 bridge 网络不支持服务名解析 + 无内置 DNS，无法稳定通信，更谈不上加密。必须先创建自定义网络：
- 运行
docker network create --driver bridge app-secure-net，或在docker-compose.yml中声明 - 所有需要加密通信的服务（如 API、数据库客户端、缓存客户端）都加入该网络
- 确保服务通过服务名访问（如
https://auth-service:8443），而非 IP —— 这是后续配置证书绑定和 TLS 的前提
让服务自带 TLS 能力（推荐轻量级方案）
不依赖外部代理，直接在应用中启用 HTTPS/gRPC-TLS，是最可控的方式：
- 为后端服务（如 Go/Python/Node 应用）生成自签名或 Let’s Encrypt 兼容证书，并挂载进容器：
volumes: ["./certs:/app/certs"] - 代码中加载证书启动 HTTPS 服务器（例如 Python 的
ssl_context，Go 的http.Server.TLSConfig） - 调用方（如前端服务）使用
https://backend:8443访问，并配置跳过证书校验（开发）或信任 CA（生产） - 示例：Nginx 容器作为反向代理时，可在配置中启用
ssl_certificate和ssl_certificate_key，将 HTTP 流量升级为 HTTPS 内部转发
用 nginx-proxy 或 caddy 做统一 TLS 终止层
适合多个服务共用一套证书，降低重复配置成本：
- 部署一个 Caddy 容器，监听内部网络（
app-secure-net），为其配置自动证书（Caddy 0.27+ 支持内网 ACME 伪签发）或挂载已有证书 - 在 Caddyfile 中设置上游代理：
backend.example { reverse_proxy https://backend:8443 } - 其他服务只与 Caddy 通信（HTTP 或 HTTPS），由 Caddy 负责加解密和证书管理
- 优势：业务代码无需改动 TLS，证书轮换集中处理；缺点：多一层转发延迟（通常可忽略）
数据库等敏感服务强制启用加密连接
不能只靠网络隔离，必须叠加传输层加密：
- PostgreSQL 启动时加参数：
-c ssl=on -c ssl_cert_file=/etc/ssl/certs/server.crt -c ssl_key_file=/etc/ssl/private/server.key - MySQL 设置
require_secure_transport=ON，并挂载 PEM 证书 - 应用连接字符串明确指定
sslmode=require（PG）或?tls=true（MySQL），拒绝非加密连接 - 验证方式：进入客户端容器执行
psql "host=db user=app dbname=test sslmode=require"，失败即说明配置生效
