Ký container image với Sigstore Cosign: Từ CI đến admission policy

Ký container image bằng Cosign giúp trả lời “artifact digest này được identity nào xác nhận?”, không trả lời “artifact này không có lỗ hổng”. Một thiết kế production phải khóa image theo digest, xác minh đúng certificate identity và OIDC issuer, kiểm tra bằng chứng transparency/timestamp, rồi thực thi policy tại đường deploy—không chỉ chạy một lệnh ký trong CI để có dấu tích.

Bài viết dựa trên tài liệu chính thức của Sigstore Cosign signing và signature verification. Cú pháp và định dạng bundle có thể thay đổi giữa major Cosign; pin phiên bản, đọc tài liệu tương ứng và kiểm thử chính sách trước khi rollout.

1. Chữ ký image bảo đảm điều gì?

Chữ ký mật mã ràng buộc một digest với signer theo trust policy của verifier. Nếu image thay một byte, digest đổi và chữ ký cũ không còn áp dụng. Verification tốt chứng minh artifact nhận được đúng artifact đã được một identity được phép ký.

Nó không tự chứng minh:

• source code an toàn hoặc không có dependency dễ tổn thương;
• CI không bị chiếm quyền tại thời điểm ký;
• test đã chạy hoặc provenance/SBOM là đúng;
• runtime configuration và secret an toàn;
• signer đáng tin cho mọi repository/environment.

Vì vậy chữ ký là một lớp trong software supply chain: build isolation, review, scanner, provenance, admission và runtime controls vẫn cần độc lập.

2. Tag thay đổi; digest là identity bất biến

registry.example.com/payments/api:2026-10-16
registry.example.com/payments/api@sha256:<digest>

Tag là con trỏ có thể được gán lại. Digest xác định manifest/content cụ thể. Pipeline nên build/push một lần, lấy digest từ registry hoặc output đáng tin của builder, ký digest đó và promote cùng digest qua các môi trường.

Nếu admission xác minh tag rồi runtime resolve tag ở thời điểm khác, tag có thể đổi giữa hai bước. Policy controller cần resolve/pin digest theo cách ngăn time-of-check/time-of-use; manifest deploy cuối cùng nên ghi digest.

3. Keyless signing hoạt động như thế nào?

1. CI workload nhận OIDC token ngắn hạn từ identity provider.
2. Cosign tạo ephemeral key pair.
3. Fulcio cấp certificate ngắn hạn ràng buộc public key với OIDC identity.
4. Cosign ký image digest.
5. Bằng chứng được gắn với artifact/bundle và có thể được ghi vào transparency log.
6. Verifier kiểm tra digest, signature, certificate chain, identity, issuer và bằng chứng thời gian/log theo policy.

“Keyless” không nghĩa không có key; private key tồn tại ngắn hạn và không cần lưu dài hạn. Trust chuyển sang OIDC identity, CA/trusted root, transparency/timestamp và policy xác minh.

4. Bootstrap Cosign cũng phải có trust

Không nên tải binary “latest” rồi dùng chính binary chưa xác minh để bảo vệ chuỗi cung ứng. Pin version và checksum/signature trong toolchain bootstrap. Sigstore cung cấp hướng dẫn xác minh release Cosign; CI image/action cũng nên pin bằng digest hoặc commit bất biến.

• Lưu version Cosign trong build manifest/tool lock.
• Xác minh binary/container từ nguồn chính thức.
• Theo dõi security advisory của Cosign và dependency.
• Rollout nâng major qua staging vì bundle/default có thể đổi.

5. Pipeline đúng thứ tự: build → push → resolve digest → sign

# IMAGE_DIGEST phải đến từ output build/push đã kiểm chứng
IMAGE="registry.example.com/payments/api@sha256:${IMAGE_DIGEST}"

cosign sign --yes "$IMAGE"

cosign verify "$IMAGE" \
  --certificate-identity "https://github.com/ORG/REPO/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

Identity minh họa phải được thay bằng subject thực tế xuất hiện trong certificate/bundle của workflow. Xác nhận output verification trong staging, rồi hardcode policy chính xác. Không dùng pattern rộng như “mọi workflow trong tổ chức” nếu chỉ release workflow được quyền ký production.

Trong GitHub Actions, chỉ job ký cần id-token: write; giảm các quyền khác và không cấp OIDC cho pull request không tin cậy. Với provider khác, pin issuer/subject đúng claim contract của provider đó.

6. Xác minh identity và issuer, không chỉ xác minh chữ ký hợp lệ

Một chữ ký hợp lệ từ identity không mong muốn vẫn không được phép deploy. Verification keyless cần ít nhất:

Tránh flag “insecure ignore” trên đường production chỉ để pipeline xanh. Nếu môi trường air-gapped, thiết kế trusted root và bundle/timestamp offline có chủ đích thay vì bỏ kiểm tra.

7. Transparency log tăng khả năng kiểm toán, không giữ bí mật

Transparency log cung cấp bằng chứng append-only có thể kiểm toán về signing event. Nó giúp phát hiện ký trái phép hoặc điều tra thời điểm/identity, nhưng dữ liệu đưa vào log công khai cần được xem là có thể quan sát.

Không đặt secret, token, path nội bộ nhạy cảm hoặc dữ liệu cá nhân vào annotation/attestation công khai. Xác định retention, privacy và availability requirements. Log evidence không thay authorization: một entry có thật vẫn có thể đến từ identity không được policy cho phép.

