Docker sandbox AI coding agent: cấu hình an toàn

Bạn có đang để AI coding agent chạy lệnh trực tiếp trên máy dev hoặc repo thật không? Nếu agent chỉ đọc file thì rủi ro còn kiểm soát được, nhưng khi nó có quyền chạy terminal, cài package, sửa file hoặc gọi network, một prompt sai có thể biến thành thay đổi rất khó lần ngược.

Docker sandbox AI coding agent là cách thực tế để tạo một lớp cách ly trước khi cho agent thao tác với code. Nó không biến môi trường thành tuyệt đối an toàn, nhưng giúp bạn giảm phạm vi thiệt hại, ép quyền rõ ràng và dễ audit hơn. Cùng xem nhé!

Docker sandbox cho AI coding agent là gì?

Docker sandbox là môi trường container được cấu hình để agent chỉ nhìn thấy phần repo và quyền cần thiết cho một task cụ thể. Thay vì cho agent chạy trên host, bạn đặt nó vào một không gian có filesystem, process, network và tài nguyên bị giới hạn.

Docker dùng các cơ chế của Linux như namespaces, cgroups và capabilities để cô lập tiến trình container với host [1]. Đây là nền tảng tốt cho workflow AI coding agent, vì agent thường cần làm nhiều việc giống lập trình viên: đọc code, chạy test, cài dependency và tạo diff.

Điểm cần nói thẳng: container không phải máy ảo bảo mật tuyệt đối. Nếu bạn mount nhầm Docker socket, đưa secrets thật vào env, hoặc chạy container với quyền quá rộng, sandbox có thể mất ý nghĩa. Docker docs cũng nhấn mạnh daemon và socket Docker là bề mặt quyền rất mạnh cần được bảo vệ [1].

Bạn đang đọc bài viết thuộc chuyên mục Lập trình của VietnamTutor — nơi mình ưu tiên cách triển khai có thể dùng trong repo thật, không chỉ demo cho đẹp.

Những rủi ro nào cần chặn trước?

Trước khi cấu hình Docker, bạn cần biết mình đang chặn rủi ro nào: đọc nhầm dữ liệu, sửa nhầm file, gọi network ngoài ý muốn, làm lộ secrets hoặc chạy lệnh phá môi trường. Nếu không định nghĩa rủi ro, bạn rất dễ tạo một container “có vẻ an toàn” nhưng vẫn mở mọi quyền quan trọng.

Với AI coding agent, rủi ro phổ biến nhất là mount quá rộng. Ví dụ, nếu bạn mount cả thư mục home, agent có thể nhìn thấy SSH keys, cloud credentials, file cấu hình cá nhân hoặc dự án khác. Nếu mount Docker socket, container có thể điều khiển Docker daemon trên host, tạo thêm container privileged hoặc đọc volume khác.

Rủi ro thứ hai là network. Agent có thể cần internet để đọc docs hoặc tải package, nhưng network mở toàn bộ khiến dữ liệu repo, log hoặc prompt nhạy cảm dễ bị gửi ra ngoài nếu toolchain bị cấu hình sai. Với task chỉ chạy unit test, mình khuyên tắt network trước; cần internet thì bật có lý do.

Rủi ro thứ ba là tài nguyên. Một lệnh build lỗi, test treo hoặc script sinh file vô hạn có thể ăn hết CPU, RAM hoặc disk. Docker hỗ trợ giới hạn memory và CPU để tránh container làm nghẹt host [5]. Đây là lớp nhỏ nhưng rất thực dụng.

Cấu hình docker run an toàn nên gồm gì?

Một lệnh sandbox tốt nên giới hạn user, filesystem, capabilities, network và tài nguyên ngay từ đầu. Bạn không cần làm quá phức tạp trong ngày đầu, nhưng đừng chạy container như root với mount rộng và network mở mặc định.

Ví dụ dưới đây minh họa một sandbox tối thiểu cho task đọc repo, chạy test và tạo diff. Bạn cần điều chỉnh image, command và thư mục theo stack thật của mình.

docker run --rm -it \
  --name ai-agent-sandbox \
  --user 1000:1000 \
  --workdir /workspace \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=512m \
  --mount type=bind,src="$PWD",dst=/workspace,rw \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 256 \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  node:22-bookworm \
  bash

