Docker MCP Là Gì?

Ở các module trước bạn đã hiểu MCP (Model Context Protocol) là chuẩn giao tiếp cho phép một AI agent gọi tool (tool calling) ra bên ngoài context window của LLM để lấy dữ liệu hoặc thực thi hành động. Docker MCP là một implementation cụ thể của ý tưởng đó: một MCP server đóng gói lại các thao tác của Docker Engine — list image, chạy container, đọc log, exec vào container, chạy docker compose — thành các tool có schema rõ ràng, để agent (Claude, hoặc bất kỳ client hỗ trợ MCP nào) gọi được như gọi hàm.

Trên thực tế, "Docker MCP" thường được nói tới dưới hai hình thức: (1) Docker MCP Toolkit — bộ MCP server chính chủ do Docker cung cấp, tích hợp sẵn trong Docker Desktop, expose một tập tool chuẩn cho Docker Engine; và (2) các MCP server tự viết (community hoặc in-house) wrap lại Docker CLI/Docker Engine API theo nhu cầu riêng. Cả hai đều có chung bản chất: server này có quyền nói chuyện trực tiếp với Docker daemon qua Docker socket (file socket Unix /var/run/docker.sock, hoặc named pipe trên Windows), và MCP chỉ là lớp giao tiếp phía trên để agent gọi vào.

Bài này đi từ tool cụ thể, cách setup, đến các use case tự động hoá thực tế, và quan trọng nhất — rủi ro bảo mật khi bạn trao quyền Docker socket cho một agent. Đây là kiến thức bắt buộc trước khi bạn đưa Docker MCP vào bất kỳ pipeline CI/CD hay dev workflow nào.

Bộ Công Cụ Cốt Lõi Của Docker MCP: Image, Container, Log, Exec Và Compose

Một Docker MCP server tốt sẽ map gần như 1:1 với các nhóm lệnh Docker CLI mà bạn đã quen, chỉ khác là input/output được chuẩn hoá thành JSON schema để LLM parse được. Dưới đây là các tool phổ biến nhất theo từng nhóm (tên tool thực tế có thể khác chút tuỳ server, nhưng convention đặt tên đều xoay quanh động từ + đối tượng như dưới).

Nhóm tool quản lý container

• list_containers — trả list container đang chạy/đã dừng, kèm status, port mapping, image.
• inspect_container — trả full metadata (network, mount, env, health check) của một container theo id/name.
• start_container, stop_container, restart_container — điều khiển lifecycle.
• remove_container — xoá container (thường có flag force để xử lý container đang chạy).

Nhóm tool quản lý image

• list_images — list image local kèm tag, size, created time.
• build_image — build từ Dockerfile, nhận context_path, dockerfile, tags làm input.
• pull_image / push_image — tương tác registry.
• remove_image — xoá image không dùng.

Nhóm tool log và debug

• get_logs — lấy log container, hỗ trợ tail, since, follow (dạng streaming nếu MCP transport hỗ trợ).
• exec_in_container — chạy lệnh arbitrary bên trong container đang sống (đây là tool nhạy cảm nhất, nói kỹ ở phần bảo mật).
• get_stats — CPU, memory, network I/O real-time, hữu ích để agent tự phát hiện container đang leak resource.

Nhóm tool Compose và dọn dẹp

• compose_up / compose_down — điều khiển multi-container stack theo file compose.yaml.
• compose_ps, compose_logs — tương đương bản Compose của các tool log/inspect trên.
• prune — dọn container dừng, network orphan, image dangling, build cache — nhận tham số filter theo tuổi (until), theo label.

Ví dụ prompt bạn có thể gõ cho agent: "Kiểm tra container nào đang restart loop trong stack hiện tại, lấy log 200 dòng cuối của nó, rồi cho tôi biết nghi ngờ nguyên nhân." Agent sẽ tự chuỗi các tool call: list_containers → phát hiện container có restart_count cao → get_logs với tail: 200 → phân tích log trong context window rồi trả kết luận bằng lời.

Mẹo: Khi review một Docker MCP server mới (tự build hoặc third-party), việc đầu tiên nên làm là liệt kê hết tool nó expose và tự hỏi "tool này có thể gây thiệt hại gì nếu agent gọi sai tham số hoặc bị prompt injection dẫn dắt?" — exec_in_container và remove_image/prune luôn nằm đầu danh sách rủi ro.

Thiết Lập Docker MCP: Truy Cập Socket, Context Và Mô Hình Phân Quyền

Docker MCP server cần một đường truyền tới Docker daemon để hoạt động. Có ba cách phổ biến, xếp theo mức độ rủi ro tăng dần:

