Hướng dẫn Docker Build Secrets: Phát triển ảnh container an toàn

Tôi đã thấy vô số ảnh Docker vô tình bị lộ do nhúng cứng khóa API, mật khẩu cơ sở dữ liệu và token xác thực trong các layer của ảnh. Những sự cố bảo mật này thường xảy ra trong quá trình build khi nhà phát triển cần quyền truy cập tạm thời vào tài nguyên riêng tư nhưng vô tình đóng gói thông tin xác thực vào ảnh cuối cùng.

Thách thức là các cách xử lý thông tin xác thực truyền thống trong lúc build, như biến môi trường hoặc tham số build, không được thiết kế cho mục đích ngắn hạn. Chúng để lại dấu vết vĩnh viễn trong metadata hoặc layer của ảnh, tạo ra lỗ hổng bảo mật tồn tại rất lâu sau khi build hoàn tất. Điều này dẫn đến thế khó: làm sao xác thực với tài nguyên riêng tư trong lúc build mà không đánh đổi bảo mật?

Docker build secrets giải quyết bài toán bảo mật quan trọng này bằng cách cung cấp cơ chế sử dụng dữ liệu nhạy cảm trong quá trình build ảnh mà không để lại dấu vết trong artifact cuối cùng.

Trong hướng dẫn này, tôi sẽ dẫn bạn triển khai build secrets một cách hiệu quả, từ khái niệm cơ bản đến tích hợp CI/CD nâng cao, đảm bảo quy trình build container của bạn luôn an toàn.

Nếu bạn mới làm quen với Docker, tôi khuyến nghị tham gia một trong các khóa học của chúng tôi như Giới thiệu về Docker, Containerization và Virtualization với Docker và Kubernetes, hoặc Docker trình độ trung cấp.

Docker Build Secrets là gì?

Hãy bắt đầu bằng việc hiểu điều khiến build secrets khác với các cách quản lý thông tin xác thực khác. Docker build secrets là những mảnh thông tin nhạy cảm có tính ngắn hạn, được cung cấp trong quá trình build nhưng không bao giờ được lưu trữ trong các layer hay hệ thống tệp của ảnh. Chúng chỉ tồn tại trong bộ nhớ trong các bước build cụ thể và biến mất ngay sau khi bước đó hoàn tất.

Sự cần thiết của build secrets xuất phát từ quy trình phát triển ứng dụng hiện đại.

Bạn thường cần xác thực với kho gói riêng tư, clone repository Git riêng tư, tải phần mềm có bản quyền hoặc truy cập API nội bộ trong lúc build.

Nếu không có build secrets, các nhà phát triển phải dùng các cách lách nguy hiểm như nhúng cứng thông tin xác thực trong Dockerfile, truyền secrets qua tham số build (sẽ tồn tại trong metadata của ảnh), hoặc tạo ảnh nền quá rộng quyền với thông tin xác thực nhúng sẵn.

Rủi ro do xử lý secrets không đúng cách là rất lớn. Thông tin xác thực bị lộ có thể dẫn đến truy cập trái phép vào hệ thống sản xuất, rò rỉ dữ liệu, vi phạm tuân thủ và tổn hại nghiêm trọng đến danh tiếng. Các tình huống rò rỉ thường gặp gồm khóa API cho trình quản lý gói, khóa SSH cho thao tác Git, token xác thực cho dịch vụ nội bộ và thông tin xác thực cơ sở dữ liệu cho các bước migrate lúc build.

Docker BuildKit: Nền tảng cho Build Secrets an toàn

Trước khi đi vào triển khai, bạn cần hiểu về BuildKit, công cụ build hiện đại giúp bảo mật secrets. BuildKit là trình build thế hệ mới của Docker thay thế engine cũ, mang lại cải thiện đáng kể về hiệu năng, bộ nhớ đệm và bảo mật.

BuildKit sử dụng mô hình thực thi dựa trên đồ thị để theo dõi phụ thuộc giữa các bước build. Kiến trúc này cho phép BuildKit mount secrets như hệ thống tệp tạm thời chỉ tồn tại trong các lệnh RUN cụ thể, đảm bảo chúng không bao giờ trở thành một phần của các layer ảnh.