Ý nghĩa chính: container chạy bằng user thường, thư mục gốc read-only, chỉ workspace được mount, network tắt, tài nguyên bị giới hạn và capability bị drop. Docker CLI hỗ trợ các cờ này trong docker run, còn seccomp/AppArmor có thể thêm khi team cần kiểm soát sâu hơn [3][4][6].

Nếu task cần cài dependency, bạn có thể mount thêm cache riêng thay vì mở toàn bộ home. Nếu task cần internet, hãy bật network có chủ đích và ghi lại lý do trong pull request. Cách làm này hơi chậm hơn một chút, nhưng rất đáng khi repo có dữ liệu khách hàng hoặc credential thật.

Dùng Docker Compose cho workflow hằng ngày thế nào?

Docker Compose giúp team chuẩn hóa sandbox thành file dùng lại được, thay vì mỗi người nhớ một lệnh dài khác nhau. Với AI coding agent, Compose phù hợp khi bạn cần thêm database giả, service mock hoặc cache riêng cho test.

Ví dụ Compose dưới đây giữ cùng tinh thần: user non-root, network nội bộ, resource limit, không mount secrets thật và không mở Docker socket. Bạn có thể thêm service database bằng dữ liệu synthetic thay vì dump production.

services:
  agent:
    image: node:22-bookworm
    working_dir: /workspace
    user: "1000:1000"
    command: bash
    read_only: true
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=512m
    volumes:
      - ./:/workspace:rw
      - agent-cache:/home/node/.cache:rw
    networks:
      - agent-net
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    mem_limit: 2g
    cpus: 2

networks:
  agent-net:
    internal: true

volumes:
  agent-cache:

Compose không tự động giải quyết mọi vấn đề. Bạn vẫn cần .dockerignore, .gitignore, secret scanning và policy cho lệnh được phép. Nếu team đang chuẩn hóa môi trường dev, bài Docker Compose best practices sẽ là bước đọc tiếp rất hợp.

Checklist áp dụng trong team kỹ thuật

Sandbox chỉ có giá trị khi nó đi cùng quy trình review và rule vận hành rõ ràng. Nếu agent có thể tự ý sửa code, chạy lệnh và merge mà không ai xem diff, Docker chỉ là một lớp vỏ mỏng.

Mình khuyên bạn bắt đầu bằng checklist sau:

• Repo: chỉ mount đúng thư mục cần xử lý, tránh mount toàn bộ home.
• Secrets: không truyền .env thật, không mount SSH keys, không để cloud credentials trong workspace.
• User: chạy non-root; cân nhắc rootless mode nếu phù hợp với môi trường [2].
• Filesystem: bật read-only root filesystem, dùng tmpfs/cache riêng cho file tạm.
• Network: mặc định none hoặc internal; chỉ bật internet khi task cần.
• Kernel surface: drop capabilities, dùng seccomp/AppArmor profile khi team có năng lực vận hành [3][4].
• Resource: giới hạn CPU, RAM và số process để tránh task runaway [5].
• Review: mọi thay đổi phải đi qua branch riêng, test và review diff.

Cách nghĩ này rất gần với Context Engineering cho workflow AI coding: bạn không chỉ viết prompt, mà còn thiết kế môi trường, rule và feedback loop để agent làm đúng việc. Nếu đang lo agent sinh lỗ hổng, đọc thêm bảo mật vibe coding và checklist kiểm thử code do AI tạo.

Nguồn tham khảo

1. Docker Docs: Docker Engine security
2. Docker Docs: Rootless mode
3. Docker Docs: Seccomp security profiles
4. Docker Docs: AppArmor security profiles
5. Docker Docs: Runtime resource constraints
6. Docker Docs: docker container run reference
7. Anthropic Docs: Claude Code security
8. OpenAI: Codex GitHub repository

Docker sandbox là một bước rất đáng làm nếu bạn dùng AI coding agent trong repo thật. Hãy bắt đầu nhỏ: mount đúng thư mục, tắt network khi không cần, chạy non-root, giới hạn tài nguyên và luôn review diff trước khi merge.

Mình khuyên bạn coi sandbox như một quy trình vận hành chứ không phải một mẹo Docker. Khi môi trường, quyền và approval rõ ràng, AI coding agent sẽ hữu ích hơn và ít tạo rủi ro âm thầm hơn.