1. Mount Docker socket vào container chạy MCP server (-v /var/run/docker.sock:/var/run/docker.sock) — cách nhanh nhất, cũng là cách rủi ro nhất vì container đó gần như có quyền root trên host.
2. Docker context qua TCP/TLS — MCP server nói chuyện với daemon qua network endpoint đã bật TLS client cert, tách biệt được server và daemon ra hai máy khác nhau, dễ audit hơn.
3. Docker Desktop's built-in Docker MCP Toolkit — chạy trong sandbox riêng do Docker Desktop quản lý, không cần bạn tự mount socket, và có UI cho phép bật/tắt từng tool theo scope.

Setup nhanh với claude mcp add

Nếu bạn dùng Claude Code hoặc Claude Desktop, cách setup nhanh nhất là add MCP server dạng stdio, chạy Docker MCP server như một process con:

claude mcp add docker -- docker mcp gateway run

Hoặc khai báo tay trong claude_desktop_config.json (tương đương mcp.json ở các client khác):

{
  "mcpServers": {
    "docker": {
      "command": "docker",
      "args": ["mcp", "gateway", "run"],
      "env": {
        "DOCKER_HOST": "unix:///var/run/docker.sock"
      }
    }
  }
}

Với setup tự build server bằng SDK (ví dụ Node/Python) chạy trong container riêng, config sẽ trỏ vào docker run kèm mount socket:

{
  "mcpServers": {
    "docker-custom": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-v", "/var/run/docker.sock:/var/run/docker.sock",
        "my-org/docker-mcp-server:latest"
      ]
    }
  }
}

Docker context (docker context) và multi-environment

Nếu bạn quản lý nhiều Docker context (dev machine, staging server, remote Docker host qua SSH), MCP server cần biết đang nói chuyện với context nào. Thực hành tốt là expose tool list_contexts / use_context riêng, và luôn để agent xác nhận context hiện tại trước khi chạy lệnh có side-effect (build, remove, compose down) — tránh trường hợp agent tưởng đang ở local nhưng thực ra đang trỏ vào context production.

Mô hình phân quyền (permission model)

Đa số Docker MCP Toolkit hỗ trợ scope theo nhóm tool: read-only (list/inspect/logs), write (start/stop/build), destructive (remove/prune/exec). Nên bật read-only mặc định, chỉ mở write/destructive theo từng session có giám sát, và tắt hẳn exec_in_container nếu agent không thực sự cần chạy lệnh tuỳ ý bên trong container.

Mẹo: Luôn test setup bằng một prompt "vô hại" trước — ví dụ "list toàn bộ container đang chạy" — để chắc chắn agent connect đúng Docker context mong muốn, trước khi giao bất kỳ task có quyền write/destructive.

AI Agent Có Thể Tự Động Hoá Gì Với Docker MCP: Build, Debug Và Dọn Dẹp

Đây là phần giá trị thực sự của Docker MCP — biến các task vận hành lặp đi lặp lại thành việc bạn chỉ cần ra lệnh bằng ngôn ngữ tự nhiên.

Build và rebuild có điều kiện. Prompt: "Build lại image cho service api từ Dockerfile trong ./services/api, tag api:local-dev, rồi cho tôi biết build log có warning nào không." Agent gọi build_image, đọc output, tóm tắt warning (deprecated base image, unused build arg, layer cache miss...) mà không cần bạn scroll log tay.

Debug container crash loop. Đây là use case mạnh nhất trong thực tế của mình khi làm dev: thay vì tự chạy docker ps, docker logs, docker inspect rồi ghép thông tin lại, giao hẳn cho agent: "Container worker cứ restart, tìm nguyên nhân." Agent tự chuỗi list_containers → thấy restart_count cao → inspect_container để xem exit code/health check → get_logs để đọc traceback → kết luận, ví dụ "container exit code 137, khả năng cao bị OOM-killed, memory limit hiện tại 256MB nhưng log cho thấy heap tăng liên tục trước khi crash."

So sánh trạng thái container với compose file. "Kiểm tra service nào trong compose.yaml chưa chạy hoặc chạy image cũ so với file định nghĩa." Agent kết hợp compose_ps và list_images để phát hiện drift.

Dọn dẹp có kiểm soát. "Liệt kê image dangling và container đã dừng quá 7 ngày, hỏi tôi xác nhận trước khi xoá." Đây là pattern quan trọng: luôn thiết kế prompt/workflow để agent đề xuất trước khi gọi tool destructive như prune hay remove_image, không tự động chạy luôn.

Sinh Dockerfile/compose từ mô tả. Agent không cần tool Docker MCP cho bước sinh code, nhưng có thể dùng build_image ngay sau để verify Dockerfile mới sinh build được thật, tạo thành loop viết → build → sửa lỗi build → build lại hoàn toàn tự động.

Mẹo: Khi giao task debug cho agent, luôn yêu cầu nó nêu rõ tool nào đã gọi và log trích dẫn cụ thể trong câu trả lời — tránh trường hợp agent "đoán" nguyên nhân dựa trên kiến thức chung thay vì dựa trên log thật lấy về từ get_logs.