Khác với build Docker cổ điển, nơi mọi thứ trong build context đều thành một phần của cache, BuildKit coi secrets là tài nguyên đặc biệt bỏ qua cache layer hoàn toàn.

Bật BuildKit rất đơn giản. Với Docker 23.0 trở lên, BuildKit là trình build mặc định. Với phiên bản cũ hơn, đặt biến môi trường DOCKER_BUILDKIT=1 trước khi chạy lệnh build:

export DOCKER_BUILDKIT=1
docker build -t myapp .Được hỗ trợ bởi

Ngoài ra, bạn có thể bật vĩnh viễn bằng cách cấu hình Docker daemon hoặc dùng Docker Buildx, vốn luôn sử dụng BuildKit. Khác biệt cốt lõi giữa build cổ điển và build dùng BuildKit là secrets trong build cổ điển có thể tồn tại trong các layer trung gian nếu không được quản lý kỹ, trong khi BuildKit đảm bảo secrets là tạm thời và không bao giờ được ghi xuống đĩa như một phần của ảnh.

Với nền tảng an toàn của BuildKit, hãy khám phá các loại secrets mà nó hỗ trợ và cách triển khai từng loại hiệu quả.

Các loại Docker Build Secrets và cách triển khai

BuildKit hỗ trợ ba cơ chế chính để xử lý secrets trong lúc build, mỗi cơ chế phù hợp cho các tình huống cụ thể. Hiểu khi nào dùng loại nào sẽ giúp tối ưu bảo mật và chức năng.

Secret mount: dữ liệu nhạy cảm đa dụng

Secret mount cung cấp cách linh hoạt nhất để xử lý dữ liệu nhạy cảm trong lúc build. Chúng cho phép bạn mount secrets dưới dạng tệp tại các đường dẫn chỉ định trong lệnh RUN, giúp thông tin xác thực sẵn sàng cho lệnh build mà không bị lưu vào layer.

Quy trình gồm hai bước: truyền secret vào lệnh build và mount nó trong Dockerfile. Trước tiên, tạo một tệp secret cục bộ hoặc dùng biến môi trường. Sau đó tham chiếu nó khi build:

docker build --secret id=api_key,src=./api_key.txt -t myapp .Được hỗ trợ bởi

Trong Dockerfile, mount secret trong lệnh RUN cần dùng nó:

RUN --mount=type=secret,id=api_key \
    API_KEY=$(cat /run/secrets/api_key) && \
    curl -H "Authorization: Bearer $API_KEY" https://api.example.com/package > /app/data.jsonĐược hỗ trợ bởi

Theo mặc định, secrets được mount tại /run/secrets/<id>, nhưng bạn có thể chỉ định đích tùy chỉnh bằng tham số target.

Thực hành tốt gồm chỉ mount secrets trong những lệnh RUN cụ thể cần chúng, không bao giờ sao chép secrets vào hệ thống tệp của ảnh và dùng build nhiều giai đoạn để tách các giai đoạn cần secrets khỏi ảnh cuối cùng.

Nguồn có thể là đường dẫn tệp, hoặc dùng env để truyền secrets từ biến môi trường: --secret id=token,env=API_TOKEN.

Để mount secret như biến môi trường thay vì tệp, dùng tùy chọn env:

RUN --mount=type=secret,id=db_user,env=DB_USER \
    --mount=type=secret,id=db_password,env=DB_PASSWORD \
    ./setup-database.shĐược hỗ trợ bởi

Bạn có thể dùng đồng thời tùy chọn target và env để mount một secret vừa là tệp vừa là biến môi trường.

Thực hành tốt gồm chỉ mount secrets trong các lệnh RUN cụ thể cần chúng, không bao giờ sao chép secrets vào hệ thống tệp của ảnh và dùng build nhiều giai đoạn để tách các giai đoạn cần secrets khỏi ảnh cuối cùng.

SSH mount: truy cập an toàn vào tài nguyên riêng tư

