My Awesome Project

Appearance

Binary Authorization — Chỉ Deploy Image Đáng Tin ​

Vì sao kiểm soát "image nào được chạy" là một lớp phòng thủ riêng ​

Mọi lớp phòng thủ trước giả định kẻ tấn công tấn công từ bên ngoài vào workload của bạn. Nhưng có một vector hoàn toàn khác: kẻ tấn công không cần phá cluster — họ chỉ cần bạn deploy image của họ. Một dependency bị nhiễm, một base image độc hại, một build pipeline bị chiếm, hoặc đơn giản một developer pull nginx:latest từ một registry giả mạo. Đây là supply chain attack, và không securityContext hay Network Policy nào ngăn được nó — vì image độc hại chạy như một workload hợp lệ.

Câu hỏi cốt lõi mà Binary Authorization trả lời là: "Image này có được phép chạy trong cluster của tôi không, và dựa trên bằng chứng gì?" Thay vì tin tưởng mọi image pull được, Binary Authorization yêu cầu bằng chứng mật mã (attestation) rằng image đã đi qua đúng các bước kiểm soát — được build từ source tin cậy, đã scan vulnerability, đã qua review — trước khi cho phép deploy. Đây là cơ chế deploy-time enforcement cho chuỗi cung ứng: chỉ image có "giấy thông hành" hợp lệ mới qua cổng.

Internal model: mô hình attestation ​

Binary Authorization xây trên bốn khái niệm liên kết. Hiểu chúng là hiểu toàn bộ hệ thống.

Image digest — danh tính bất biến ​

Mọi attestation gắn với image digest (sha256:...), không phải tag. Lý do bảo mật then chốt: tag có thể thay đổi (latest hôm nay khác latest ngày mai; một tag có thể bị đẩy đè), nhưng digest là hash bất biến của nội dung image. Attestation cho một digest đảm bảo chính xác bytes đó đã được verify — không có chuyện "verify image A rồi swap sang image B cùng tag". Đây là lý do Binary Authorization (và admission policy ở file 08) luôn làm việc với digest.

Attestation — chứng nhận ký số ​

Một attestation là một tuyên bố ký số rằng một image (theo digest) đã hoàn thành một bước nào đó trong quy trình. Theo tài liệu Binary Authorization, attestation chứa "the registry path and digest of the image, and that has been digitally signed using the signer's private cryptographic key" — đường dẫn registry, digest, và được ký bằng private key của signer. Chữ ký mật mã đảm bảo attestation không thể giả mạo: chỉ ai giữ private key tương ứng mới tạo được attestation hợp lệ.

Attestor — authority verify ​

Một attestor là một thực thể được cấu hình để verify attestation tại thời điểm deploy. Attestor giữ public key tương ứng với private key của signer; khi một image cần được duyệt, attestor dùng public key để kiểm tra chữ ký của attestation. Một policy có thể yêu cầu attestation từ nhiều attestor khác nhau (ví dụ: một attestor cho "đã build bởi CI tin cậy", một cho "đã qua security scan", một cho "đã được QA duyệt") — mô hình hóa một quy trình phê duyệt nhiều bước.

Note (Artifact Analysis) — nơi lưu metadata tin cậy ​

Binary Authorization dùng Artifact Analysis (trước đây gọi Container Analysis) để lưu metadata tin cậy. Một note đại diện cho loại attestation; mỗi attestation là một occurrence gắn với note đó và với một image cụ thể. Theo tài liệu, Artifact Analysis "store trusted metadata used in authorization decisions" — lưu metadata tin cậy dùng cho quyết định authorize, cùng với thông tin vulnerability. Đây là kho lưu trữ chung kết nối Binary Authorization với hệ thống scan và metadata của GCP.

Tóm tắt luồng khái niệm: CI build image → tạo digest → signer ký một attestation cho digest đó (lưu vào Artifact Analysis như occurrence của một note) → khi deploy, attestor verify chữ ký bằng public key → policy quyết định allow/deny.

Execution path: điều gì xảy ra khi deploy ​

Khi một Pod được tạo (hoặc image được pull để chạy), chuỗi enforcement sau diễn ra:

1. kubectl/controller tạo Pod tham chiếu image (resolve về digest)
2. GKE admission controller (Binary Authorization) chặn request tạo Pod
3. Admission controller gọi Binary Authorization API với image digest
4. Binary Authorization đánh giá policy:
     - Image có khớp allowlist registry không? → nếu có, allow
     - Policy có yêu cầu attestation không? → kiểm tra attestor verify
       được attestation cho digest này không
5. Kết quả:
     - PASS  → Pod được phép tạo
     - FAIL  → Pod bị từ chối; ghi message vào Cloud Audit Logs
       mô tả vì sao image không tuân thủ

Điểm then chốt: Binary Authorization là một admission controller (đối chiếu file 08 và Chương 10) — nó nằm trên đường tạo Pod và là cổng deploy-time. Theo tài liệu, khi image không tuân thủ, hệ thống "blocks deployment and writes a message to Cloud Audit Logs that describes why the image is out of compliance" — chặn deploy và ghi log giải thích lý do. Mọi quyết định, allow hay deny, đều để lại dấu vết audit (kết nối file 10).

Policy modes: từ allowlist tới require-attestation ​

Binary Authorization policy hỗ trợ nhiều cấp độ enforcement, có thể kết hợp:

  • Allowlist (allowed images): cho phép image khớp các pattern registry/path cụ thể mà không cần attestation. Dùng cho image hệ thống tin cậy (ví dụ image của Google, registry nội bộ đã được kiểm soát chặt ở tầng khác). Đây là cơ chế "danh sách trắng" đơn giản nhất.

  • Require attestation: image phải có attestation hợp lệ verify được bởi (các) attestor yêu cầu. Đây là mức enforcement thực sự cho supply chain — image phải mang bằng chứng đã qua các bước kiểm soát.

  • dryRun mode: policy được đánh giá và ghi log vi phạm nhưng KHÔNG chặn deploy. Đây là công cụ rollout an toàn cốt lõi: bật policy ở dryRun trước, quan sát image nào sẽ bị chặn (qua audit log), sửa pipeline để sinh attestation cho chúng, rồi mới chuyển sang enforce thực sự. Bật require-attestation mà không qua dryRun gần như chắc chắn làm vỡ deploy của những image chưa có attestation.

Policy có thể đặt rule mặc định cho cả cluster và rule riêng theo từng cluster (specific cluster rule), cho phép môi trường khác nhau có mức enforcement khác nhau (ví dụ: production require-attestation chặt, dev chỉ allowlist).

Break-glass: lối thoát khẩn cấp được audit ​

Enforcement chặt tạo ra một rủi ro vận hành: nếu trong một sự cố khẩn cấp bạn phải deploy một image chưa có attestation (hotfix lúc 3 giờ sáng, attestation service đang down), policy sẽ chặn bạn — đúng lúc bạn cần deploy nhất. Break-glass là cơ chế giải quyết tình huống này.

Break-glass cho phép bypass Binary Authorization policy bằng cách thêm một annotation đặc biệt vào Pod:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: emergency-hotfix
  annotations:
    alpha.image-policy.k8s.io/break-glass: "true"   # bypass policy
spec:
  containers:
    - name: app
      image: REGION-docker.pkg.dev/PROJECT/repo/app@sha256:...

Nguyên tắc thiết kế quan trọng: mọi lần break-glass đều được ghi vào Cloud Audit Logs. Break-glass không phải là "tắt bảo mật" — nó là "vượt rào có ghi nhận". Triết lý: cho phép linh hoạt khẩn cấp, nhưng đảm bảo mọi lần dùng đều để lại dấu vết để review sau. Một spike break-glass annotation là tín hiệu cần điều tra. Quyền thêm annotation này (qua RBAC) nên được hạn chế, và việc dùng nó nên kích hoạt alert.

Continuous Validation: bảo mật không dừng ở deploy time ​

Admission control chỉ kiểm tra tại thời điểm deploy. Nhưng một image hợp lệ hôm nay có thể trở thành vấn đề ngày mai: một CVE mới được công bố, một attestation bị thu hồi, một policy thay đổi. Một Pod đã chạy từ tuần trước không đi qua admission lại. Continuous Validation (CV) lấp khoảng trống này.