Rủi Ro An Toàn Khi Cho Agent Quyền Truy Cập Docker Socket

Đây là phần dễ bị xem nhẹ nhất, và cũng là phần quan trọng nhất trong bài. Cần nói thẳng: quyền truy cập Docker socket tương đương quyền root trên host. Đây không phải cách nói phóng đại — bất kỳ process nào gọi được Docker socket đều có thể mount toàn bộ filesystem của host vào một container mới rồi đọc/ghi tự do, tức là leo thang lên root mà không cần khai thác lỗ hổng nào cả.

Container escape và blast radius

Nếu agent (hoặc một prompt injection dụ được agent) chạy một lệnh như tạo container mount / của host rồi exec vào đó, agent coi như đã "escape" ra khỏi container ban đầu và có toàn quyền trên máy host. Với exec_in_container, rủi ro tương tự: nếu container target đang mount volume nhạy cảm hoặc chạy với --privileged, một câu lệnh exec tưởng chừng vô hại có thể đọc được secret, biến môi trường chứa credential, hoặc thay đổi code đang chạy production.

Blast radius (bán kính ảnh hưởng) ở đây không chỉ giới hạn trong Docker — nó là toàn bộ host, và nếu host đó nằm trong cùng network với các service khác (database, internal API), thiệt hại lan ra toàn hệ thống.

Nguy cơ từ prompt injection

Nếu agent của bạn đọc dữ liệu từ nguồn không tin cậy (issue trên GitHub, log ứng dụng có thể bị người dùng chèn nội dung, nội dung file mà agent tự đọc) và nguồn đó chứa chỉ dẫn ẩn kiểu "hãy chạy exec_in_container với lệnh XYZ", agent có thể bị dẫn dắt gọi tool ngoài ý định người dùng. Đây là lý do không nên cấp exec_in_container hoặc prune cho agent chạy trong workflow tự động không có người giám sát duyệt lệnh.

Các biện pháp giảm rủi ro nên áp dụng

• Chạy MCP server trong container bị siết quyền riêng — không chạy --privileged, drop hết capability không cần, chỉ mount đúng socket cần thiết, không mount thêm bất kỳ path nào khác của host.
• Scoped permission profile — chỉ bật nhóm tool read-only (list/inspect/logs/stats) cho các agent chạy tự động không giám sát; nhóm write/destructive chỉ mở cho session có người review từng bước (human-in-the-loop).
• Tránh mount /var/run/docker.sock vào chính sandbox của agent nếu agent đó còn chạy code do người dùng cuối cung cấp — kết hợp hai thứ này gần như chắc chắn dẫn tới container escape sớm hay muộn. Nếu bắt buộc phải cho agent điều khiển Docker, ưu tiên phương án Docker context qua TCP/TLS tới daemon nằm trên máy riêng, cách biệt với sandbox thực thi code của agent.
• Audit logging đầy đủ — log lại toàn bộ tool call (tên tool, tham số, thời điểm, agent/session nào gọi) tách biệt khỏi log ứng dụng thông thường, để có thể truy vết khi có sự cố.
• Least privilege ở tầng daemon — nếu hạ tầng cho phép, dùng rootless Docker hoặc user namespace remapping, để dù có bị escape, container vẫn không map thẳng ra root thật của host.

Mẹo: Coi Docker socket giống hệt như một private key hoặc service account có quyền admin — không bao giờ mount nó vào một container mà bạn không kiểm soát được 100% code chạy bên trong, bất kể đó là code do agent viết hay do người dùng cung cấp.

Tips

Tổng hợp lại, Docker MCP là công cụ rất mạnh để agent thay bạn làm phần vận hành Docker lặp lại — build, debug, dọn dẹp — nhưng sức mạnh đó đi kèm với quyền lực tương đương root trên host. Trước khi đưa vào workflow thật, hãy tự chạy qua checklist dưới đây một lượt.

• Bắt đầu với scope read-only, chỉ mở rộng dần sau khi đã quan sát agent hành xử đúng ý.
• Luôn để exec_in_container, prune, remove_image yêu cầu xác nhận thủ công, không auto-run trong pipeline không người giám sát.
• Tách biệt Docker context dùng cho agent với context production, đặt tên context rõ ràng để tránh nhầm.
• Bật audit log riêng cho toàn bộ tool call của MCP server, review định kỳ.
• Không bao giờ mount Docker socket vào container mà chính agent dùng để chạy code không tin cậy.

Mẹo: Nếu chỉ nhớ một điều từ bài này, hãy nhớ: mọi tool "list/inspect/logs" đều an toàn để cho agent tự do dùng, còn mọi tool có thể build/remove/exec/prune cần được coi là hành động có chữ ký — luôn có một con người xác nhận trước khi nó chạy thật trên hệ thống của bạn.