1. Giới thiệu

Docker là một công nghệ mang tính cách mạng cho phép các nhà phát triển xây dựng, triển khai và bảo trì ứng dụng một cách nhẹ nhàng, dễ di chuyển và hiệu quả (được gọi là container).

Có thể coi container tương tự như một ‘Virtual Machine’ (Máy ảo) nhưng có những lợi thế bổ sung. Docker container nhẹ, hiệu quả và lý tưởng cho các ứng dụng hiện đại vì chúng đóng gói code và các dependency (phần phụ thuộc) trong khi vẫn chia sẻ kernel của hệ điều hành. Chúng tiêu thụ ít không gian hơn, khởi động nhanh hơn và hỗ trợ khả năng mở rộng cao hơn so với Máy ảo. Trong khi đó, Máy ảo nặng hơn và bao gồm một hệ điều hành đầy đủ cho mỗi instance.

Trong khi Máy ảo cung cấp khả năng cô lập tài nguyên tốt hơn và phù hợp với các hệ thống cũ, container là lựa chọn hàng đầu cho các triển khai hiệu quả tài nguyên, có khả năng mở rộng và dễ di chuyển.

2. Tổng quan toàn diện về Dockerfile

Dockerfile có thể được hình dung là bản thiết kế để xây dựng các Docker image của container. Một Dockerfile chỉ định base image, các file ứng dụng, thư viện cần thiết, cấu hình và các lệnh cần thực thi để xây dựng và chạy ứng dụng.

Mỗi chỉ dẫn trong Dockerfile được thực thi tuần tự để tạo ra một image có thể tái tạo và nhất quán, có thể triển khai dưới dạng container trên các môi trường khác nhau, đảm bảo độ tin cậy, tính di động và hợp lý hóa việc triển khai ứng dụng.

Hiểu cấu trúc và các thành phần của Dockerfile là rất quan trọng để duy trì các tiêu chuẩn bảo mật mạnh mẽ.

3. Hiểu về Bảo mật Docker Container

Bảo mật của một Docker container phụ thuộc nhiều vào Dockerfile của nó. Điều này có nghĩa là các nhà phát triển phải nhận thức rõ về những gì họ đang viết trong Dockerfile. Điều này có nghĩa là chỉ bao gồm các thư viện, base image và cấu hình tùy chỉnh được khai báo rõ ràng trong Dockerfile của bạn đồng thời tránh phần mềm độc hại, các lỗ hổng đã biết và các mối đe dọa khác.

Các cấu hình sai trong Dockerfile có thể dẫn đến các lỗ hổng, thách thức vận hành và sự phức tạp không cần thiết. Dưới đây, chúng ta sẽ đi sâu vào các sai lầm bảo mật quan trọng nhất và ý nghĩa của chúng, giúp các nhà phát triển hiểu tại sao việc cấu hình đúng đắn là rất cần thiết.

3.1 Sử dụng Base image cồng kềnh và không xác minh

Việc sử dụng các image lớn hoặc chưa được xác minh sẽ thêm các gói không cần thiết và các dependency không mong muốn, làm tăng bề mặt tấn công. Các image từ các nguồn không đáng tin cậy có thể chứa phần mềm độc hại hoặc các lỗ hổng có thể lây nhiễm vào pipeline build của bạn.

Điều gì có thể xảy ra?

• Kẻ tấn công có thể chèn phần mềm độc hại vào các base image chưa được xác minh, làm tổn hại toàn bộ pipeline CI/CD của bạn.
• Các image cồng kềnh dẫn đến triển khai chậm hơn và kém hiệu quả khi chạy (runtime inefficiencies).

Ví dụ về sai lầm:

FROM ubuntu:latest

Việc sử dụng ubuntu:latest có nghĩa là bạn có thể kéo một image khác nhau mỗi khi build, tạo ra các môi trường không nhất quán.

Giải pháp: Ghim (Pin) base image của bạn vào một phiên bản cụ thể, đã được xác minh, ưu tiên phiên bản được tối ưu hóa cho bảo mật.

FROM ubuntu:20.04

3.2 Không chọn phiên bản Docker image chính xác

Chọn phiên bản Docker image chính xác. Một bản build trong tương lai có thể đưa vào một phiên bản dependency chưa được kiểm thử hoặc có lỗ hổng, làm hỏng ứng dụng của bạn hoặc lộ ra các lỗ hổng bảo mật.