CV định kỳ quét các Pod đang chạy và kiểm tra image của chúng so với policy hiện hành. Theo tài liệu, CV "periodically monitors running Pods to ensure images maintain policy conformance, generating Cloud Logging entries for violations" — giám sát định kỳ Pod đang chạy, đảm bảo image vẫn tuân thủ policy, và sinh log khi vi phạm.

Điểm tinh tế quan trọng: CV không tự động kill Pod vi phạm — nó ghi log vi phạm vào Cloud Logging. Đây là một lựa chọn thiết kế thận trọng: tự động giết workload production khi một CVE mới xuất hiện có thể gây outage tệ hơn rủi ro. Thay vào đó, CV cung cấp khả năng quan sát để đội ngũ phản ứng (vá, redeploy, hoặc quyết định gỡ) một cách có kiểm soát. CV biến Binary Authorization từ một cổng one-shot thành một cơ chế giám sát liên tục — kết nối trực tiếp với góc detection ở file 10.

Cloud Build integration: attestation tự động trong CI/CD ​

Sức mạnh thực của Binary Authorization chỉ phát huy khi attestation được sinh tự động trong pipeline — yêu cầu con người ký thủ công mỗi image là không khả thi. Cloud Build tích hợp native: theo tài liệu, nó "producing attestations and provenance that Binary Authorization can use for enforcement and monitoring" — tự động sinh attestation và provenance mà Binary Authorization dùng để enforce.

Mô hình điển hình:

Cloud Build pipeline:
  1. Build image từ source (gắn với commit/source tin cậy)
  2. Push image → registry, lấy digest
  3. (tùy chọn) Scan vulnerability qua Artifact Analysis
  4. Nếu đạt tiêu chí → tự động tạo attestation cho digest
     (ký bằng key do Cloud Build/KMS quản lý)
  5. Image giờ có "giấy thông hành" → deploy được qua Binary Authorization

Khái niệm provenance (nguồn gốc) đáng chú ý: Cloud Build có thể sinh build provenance ghi lại image này được build từ source nào, bằng pipeline nào, lúc nào — một phần của khung SLSA (Supply-chain Levels for Software Artifacts). Provenance + attestation cùng nhau tạo một chuỗi tin cậy có thể verify từ source code tới image đang chạy: bạn không chỉ biết image "đã được duyệt" mà còn biết chính xác nó đến từ đâu. Đây là trạng thái cuối của supply chain security — chuỗi cung ứng có thể kiểm chứng end-to-end.

Production architecture patterns ​

Pattern: enforce production, dryRun dev, attestation tự động qua CI ​

Mô hình chuẩn: cluster production đặt require-attestation (chỉ image có attestation từ CI tin cậy mới chạy); cluster dev/staging đặt dryRun hoặc allowlist lỏng hơn (cho phép thử nghiệm nhanh nhưng vẫn quan sát). Attestation được sinh hoàn toàn tự động bởi Cloud Build sau khi image qua build + scan — developer không bao giờ ký thủ công. Kết quả: con đường bình thường (commit → CI build → attest → deploy production) hoàn toàn tự động và an toàn; con đường bất thường (image lạ) bị chặn ở production.

Pattern: nhiều attestor cho quy trình phê duyệt nhiều bước ​

Mô hình hóa một quy trình release thành nhiều attestor: built-by-ci (Cloud Build ký sau khi build), vuln-scan-passed (ký sau khi Artifact Analysis xác nhận không có CVE nghiêm trọng), qa-approved (ký sau khi QA duyệt). Production policy yêu cầu cả ba attestation. Mỗi attestor là một cổng độc lập; image phải qua mọi cổng. Điều này biến policy deploy thành hiện thân mật mã của quy trình release — không thể bỏ qua bước nào vì thiếu attestation tương ứng sẽ chặn deploy.

Common mistakes / anti-patterns ​

1. Bật require-attestation mà không qua dryRun. Vì sao xảy ra: nóng vội enforce. Hệ quả: mọi image chưa có attestation (gần như tất cả lúc đầu) bị chặn → không deploy được gì → phải vội tắt policy. Phòng tránh: luôn dryRun trước, quan sát audit log, sửa pipeline sinh attestation, rồi mới enforce.