SSH mount xử lý riêng việc xác thực qua SSH, chủ yếu để truy cập repository Git riêng tư trong lúc build. Thay vì sao chép khóa SSH vào ảnh (rất rủi ro), SSH mount cung cấp quyền truy cập tạm thời vào SSH agent của bạn trong thời gian build.

Để dùng SSH mount, đảm bảo SSH agent đang chạy cục bộ với các khóa cần thiết đã nạp. Sau đó tham chiếu SSH mount trong Dockerfile:

RUN --mount=type=ssh \
    git clone [email protected]:myorg/private-repo.git /appĐược hỗ trợ bởi

Build ảnh với SSH forwarding được bật:

docker build --ssh default -t myapp .Được hỗ trợ bởi

Với nhiều host dùng các khóa khác nhau, bạn có thể chỉ định SSH mount có tên:

RUN --mount=type=ssh,id=github \
    git clone [email protected]:myorg/repo.gitĐược hỗ trợ bởi

Sau đó cung cấp khóa cụ thể trong lúc build:

docker build --ssh github=$HOME/.ssh/github_key -t myapp .Được hỗ trợ bởi

Bạn sẽ thấy cách tiếp cận này đảm bảo an toàn bằng việc không bao giờ để lộ khóa riêng trong ảnh nhưng vẫn cho phép truy cập xác thực vào repository riêng tư trong quá trình build.

Xác thực Git cho remote context

Khi Docker build của bạn cần truy cập repository Git riêng tư, hoặc là chính build context hoặc khi tải phụ thuộc trong lúc build, bạn cần một cách xác thực mà không nhúng thông tin xác thực. Điều này đặc biệt phổ biến khi build từ URL repository riêng tư hoặc dùng lệnh ADD để tải mã riêng tư.

BuildKit cung cấp hai secret định nghĩa sẵn cho xác thực Git: GIT_AUTH_TOKEN và GIT_AUTH_HEADER. Đây là các secret "pre-flight" giúp xác thực builder trước khi bất kỳ lệnh Dockerfile nào chạy, bảo vệ việc tải repository ban đầu.

Mẫu thường gặp nhất dùng GIT_AUTH_TOKEN cho xác thực HTTPS dựa trên token:

GIT_AUTH_TOKEN=$(cat ~/.github-token) docker build \
    --secret id=GIT_AUTH_TOKEN \
    https://github.com/myorg/private-repo.gitĐược hỗ trợ bởi

Điều này hoạt động mượt mà với các lệnh ADD tải repository riêng tư:

FROM alpine
ADD https://github.com/myorg/private-configs.git /configsĐược hỗ trợ bởi

Với môi trường CI/CD ngắn hạn, hãy bơm token từ kho secret của nền tảng:

- name: Build from private repo
  env:
    GIT_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: |
    docker build --secret id=GIT_AUTH_TOKEN https://github.com/myorg/app.gitĐược hỗ trợ bởi

Secret GIT_AUTH_HEADER cung cấp lựa chọn thay thế cho các cơ chế xác thực tùy chỉnh khi xác thực bằng token tiêu chuẩn là chưa đủ.

Cách sử dụng Docker Build Secrets

Giờ chúng ta đã đề cập các loại build secrets, hãy xem cách triển khai hiệu quả trong các kịch bản thực tế.

Tạo và tổ chức secrets cho thời điểm build

Chuẩn bị secret đúng cách là tối quan trọng cho bảo mật. Lưu trữ secrets trong các tệp nằm ngoài build context của Docker, đảm bảo chúng được thêm vào .gitignore và .dockerignore, và đặt quyền tệp hạn chế (600 hoặc 400).

Với nhiều secrets, hãy tạo một thư mục riêng cho secrets:

mkdir -p .secrets
echo "my-api-key" > .secrets/api_key
chmod 600 .secrets/*Được hỗ trợ bởi

Sau đó tham chiếu chúng trong lúc build:

docker build \
    --secret id=api_key,src=.secrets/api_key \
    --secret id=db_password,src=.secrets/db_password \
    -t myapp .Được hỗ trợ bởi

Với secrets dựa trên biến môi trường, phổ biến trong CI/CD:

docker build \
    --secret id=api_key,env=API_KEY \
    --secret id=db_pass,env=DB_PASSWORD \
    -t myapp .Được hỗ trợ bởi

Tích hợp với build nhiều giai đoạn

Build nhiều giai đoạn trở nên mạnh mẽ khi kết hợp với build secrets. Dùng secrets ở giai đoạn đầu để lấy phụ thuộc, sau đó chỉ sao chép artifact cần thiết sang giai đoạn cuối:

# Build stage - secrets used here
FROM python:3.11 AS builder
WORKDIR /app
COPY requirements.txt .
RUN --mount=type=secret,id=api_key \
    API_KEY=$(cat /run/secrets/api_key) && \
    curl -H "Authorization: Bearer $API_KEY" https://api.company.com/data.json -o data.json && \
    pip install -r requirements.txt

# Final stage - no secrets present
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages
COPY --from=builder /app/data.json ./data.json
COPY . .
CMD ["python", "app.py"]Được hỗ trợ bởi

Cách này đảm bảo secrets chỉ tồn tại trong giai đoạn builder và không xuất hiện trong ảnh cuối cùng.

Build nhiều giai đoạn xử lý khéo léo các secret đơn lẻ, nhưng ứng dụng thực tế thường phức tạp hơn.

Hãy xem cách quản lý các tình huống liên quan đến nhiều secrets hoặc yêu cầu build phức tạp

Xử lý nhiều secrets và kịch bản phức tạp

Các build phức tạp thường cần nhiều secrets trong cùng một lệnh RUN. BuildKit hỗ trợ mount đồng thời nhiều secrets:

RUN --mount=type=secret,id=api_key \
    --mount=type=secret,id=db_password \
    API_KEY=$(cat /run/secrets/api_key) && \
    DB_PASS=$(cat /run/secrets/db_password) && \
    ./configure.shĐược hỗ trợ bởi

Với các tình huống cần secrets ở nhiều lệnh, hãy kết hợp các lệnh trong một RUN duy nhất để giảm số lần mount secret đồng thời vẫn duy trì ranh giới bảo mật.

Thực hành tốt về bảo mật Docker Build Secrets

Triển khai build secrets đúng cách đòi hỏi tuân thủ các thực hành bảo mật đã được kiểm chứng. Tôi sẽ chia sẻ các mẫu mà tôi thấy hiệu quả nhất để duy trì bảo mật xuyên suốt quá trình build.

Ngăn ngừa lộ lọt và rò rỉ secrets

Sau khi build ảnh, hãy xác minh secrets không bị rò rỉ bằng cách kiểm tra các layer của ảnh:

docker history myapp:latest
docker save myapp:latest | tar -xĐược hỗ trợ bởi

Kiểm tra các layer đã giải nén để tìm dữ liệu nhạy cảm. Ngoài ra, phân biệt giữa secrets lúc build (tạm thời, dùng khi build) và secrets lúc chạy (cần khi container chạy). Không bao giờ dùng build secrets cho thông tin xác thực lúc chạy. Thay vào đó dùng Docker secrets, Kubernetes secrets, hoặc biến môi trường được bơm vào lúc chạy.

Luôn thêm tệp secret vào .gitignore:

# .gitignore
.secrets/
*.keyĐược hỗ trợ bởi

Và vào .dockerignore để ngăn vô tình đưa vào build context:

# .dockerignore
.secrets/
*.key
.envĐược hỗ trợ bởi

Quản lý secrets trong môi trường CI/CD

Các nền tảng CI/CD cung cấp quản lý secrets gốc tích hợp liền mạch với Docker build secrets. Trong GitHub Actions:

- name: Build Docker image
  env:
    API_KEY: ${{ secrets.API_KEY }}
  run: |
    docker build \
      --secret id=api_key,env=API_KEY \
      -t myapp .Được hỗ trợ bởi

Nguyên tắc then chốt là tận dụng kho secrets do nền tảng cung cấp thay vì lưu secrets trong repository. Secrets của CI/CD được bơm vào dưới dạng biến môi trường, BuildKit có thể sử dụng trực tiếp thông qua kiểu nguồn env.

Quyền và kiểm soát truy cập đối với secrets

Khi build dưới quyền người dùng không phải root, đảm bảo tệp secret có quyền đọc phù hợp. Nếu Dockerfile của bạn dùng USER để chuyển sang người dùng không phải root, hãy mount secrets tại vị trí người dùng đó có thể truy cập:

FROM python:3.11-slim
RUN useradd -m appuser
USER appuser

RUN --mount=type=secret,id=token,uid=1000 \
    cat /run/secrets/token > /dev/nullĐược hỗ trợ bởi

Để tăng cường tuân thủ bảo mật, hãy triển khai chiến lược xoay vòng secrets. Dùng token có thời hạn ngắn khi có thể, tự động xoay vòng trong pipeline CI/CD và duy trì nhật ký kiểm toán việc sử dụng secrets.

Cân nhắc các secrets có ngày hết hạn và quy trình gia hạn tự động để giảm thiểu cửa sổ phơi lộ.

Đến đây, chúng ta tập trung vào build đơn lẻ, nhưng ứng dụng hiện đại thường gồm nhiều dịch vụ. Hãy xem Docker Compose mở rộng khả năng build secrets cho kiến trúc đa dịch vụ như thế nào.

Tích hợp Build Secrets với Docker Compose

Docker Compose đơn giản hóa việc quản lý build secrets trên các ứng dụng đa dịch vụ. Trong docker-compose.yml, định nghĩa secrets ở cấp cao nhất và tham chiếu chúng trong cấu hình build của dịch vụ:

services:
  app:
    build:
      context: .
      secrets:
        - api_key
        - db_password
  
secrets:
  api_key:
    file: ./.secrets/api_key
  db_password:
    environment: DB_PASSWORDĐược hỗ trợ bởi

Sau đó trong Dockerfile, mount secrets như thường lệ:

RUN --mount=type=secret,id=api_key \
    --mount=type=secret,id=db_password \
    ./setup.shĐược hỗ trợ bởi

Build với Compose:

docker-compose buildĐược hỗ trợ bởi

Mẫu này mở rộng tốt cho ứng dụng có nhiều dịch vụ cần các secrets khác nhau, duy trì quản lý secrets tập trung đồng thời bảo toàn ranh giới bảo mật giữa các dịch vụ.

Khi bạn triển khai build secrets trên các dự án, bạn sẽ khó tránh khỏi sự cố. Hãy giải quyết các thách thức phổ biến và cách khắc phục để hỗ trợ bạn xử lý sự cố hiệu quả.

Thách thức thường gặp và cách khắc phục

Ngay cả khi triển khai đúng, bạn vẫn có thể gặp khó khăn. Dưới đây là những vấn đề thường gặp và giải pháp.

Lỗi cú pháp và vấn đề khai báo mount

Cú pháp --mount rất chặt chẽ. Lỗi thường gặp gồm thiếu dấu phẩy giữa các tham số, tên tham số sai và sai loại mount. Cú pháp đúng là:

RUN --mount=type=secret,id=secret_name,target=/path \
    commandĐược hỗ trợ bởi

Nếu build thất bại với lỗi "secret not found", hãy xác minh BuildKit đã bật và ID trong Dockerfile khớp với --secret id trong lệnh build của bạn.

Secrets không khả dụng hoặc không tìm thấy

Khi không truy cập được secrets, hãy kiểm tra tệp nguồn tồn tại và có thể đọc:

cat .secrets/api_key
docker build --secret id=api_key,src=.secrets/api_key .Được hỗ trợ bởi

Với biến môi trường, xác nhận chúng đã được đặt:

echo $API_KEY
docker build --secret id=api_key,env=API_KEY .Được hỗ trợ bởi

Nhầm lẫn giữa biến môi trường và tệp

Với build secrets, theo mặc định secrets luôn được mount như tệp tại /run/secrets/<id>. Để dùng như biến môi trường, hãy đọc nội dung tệp:

RUN --mount=type=secret,id=token \
    export TOKEN=$(cat /run/secrets/token) && \
    curl -H "Authorization: Bearer $TOKEN" https://api.example.comĐược hỗ trợ bởi

Không bao giờ dùng tham số build (ARG) cho secrets, vì chúng tồn tại trong metadata của ảnh.

Vấn đề về tính bền và cache layer

Secrets theo thiết kế không tồn tại giữa các lệnh RUN. Nếu nhiều lệnh RUN cần cùng một secret, hãy gộp chúng hoặc mount lại secret:

RUN --mount=type=secret,id=token \
    command1

RUN --mount=type=secret,id=token \
    command2Được hỗ trợ bởi

BuildKit đảm bảo secrets không bao giờ đi vào cache layer.

Khi bạn đã nắm vững cơ bản và cách khắc phục thường gặp, có thể bạn sẽ gặp các tình huống cần cách tiếp cận tinh vi hơn. Hãy khám phá các trường hợp nâng cao và cạnh biên vượt ra ngoài triển khai tiêu chuẩn.

Các cách dùng nâng cao của Docker Build Secrets

Với các kịch bản triển khai phức tạp, bạn sẽ cần xử lý các cân nhắc bổ sung vượt ngoài triển khai cơ bản.

Secrets trong pipeline CI/CD phức tạp

Các pipeline CI/CD nhiều giai đoạn thường cần secrets ở các giai đoạn khác nhau. Hãy triển khai secrets theo từng giai đoạn thay vì chia sẻ thông tin xác thực. Dùng tính năng phân phạm vi secret của nền tảng CI/CD để giới hạn giai đoạn nào được truy cập secret nào. Tự động dọn dẹp secrets sau build để giảm thiểu thời gian phơi lộ.

Secrets với các trình build không phải Docker

Các trình build thay thế như Buildah và Kaniko có mức hỗ trợ khác nhau cho cú pháp secret của BuildKit. Buildah hỗ trợ mount secret tương tự thông qua --secret flags. Kaniko, được thiết kế cho môi trường Kubernetes, dùng cơ chế khác, thường là Kubernetes secrets được mount dưới dạng volume. Khi dùng trình build không phải Docker, hãy tham khảo tài liệu riêng, vì cách triển khai khác biệt đáng kể.

Secrets và tuân thủ bảo mật

Build secrets phù hợp với các khung tuân thủ bảo mật bằng cách cung cấp quyền truy cập thông tin xác thực có thể kiểm toán và mang tính tạm thời.

Với GDPR, đảm bảo secrets không làm rò rỉ thông tin nhận dạng cá nhân vào các layer. SOC2 hưởng lợi từ việc xây dựng dấu vết kiểm toán secrets — ghi lại khi nào secrets được dùng và bởi ai. Duy trì hồ sơ truy cập secrets để phục vụ kiểm toán tuân thủ.

Xoay vòng và cập nhật secrets

Thiết lập quy trình xoay vòng secrets mà không làm gián đoạn build. Dùng tệp secret có phiên bản hoặc quy ước đặt tên biến môi trường cho phép chuyển đổi giữa các phiên bản.

Tự động xoay vòng trong pipeline CI/CD, nơi secrets được làm mới từ kho trung tâm. Với token có ngày hết hạn, theo dõi thời điểm hết hạn và tự động hóa quy trình gia hạn.

Kết luận: Thực hành tốt và khuyến nghị

Docker build secrets đại diện cho bước tiến quan trọng về bảo mật trong phát triển ứng dụng container hóa. Xuyên suốt hướng dẫn này, chúng ta đã tìm hiểu cách triển khai secrets an toàn, từ secret mount cơ bản đến tích hợp CI/CD phức tạp.

Những điểm mấu chốt rất rõ ràng: luôn dùng cơ chế mount secret của BuildKit thay vì tham số build hoặc nhúng cứng thông tin xác thực, triển khai build nhiều giai đoạn để cô lập các giai đoạn dùng secrets khỏi ảnh cuối, tận dụng quản lý secrets của nền tảng CI/CD cho quy trình tự động, và thường xuyên kiểm toán ảnh để xác minh secrets không rò rỉ vào các layer.

Với các tổ chức áp dụng những thực hành này, hãy bắt đầu bằng chính sách quản lý secrets xác định secrets nào cần truy cập trong lúc build, thiết lập lịch xoay vòng tự động, triển khai kiểm thử toàn diện để xác minh secrets không tồn tại trong ảnh, và đào tạo đội ngũ phát triển về mẫu xử lý secrets đúng đắn. Bằng cách coi build secrets là thành phần bảo mật quan trọng, bạn sẽ giảm đáng kể bề mặt tấn công và xây dựng ứng dụng container hóa an toàn hơn.

Để tiếp tục học, tôi khuyến nghị xem các tài nguyên sau:

Docker Build Secrets FAQs

Docker build secrets là gì?

Docker build secrets là các mẩu thông tin nhạy cảm có tính tạm thời, được cung cấp trong quá trình build nhưng không được lưu trữ trong các layer của ảnh, chỉ tồn tại trong bộ nhớ ở những bước build cụ thể.

Docker hỗ trợ những loại build secrets nào?

Docker hỗ trợ ba loại: secret mount cho dữ liệu nhạy cảm đa dụng, SSH mount cho truy cập an toàn vào repository Git, và secrets xác thực Git (GIT_AUTH_TOKEN và GIT_AUTH_HEADER) cho remote context riêng tư.

Làm sao để ngăn secrets xuất hiện trong ảnh Docker?

Hãy dùng cú pháp --mount=type=secret của BuildKit trong các lệnh RUN kết hợp với build nhiều giai đoạn, không bao giờ dùng tham số build hoặc biến môi trường cho secrets, và thường xuyên kiểm tra ảnh bằng docker history để xác minh không có rò rỉ.

Tôi có thể dùng Docker build secrets với Docker Compose không?

Có. Docker Compose hỗ trợ build secrets thông qua phần secrets trong tệp compose, cho phép bạn định nghĩa secrets ở cấp cao nhất và tham chiếu chúng trong cấu hình build của dịch vụ.

Build secrets hoạt động thế nào trong pipeline CI/CD?

Các nền tảng CI/CD bơm secrets dưới dạng biến môi trường có thể được truyền vào Docker build bằng --secret id=name,env=VARIABLE_NAME, cho phép tự động hóa quy trình mà không lưu thông tin xác thực trong repository.

Tác giả

Benito Martin

Với vai trò Nhà sáng lập Martin Data Solutions và Nhà khoa học dữ liệu/ Kỹ sư ML & AI tự do, tôi sở hữu danh mục năng lực đa dạng về Hồi quy, Phân loại, Xử lý ngôn ngữ tự nhiên (NLP), LLM, RAG, Mạng nơ-ron, Phương pháp tổ hợp (Ensemble) và Thị giác máy tính.

Phát triển thành công nhiều dự án ML end-to-end, bao gồm làm sạch dữ liệu, phân tích, xây dựng mô hình và triển khai trên AWS và GCP, mang lại các giải pháp có tác động và khả năng mở rộng.
Xây dựng các ứng dụng web tương tác, có khả năng mở rộng bằng Streamlit và Gradio cho nhiều bài toán trong các ngành khác nhau.
Giảng dạy và cố vấn cho học viên về khoa học dữ liệu và phân tích, thúc đẩy sự phát triển nghề nghiệp của họ thông qua phương pháp học tập cá nhân hóa.
Thiết kế nội dung khóa học cho các ứng dụng retrieval-augmented generation (RAG) được điều chỉnh theo yêu cầu doanh nghiệp.
Viết các blog kỹ thuật AI & ML có sức ảnh hưởng, bao gồm các chủ đề như MLOps, cơ sở dữ liệu vector và LLM, đạt được mức độ tương tác đáng kể.

Trong mỗi dự án tôi đảm nhận, tôi luôn áp dụng các thực hành cập nhật trong kỹ thuật phần mềm và DevOps như CI/CD, linting mã, định dạng, giám sát mô hình, theo dõi thí nghiệm và xử lý lỗi mạnh mẽ. Tôi cam kết cung cấp các giải pháp hoàn chỉnh, chuyển hóa những hiểu biết từ dữ liệu thành chiến lược thực tiễn giúp doanh nghiệp phát triển và khai thác tối đa giá trị của khoa học dữ liệu, học máy và AI.

Chủ đề

Docker