Quản lý Docker Networks: Cho các Container giao tiếp an toàn với nhau
Hướng dẫn Docker Networks toàn diện: bridge, host, none, overlay, service discovery, port publishing, Compose network segmentation, internal networks, bảo mật và debug kết nối.
ShanverseUpdated 9 min read— viewsLoading views
Docker
Deployment
Docker Network là gì?
Mỗi Container có network namespace riêng: interface, IP, routing table và port riêng. Docker Network kết nối các namespace này với nhau, với host hoặc với mạng bên ngoài.
Một topology phổ biến:
Mermaid
Loading diagram…
Mục tiêu:
User chỉ truy cập reverse proxy.
Proxy chỉ cần truy cập API.
API cần truy cập database.
Database không cần public ra host hoặc Internet.
Ba loại địa chỉ dễ nhầm
Từ API Container, localhost:5432
Comments
không phải PostgreSQL Container. Hãy dùng tên service/network alias.
Network drivers quan trọng
bridge
Driver mặc định cho Container trên một Docker host. User-defined bridge phù hợp với phần lớn local development và single-host deployment.
Ưu điểm:
DNS theo tên Container/service.
Cô lập nhóm workload.
Có thể attach/detach Container.
Không cần publish port cho giao tiếp nội bộ.
host
Container dùng trực tiếp network namespace của host trên nền tảng được hỗ trợ.
Ít isolation hơn.
Dễ xung đột port.
ports mapping không còn ý nghĩa như bridge.
Chỉ nên dùng khi đã hiểu rõ yêu cầu hiệu năng hoặc network đặc biệt.
none
Container chỉ có loopback, không kết nối network ngoài.
Phù hợp với job xử lý offline, parse file hoặc workload cần cô lập network hoàn toàn.
overlay
Kết nối service qua nhiều Docker host, thường dùng với Docker Swarm. Cần hạ tầng và control plane phù hợp; không thay user-defined bridge cho ứng dụng một host.
macvlan và ipvlan
Cho Container xuất hiện gần như thiết bị riêng trên mạng vật lý hoặc kiểm soát L2/L3 nâng cao. Đây là lựa chọn chuyên biệt:
Phải phối hợp subnet, gateway và network team.
Có thể phát sinh hạn chế giao tiếp host ↔ Container.
Dễ xung đột IP nếu IPAM không được quản lý.
Vì sao nên dùng user-defined bridge?
Liệt kê network:
Tạo network riêng:
Chạy PostgreSQL:
Chạy API trên cùng network:
API dùng hostname postgres; không cần biết IP động của database.
Port Container khác port host
Ứng dụng Node.js lắng nghe:
Publish ra host:
Ý nghĩa:
Container khác trên cùng network vẫn gọi api:3000, không gọi port host 8080.
0.0.0.0 và 127.0.0.1 khi publish
thường publish trên mọi interface host. Nếu chỉ cần truy cập local:
Việc bind loopback giảm phạm vi truy cập, nhưng không thay authentication hoặc firewall policy.
Không cần publish port cho giao tiếp nội bộ
Database chỉ cần được API truy cập:
Không cần:
ports tạo đường từ host tới Container. Giao tiếp giữa service dùng shared Docker Network.
expose không phải firewall rule
expose mô tả port nội bộ và có thể giúp tài liệu/tooling, nhưng không tạo ACL. Container trên cùng network có thể kết nối tới port mà process đang listen ngay cả khi không khai báo expose.
Phân đoạn network theo trust boundary
Thay vì đặt tất cả service vào một network, tách:
edge: proxy ↔ API.
data: API ↔ database.
Mermaid
Loading diagram…
Proxy không tham gia data, nên không kết nối trực tiếp đến database. Database không tham gia edge, nên không nhìn thấy proxy.
Docker Compose mẫu an toàn hơn
nginx.conf tối thiểu:
Điểm bảo mật:
Chỉ proxy publish port.
API không publish ra host.
PostgreSQL không publish port.
Proxy và database không dùng chung network.
data là internal network.
Config Nginx được mount read-only.
internal: true làm gì?
Network internal hạn chế kết nối ra ngoài qua network đó. Nó phù hợp với database tier không cần egress.
Trong ví dụ, API còn tham gia edge, nên API vẫn có thể có đường egress qua network khác. internal: true không phải policy engine theo domain/URL và không tự chặn một Container đã tham gia cùng network.
Network alias
Khai báo alias ổn định:
Proxy có thể gọi backend-api:3000. Tránh dùng alias trùng nhau nếu client không được thiết kế để xử lý nhiều IP.
Kết nối và ngắt Container lúc runtime
Xem chi tiết network:
Ngắt network có thể làm hỏng connection đang hoạt động. Trong production, ưu tiên thay đổi declarative rồi recreate/rollout có kiểm soát.
IPAM và tránh xung đột subnet
Tạo subnet rõ ràng:
Chỉ cấu hình khi cần. Subnet Docker trùng VPN, VPC hoặc office LAN có thể gây route sai. Hãy quản lý dải địa chỉ tập trung thay vì chọn ngẫu nhiên trên từng host.
Compose:
Static IP thường nên tránh; DNS service discovery linh hoạt hơn.
Network isolation không đồng nghĩa với mã hóa
Docker Network giúp giới hạn reachability nhưng không tự đảm bảo:
Dữ liệu được mã hóa.
Client được xác thực.
Service được ủy quyền đúng.
Container bị compromise không thể tấn công peer cùng network.
Với dữ liệu nhạy cảm:
Dùng TLS/mTLS khi threat model yêu cầu.
Bật authentication cho database và cache.
Dùng user quyền tối thiểu.
Rotate secret.
Validate input và rate limit.
Dùng network policy/firewall bổ sung theo môi trường.
Nguyên tắc least privilege cho Docker Networks
Một service chỉ tham gia network cần thiết.
Chỉ ingress/reverse proxy publish public port.
Database/cache không publish trừ nhu cầu quản trị có kiểm soát.
Bind local tool port vào 127.0.0.1.
Dùng user-defined network thay cho nhét mọi thứ vào một network chung.
Không mount Docker socket vào application Container.
Không dùng --privileged chỉ để sửa lỗi network.
Drop capability không cần thiết và dùng read-only filesystem khi phù hợp.
Dùng TLS/authentication ngoài network isolation.
Audit network membership và published ports định kỳ.
Host firewall và Docker
Trên Linux, Docker có thể quản lý iptables/nftables rules để NAT và publish port. Một firewall host cấu hình thiếu có thể không tạo kết quả như bạn dự đoán.
Kiểm tra port từ một máy bên ngoài, không chỉ từ localhost.
Áp dụng policy theo hướng dẫn firewall của môi trường.
Kiểm tra chain dành cho rule do người dùng quản lý khi dùng Docker Engine.
Không sửa rule Docker-generated thủ công mà không hiểu lifecycle.
Hạn chế quyền truy cập Docker daemon; quyền điều khiển daemon gần tương đương quyền cao trên host.
IPv6 và dual stack
Chỉ bật IPv6 khi hạ tầng, firewall và monitoring đều hỗ trợ. Đừng giả định rule IPv4 tự bảo vệ IPv6. Kiểm tra:
Address allocation.
DNS records.
Ingress binding.
Firewall cho cả hai protocol.
Application listen address.
Debug Container không kết nối được
1. Kiểm tra network membership
Hoặc:
2. Kiểm tra DNS
Nếu Image quá tối giản:
Chỉ dùng debug Image từ nguồn tin cậy và xóa sau khi dùng.
3. Kiểm tra port đang listen
Trong service đích:
Nếu app chỉ bind 127.0.0.1, Container khác không thể truy cập. Bind 0.0.0.0 hoặc địa chỉ interface phù hợp.
4. Kiểm tra TCP/HTTP
5. Kiểm tra mapping port
6. Đọc log
Lỗi phổ biến
Dùng localhost để gọi Container khác
Dùng tên service: postgres, redis, api.
Publish mọi port
Làm tăng bề mặt tấn công và xung đột port host.
Đặt toàn bộ stack vào một network
Mọi service có reachability rộng hơn nhu cầu.
Nghĩ expose là access control
Nó không thay network segmentation hoặc firewall.
Dùng IP Container cố định
IP thay đổi khi recreate và làm cấu hình khó scale.
Cho database chạy không authentication vì “đã ở private network”
Container cùng network hoặc workload bị compromise vẫn có thể truy cập.
Dùng network_mode: host để né lỗi DNS
Đây là bỏ isolation chứ không sửa root cause.
Xóa network bừa bãi
Prune là thao tác xóa network không dùng. Kiểm tra kỹ shared host và Compose projects trước khi xác nhận.
Checklist production
Mỗi trust boundary có network riêng.
Chỉ ingress service publish public port.
Database và cache không public trực tiếp.
Service gọi nhau bằng DNS name, không hard-code IP.
App bind đúng interface trong Container.
internal: true được dùng cho tier không cần egress.
Authentication vẫn bật trên database/cache.
TLS/mTLS được áp dụng theo threat model.
Host firewall được test từ bên ngoài.
Docker socket không mount vào workload thông thường.
Subnet không trùng VPN/VPC/LAN.
Published ports và network membership được audit.
Monitoring có network errors, latency và connection saturation.
Tổng kết
Thiết kế Docker Network an toàn tuân theo dependency graph:
Hướng dẫn tự động deploy ứng dụng Docker lên VPS Ubuntu và cloud providers bằng GitHub Actions: AWS ECS/App Runner/EC2, Vercel, Render, secrets, healthcheck, rollback và zero-downtime strategy.