2. Quản lý private key của signer cẩu thả. Vì sao xảy ra: coi nhẹ key ký attestation. Hệ quả: ai lấy được key có thể tạo attestation giả cho image độc hại → bypass toàn bộ Binary Authorization. Phòng tránh: lưu key trong Cloud KMS, hạn chế quyền dùng key, ký qua dịch vụ (Cloud Build) thay vì key trên máy người.

3. Break-glass không giám sát. Vì sao xảy ra: bật break-glass cho tiện rồi quên. Hệ quả: developer dùng break-glass thường xuyên để né policy → Binary Authorization trở thành hình thức. Phòng tránh: hạn chế RBAC quyền thêm annotation, alert mỗi lần break-glass, review định kỳ audit log break-glass.

4. Bỏ qua Continuous Validation. Vì sao xảy ra: nghĩ admission-time là đủ. Hệ quả: image trở nên vulnerable sau deploy (CVE mới) mà không ai biết. Phòng tránh: bật CV, đưa log vi phạm CV vào quy trình alert/response.

5. Allowlist quá rộng làm rỗng nghĩa enforcement. Vì sao xảy ra: allowlist cả docker.io/* cho tiện. Hệ quả: gần như mọi image qua được → Binary Authorization không bảo vệ gì. Phòng tránh: allowlist hẹp (chỉ registry nội bộ + image hệ thống cần thiết), buộc phần còn lại qua require-attestation.

GCP-native implementation guidance ​

bash
# Bật Binary Authorization trên cluster
gcloud container clusters update CLUSTER --region REGION \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

# Xem policy hiện hành
gcloud container binauthz policy export

# Tạo attestor (giữ public key verify)
gcloud container binauthz attestors create build-attestor \
  --attestation-authority-note=NOTE_ID \
  --attestation-authority-note-project=PROJECT_ID

# Kiểm tra audit log các quyết định Binary Authorization (allow/deny)
gcloud logging read \
  'resource.type="k8s_cluster" AND
   protoPayload.serviceName="binaryauthorization.googleapis.com"' \
  --limit=20 --format=json

Một policy YAML điển hình yêu cầu attestation cho production và dryRun cho phần còn lại:

yaml
defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
    - projects/PROJECT_ID/attestors/build-attestor
admissionWhitelistPatterns:
  - namePattern: "gke.gcr.io/*"          # image hệ thống GKE
  - namePattern: "REGION-docker.pkg.dev/PROJECT_ID/system/*"
clusterAdmissionRules:
  "REGION.dev-cluster":                  # dev cluster chỉ dryRun
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: DRYRUN_AUDIT_LOG_ONLY
    requireAttestationsBy:
      - projects/PROJECT_ID/attestors/build-attestor

Operational implications ​

Binary Authorization thay đổi mô hình tin cậy của cluster từ "tin mọi image pull được" sang "chỉ tin image có bằng chứng" — và hệ quả vận hành lớn nhất là nó buộc bạn phải có một CI/CD pipeline trưởng thành. Không thể enforce require-attestation nếu không có pipeline tự động sinh attestation; không thể quản lý attestor nếu không có quy trình ký key kỷ luật. Theo nghĩa này, Binary Authorization không chỉ là một tính năng bảo mật mà là một động lực đẩy tổ chức tới supply chain trưởng thành — nó chỉ hoạt động tốt khi quy trình build/release đã được tự động hóa và kiểm soát.

Hệ quả thứ hai liên quan tới cân bằng security/reliability (chủ đề xuyên suốt chương): các lựa chọn thiết kế của Binary Authorization — break-glass có audit thay vì khóa cứng, CV ghi log thay vì kill Pod, dryRun trước enforce — đều phản ánh một triết lý thận trọng: bảo mật không được phép tự nó gây ra outage tệ hơn mối đe dọa nó ngăn. Đây là bài học vận hành cốt lõi: enforcement chặt phải luôn đi kèm lối thoát có kiểm soát và khả năng quan sát, nếu không nó sẽ bị vô hiệu hóa trong sự cố đầu tiên. Kết hợp với admission policy (file 08) cho cấu hình và audit/posture (file 10) cho phát hiện, Binary Authorization hoàn thiện lớp supply chain của defense-in-depth: chỉ image đúng nguồn gốc, đã verify, với cấu hình đúng chuẩn mới chạy được — và mọi ngoại lệ đều tường minh và để lại dấu vết.

References ​