Điều gì có thể xảy ra:

• Một lỗ hổng zero-day trong một gói cập nhật có thể khiến ứng dụng của bạn bị lộ.
• Các bản build của bạn trở nên không nhất quán, gây khó khăn cho việc khắc phục sự cố và rollback.

Ví dụ về sai lầm:

RUN apt-get update && apt-get install -y curl

Giải pháp: Ghim phiên bản cho các gói đã cài đặt để đảm bảo các bản build có thể dự đoán được.

RUN apt-get update && apt-get install -y curl=7.68.0-1ubuntu2.12

3.3 Chạy dưới quyền người dùng root

Container chạy dưới quyền root có thể thực thi các hoạt động đặc quyền, làm tăng nguy cơ tấn công leo thang đặc quyền. Ngay cả khi container bị xâm nhập, một người dùng không phải root sẽ hạn chế khả năng của kẻ tấn công.

Chuyển sang người dùng không phải root càng sớm càng tốt sẽ giảm thiểu thời gian container chạy dưới quyền root. Điều này làm giảm bề mặt tấn công nếu bất kỳ lệnh nào trong Dockerfile của bạn có lỗ hổng.

Điều gì có thể xảy ra:

• Một kẻ tấn công khai thác lỗ hổng trong ứng dụng của bạn có thể giành quyền root vào host.
• Việc các container bị cấu hình sai thoát khỏi sự cô lập của chúng trở nên dễ dàng hơn.

Ví dụ về sai lầm:

FROM debian:11-slim

# Create a non-root user
RUN groupadd -r appgroup && useradd -r -g appgroup appuser

# Switch to non-root user immediately
USER appuser

# Subsequent commands will not execute as root
WORKDIR /app
COPY . /app
ENTRYPOINT ["./myapp"]

Giải pháp: Tạo một người dùng không phải root và chuyển sang người dùng đó trong Dockerfile của bạn. Gán các quyền cần thiết một cách rõ ràng. Các ứng dụng thường ghi các tệp tạm thời vào các vị trí mặc định như /tmp, nhưng các quyền hạn chế có thể gây ra lỗi. Thư mục /tmp có thể thiếu các quyền thích hợp cho người dùng không phải root. Quyền này có thể được cấp cho một người dùng hoặc nhóm bằng cách sử dụng chown.

RUN groupadd -r appgroup && useradd -r -g appgroup appuser
RUN mkdir -p /app && chown appuser:appgroup /app
WORKDIR /app
USER appuser

3.4 Kết hợp quá nhiều Layer mà không dọn dẹp

Các layer trong Docker image giữ lại mọi trạng thái trung gian, ngay cả khi dữ liệu bị xóa sau đó. Thông tin nhạy cảm hoặc các tệp lớn có thể vô tình vẫn còn trong lịch sử image.

Các công cụ build như gcc hoặc make thường không cần thiết trong image production và có thể bị kẻ tấn công lạm dụng để biên dịch và thực thi mã độc.

Điều gì có thể xảy ra:

• Các tệp tạm thời như build artifact hoặc secret có thể truy cập được thông qua docker history.
• Các image cồng kềnh làm chậm quá trình triển khai và tăng bề mặt tấn công.

Ví dụ về sai lầm:

RUN apt-get update && apt-get install -y git \
    && rm -rf /var/lib/apt/lists/*

Giải pháp: Sử dụng multi-stage build để đảm bảo dữ liệu nhạy cảm và các artifact không cần thiết bị loại trừ khỏi image cuối cùng.

FROM golang:1.19 as builder
WORKDIR /app
COPY . .
RUN go build -o myapp
FROM alpine:3.18
WORKDIR /app
COPY --from=builder /app/myapp .
ENTRYPOINT ["./myapp"]

3.5 Chỉ sử dụng ADD thay vì COPY

Chỉ dẫn ADD cung cấp các chức năng bổ sung (ví dụ: giải nén kho lưu trữ, lấy tệp từ các vị trí từ xa), điều này có thể dẫn đến hành vi không mong muốn hoặc lỗ hổng.

Điều gì có thể xảy ra:

• Nếu kẻ tấn công xâm nhập nguồn từ xa, bản build của bạn sẽ bao gồm nội dung độc hại.
• Các kho lưu trữ có thể ghi đè các tệp quan trọng trong container.

Ví dụ về sai lầm:

ADD https://example.com/app.tar.gz /app/

Giải pháp: Luôn sử dụng COPY cho các tệp cục bộ. Sử dụng các công cụ như wget hoặc curl để tải xuống từ xa, kết hợp với xác minh checksum.

COPY app.tar.gz /app/
RUN tar -xzvf /app/app.tar.gz -C /app/

3.6 Để lộ Secret trong Dockerfile

Việc mã hóa cứng các thông tin nhạy cảm như khóa API, thông tin đăng nhập hoặc chứng chỉ sẽ làm lộ secret của bạn cho bất kỳ ai có thể truy cập image hoặc Dockerfile.

Điều gì có thể xảy ra:

• Secret được commit vào các hệ thống kiểm soát phiên bản có thể bị khai thác bởi những kẻ độc hại.
• Secret bị xâm phạm có thể dẫn đến việc chiếm đoạt tài khoản, rò rỉ dữ liệu hoặc xâm phạm hệ thống.

Ví dụ về sai lầm:

ENV API_KEY=12345

Giải pháp: Sử dụng các công cụ quản lý secret như Vault, AWS Secrets Manager hoặc cờ --secret của Docker để truyền thông tin nhạy cảm một cách an toàn tại thời điểm chạy (runtime).

RUN --mount=type=secret,id=api_key echo "API key mounted securely."

3.7 Bỏ qua Health Check

Nếu không có health check, Docker không thể xác định liệu ứng dụng của bạn có hoạt động đúng cách hay không. Điều này có thể dẫn đến các lỗi không bị phát hiện trong production.

Điều gì có thể xảy ra:

• Ứng dụng có thể tiếp tục chạy trong trạng thái bị suy giảm.
• Các công cụ giám sát có thể không phát hiện được các lỗi nghiêm trọng.

Giải pháp: Xác định các health check có ý nghĩa để đảm bảo container luôn hoạt động.

HEALTHCHECK --interval=30s --timeout=5s \
  CMD curl -f http://localhost/health || exit 1

3.8 Bỏ qua các Hồ sơ bảo mật (Security Profiles)

Chạy container mà không có các hồ sơ bảo mật hạn chế (ví dụ: Seccomp, AppArmor) cho phép chúng thực hiện các lệnh gọi hệ thống (syscall) nguy hiểm, khiến host bị tấn công.

Điều gì có thể xảy ra:

• Kẻ tấn công có thể sử dụng các syscall như ptrace để trích xuất dữ liệu tiến trình nhạy cảm.
• Các cuộc khai thác như thoát khỏi container (container escapes) trở nên khả thi.

Giải pháp: Bật hồ sơ Seccomp mặc định của Docker hoặc xác định các hồ sơ tùy chỉnh cho ứng dụng của bạn.

docker run --security-opt seccomp=default.json myimage

3.9 Ví dụ về một Dockerfile bảo mật lý tưởng

# Use a minimal base image
FROM debian:11-slim
# Install dependencies securely
RUN apt-get update && apt-get install -y --no-install-recommends \
 curl=7.74.0-1.3+deb11u7 \
 ca-certificates \
 && rm -rf /var/lib/apt/lists/*
# Create a non-root user
RUN groupadd -r appgroup && useradd -r -g appgroup appuser
# Set working directory and permissions
WORKDIR /app
COPY --chown=appuser:appgroup . /app
# Switch to non-root user
USER appuser
# Define entrypoint and health check
ENTRYPOINT ["./myapp"]
HEALTHCHECK --interval=30s --timeout=5s CMD curl -f http://localhost/health || exit 1

4. Ví dụ thực tế: Xây dựng một Dockerfile an toàn

Hãy cùng tìm hiểu cách tạo một Dockerfile an toàn và sẵn sàng cho production cho một ứng dụng Golang. Ví dụ này sử dụng multi-stage build, người dùng không phải root, và minimal base image để đảm bảo bảo mật, hiệu quả và khả năng bảo trì.

Hãy xem Dockerfile trước, sau đó chúng ta sẽ phân tích từng dòng để hiểu cách nó an toàn và tối ưu!

# Stage 1: Build the application
FROM golang:1.20 AS builder

# Set metadata
LABEL maintainer="vuquoc97.work@gmail.com" \
      description="Secure and optimized Dockerfile for a Golang application"

# Set working directory
WORKDIR /app

# Copy go.mod and go.sum for dependency caching
COPY go.mod go.sum ./

# Download dependencies
RUN go mod download

# Copy the application code
COPY . .

# Build the application binary
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o main .

# Stage 2: Create a minimal, production-ready image
FROM gcr.io/distroless/static:nonroot

# Set metadata
LABEL version="1.0.0"

# Set working directory
WORKDIR /app

# Copy the application binary from the builder stage
COPY --from=builder /app/main .

# Set the application to run as a non-root user
USER nonroot:nonroot

# Expose the application port
EXPOSE 8080

# Implement a health check
HEALTHCHECK --interval=30s --timeout=5s \
  CMD [ "curl", "-f", "http://localhost:8080/health" ]

# Start the application
CMD ["./main"]

4.1. Phân tích từng bước

Hãy cùng tìm hiểu cách viết một Dockerfile an toàn và tối ưu, lấy ví dụ về việc docker hóa một dự án Golang.

4.1.1. Multi-Stage Build:

• Giai đoạn đầu tiên (golang:1.20) được sử dụng để biên dịch ứng dụng, đảm bảo các công cụ phát triển không được bao gồm trong image cuối cùng.
• Giai đoạn thứ hai (distroless/static:nonroot) là một base image nhẹ và an toàn được thiết kế đặc biệt cho việc sử dụng trong production, không có shell hoặc các tiện ích không cần thiết.

4.1.2. Dependency Caching:

• Bằng cách sao chép go.mod và go.sum trước code ứng dụng, Docker có thể cache layer cài đặt dependency, giảm thời gian build khi các dependency không thay đổi.

4.1.3. Static Binary Compilation:

• Ứng dụng được biên dịch với CGO_ENABLED=0, vô hiệu hóa các dependency C và tạo ra một binary hoàn toàn tĩnh để tương thích và bảo mật tốt hơn.

4.1.4. Non-Root User:

• Image distroless/static:nonroot sử dụng người dùng không phải root mặc định (nonroot), ngăn chặn các cuộc tấn công leo thang đặc quyền.

4.1.5. Minimal Base Image:

• Image distroless chỉ chứa các thư viện cần thiết để chạy binary, giảm đáng kể bề mặt tấn công.

4.1.6. Health Check:

• Docker giám sát tình trạng ứng dụng và tự động khởi động lại nếu nó không phản hồi.

4.1.7. Port Exposure:

• Chỉ dẫn EXPOSE tài liệu hóa cổng dự kiến của container (8080) để truy cập bên ngoài.

4.1.8. Size Optimization:

• Sử dụng -ldflags="-w -s" trong quá trình build giúp giảm kích thước của binary bằng cách loại bỏ thông tin gỡ lỗi.

5. Kết luận

Xây dựng các Docker container an toàn không chỉ là một thực hành tốt mà còn là một sự cần thiết trong bối cảnh mối đe dọa ngày càng phát triển hiện nay. Một Dockerfile được viết tốt tạo thành nền tảng của một ứng dụng container hóa an toàn và hiệu quả. Bằng cách tuân thủ các nguyên tắc được nêu trong hướng dẫn này chẳng hạn như sử dụng các base image tối thiểu và đã được xác minh, ghim phiên bản gói, chạy container dưới dạng người dùng không phải root, tận dụng multi-stage build và tránh mã hóa cứng các secret bạn có thể giảm đáng kể bề mặt tấn công và nâng cao độ tin cậy của ứng dụng.

Bảo mật không phải là một nhiệm vụ một lần mà là một quá trình liên tục. Thường xuyên cập nhật Dockerfile của bạn để tích hợp các khuyến nghị, công cụ và tính năng bảo mật mới nhất. Sử dụng các công cụ quét tự động để phát hiện các lỗ hổng trong base image và dependency, và luôn kiểm thử Dockerfile của bạn trong các môi trường được kiểm soát trước khi triển khai lên production.

Bằng cách tuân thủ các thực hành này, bạn không chỉ đảm bảo rằng các ứng dụng của mình an toàn mà còn tạo ra một pipeline phát triển mạnh mẽ, thúc đẩy hiệu quả, khả năng mở rộng và độ tin cậy. Trong thế giới container đang phát triển nhanh chóng, việc xây dựng các Docker image an toàn là một kỹ năng quan trọng tạo tiền đề cho việc triển khai ứng dụng thành công và bền vững.