8. Chữ ký, SBOM và provenance là ba contract khác nhau

Attestation là statement được ký. Verification phải kiểm tra signer, predicate type và nội dung policy; việc tồn tại một attestation không làm claim tự động đúng.

9. Ký bằng key/KMS khi keyless không phù hợp

Môi trường offline, PKI nội bộ hoặc compliance có thể yêu cầu key pair/KMS/HSM. Khi đó:

• private key không nằm trong repository hoặc CI variable dạng plaintext;
• KMS policy chỉ cho release identity ký đúng scope;
• public key/trusted root phân phối qua kênh có version và audit;
• rotation hỗ trợ giai đoạn hai key cùng hợp lệ;
• revocation/incident response nêu rõ artifact nào phải chặn hoặc ký lại.

Key dài hạn làm đơn giản một số verification nhưng tăng gánh nặng custody và rotation. Chọn theo threat model, không theo demo ngắn nhất.

10. Registry là một phần của compatibility matrix

Signature/attestation thường được lưu cùng hệ sinh thái OCI artifact. Registry, proxy, replication và garbage collection phải giữ chúng theo cách Cosign/policy controller tìm được. Test:

• push/sign/verify trong registry đích;
• copy/promote image giữa registry có mang theo referrer/signature;
• garbage collection không xóa bằng chứng còn cần;
• private registry auth và custom CA hoạt động tại admission/runtime;
• retention của image và evidence đồng bộ.

Copy chỉ manifest image mà bỏ signature tạo artifact có digest đúng nhưng không qua admission ở môi trường sau.

11. Enforce tại admission/deploy, không dựa vào CI tự kiểm

Nếu CI vừa ký vừa tự báo thành công nhưng cluster vẫn cho chạy image bất kỳ, chữ ký chỉ là metadata tự nguyện. Cổng deploy phải fail closed theo policy:

• image thuộc registry/repository được phép;
• manifest đã pin digest;
• signature khớp identity và issuer production;
• provenance đến từ builder/workflow được duyệt;
• SBOM/vulnerability attestation đáp ứng policy và còn đủ mới;
• exception có owner, lý do, TTL và audit.

Sigstore Policy Controller là một lựa chọn cho Kubernetes; sản phẩm khác có admission/policy engine riêng. Dù dùng gì, test cả allow và deny, tag mutation, registry outage, log outage và certificate/root rotation.

12. Tránh self-approval trong cùng một trust domain

Nếu cùng một job có thể sửa source, thay workflow, build, tự ký và đổi policy cluster, chữ ký không tạo separation of duties. Tách quyền:

1. branch protection và review bảo vệ source/workflow;
2. builder identity chỉ build/sign repository được chỉ định;
3. policy repository có review/owner riêng;
4. cluster deploy role chỉ nhận artifact vượt admission;
5. audit log đi tới hệ không do release job kiểm soát.

13. Quan sát và xử lý sự cố

Ghi structured log cho digest, repository, signer identity, issuer, policy version, verification result và lý do deny; không log token/bundle chứa dữ liệu nhạy cảm ngoài nhu cầu. Metric nên có verification latency/error, deny theo reason, unsigned attempts, registry/tlog availability và exception count.

Khi nghi signer/workflow bị compromise:

1. đóng quyền OIDC/KMS và freeze promotion;
2. xác định identity, time window và digest đã ký từ log/evidence;
3. cập nhật deny/policy hoặc thu hồi trust theo cơ chế áp dụng;
4. rollback về digest đã xác minh độc lập;
5. rebuild từ source/runner sạch và phát hành digest mới;
6. không “xóa lịch sử” thay cho điều tra.

14. Kế hoạch rollout

1. Inventory registry, builder, identity, cluster và đường promote hiện tại.
2. Pin Cosign, xác minh tool và ký một repository thử nghiệm theo digest.
3. Chạy verification ở audit mode; ghi lại identity/issuer thật.
4. Thu hẹp policy, thêm negative tests và thử registry/log failure.
5. Enforce một namespace/service canary với break-glass có TTL.
6. Mở rộng theo repository; đo deny false positive và deployment latency.
7. Bắt buộc provenance/SBOM từng bước sau khi signature gate ổn định.

Checklist production

• Cosign được pin version và bootstrap verification.
• Image được ký/deploy bằng digest, không tin tag mutable.
• Keyless policy khóa cả exact identity và exact issuer.
• CI OIDC permission chỉ cấp cho job/repository/ref được phép.
• Transparency/bundle policy có privacy và outage behavior rõ ràng.
• Attestation kiểm tra signer, predicate type và nội dung claim.
• Registry promotion/GC đã test giữ signature và attestation.
• Admission fail closed, có exception TTL/audit thay vì bypass vĩnh viễn.
• Policy changes tách quyền khỏi release workflow.
• Incident runbook có scope digest, revoke trust, rollback và rebuild.

Kết luận

Cosign tạo giá trị khi chữ ký trở thành điều kiện deploy có thể kiểm chứng, không phải file trang trí cạnh image. Chuỗi đúng bắt đầu từ digest bất biến, identity OIDC được giới hạn, trusted root và bằng chứng thời gian/log, rồi kết thúc bằng admission policy fail closed. Kết hợp signature với provenance, SBOM, scanning và separation of duties sẽ trả lời không chỉ “ai ký?”, mà còn “artifact nào, được build ở đâu và vì sao nó được phép chạy?”.