Checkov: chặn cấu hình hạ tầng sai ngay trong pipeline, từ Terraform đến Kubernetes
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Checkov trong một trang: máy kiểm tra cấu hình hạ tầng trước khi hạ tầng tồn tại
Checkov là công cụ phân tích tĩnh (static analysis) dành cho hạ tầng khai báo bằng mã, hay infrastructure as code (IaC). Nó đọc các tệp như Terraform, CloudFormation, Kubernetes, Helm hay Dockerfile rồi đối chiếu với một tập chính sách để phát hiện cấu hình sai trước khi hạ tầng được tạo ra. README của dự án còn mô tả phần quét thành phần phần mềm (SCA) cho gói mã nguồn mở và ảnh container, cùng khả năng dò bí mật trong tệp cấu hình. [1][4]
Nên cân nhắc Checkov khi tổ chức đã quản lý hạ tầng bằng mã, có kho Git và có bước kiểm tra tự động. Không nên kỳ vọng nó thay thế rà soát kiến trúc, quét lỗ hổng ứng dụng đang chạy hay giám sát môi trường thật. Tài liệu của dự án tự nói rõ phần phát hiện lệch cấu hình lúc chạy thuộc về nền tảng Prisma Cloud, một sản phẩm thương mại, chứ không nằm trong gói quét cục bộ. [4]
Khuyến nghị của bài là thử trên một kho hạ tầng nhỏ, đặt chế độ chỉ cảnh báo trong hai tuần đầu, đo tỷ lệ cảnh báo giả rồi mới nâng lên chế độ chặn.
Cấu hình sai thường lọt qua vì không ai đọc hết hàng nghìn dòng khai báo
Khi hạ tầng được mô tả bằng tệp văn bản, một thay đổi nhỏ có thể làm mở cổng mạng, tắt mã hóa đĩa hoặc cấp quyền quản trị quá rộng mà người duyệt không để ý. Người xem pull request thường chú ý đến logic nghiệp vụ hơn là thuộc tính trông vô hại như một giá trị ACL. Lỗi loại này không làm ứng dụng ngừng chạy, nên không bị kiểm thử chức năng phát hiện.
Checkov giải quyết bằng cách biến các quy tắc an toàn thành chính sách có mã số. Tài liệu khái niệm mô tả mỗi lần quét sẽ tạo ra một incident cho từng trường hợp không tuân thủ chính sách, và tài nguyên (resource) là thực thể trên nền tảng đám mây như máy ảo hay bucket. [5]
Có một lớp vấn đề khó hơn là quan hệ giữa các tài nguyên. Một cơ sở dữ liệu có thể an toàn khi đứng riêng nhưng nguy hiểm khi nằm cạnh một nhóm bảo mật mở toàn bộ cổng. README nêu dự án hỗ trợ chính sách nhận biết ngữ cảnh dựa trên đồ thị lưu trong bộ nhớ, và tài liệu khái niệm nói chính sách composite kiểm tra các tài nguyên có hoặc không có kết nối với nhau. [1][5]
Bộ quét, bộ chính sách và đồ thị: ba lớp bên trong một lệnh checkov
Về hình thức, Checkov là một chương trình Python chạy từ dòng lệnh, cài bằng pip hoặc Homebrew, hoặc chạy qua ảnh Docker. Người dùng chỉ định thư mục hoặc tệp đầu vào, và công cụ chọn các bộ quét (framework) phù hợp với loại tệp tìm thấy. README liệt kê cả nhóm tệp hạ tầng lẫn nhóm tệp pipeline như GitHub Actions, GitLab CI, Azure Pipelines, Bitbucket Pipelines, CircleCI và Argo Workflows. [1]
Lớp thứ nhất là các chính sách thuộc tính, kiểm tra một giá trị cấu hình trên một tài nguyên. Lớp thứ hai là chính sách composite hay trạng thái kết nối, dùng đồ thị tài nguyên để hỏi xem A có nối với B hay không. Tài liệu YAML Custom Policies phân biệt ba loại khối định nghĩa: khối thuộc tính, khối trạng thái kết nối và khối loại tài nguyên cho danh sách được phép hoặc bị cấm, kết hợp được bằng các toán tử and, or và not. [8]
Lớp thứ ba là phần điều khiển kết quả. Mã thoát của tiến trình bằng 0 khi mọi kiểm tra đạt hoặc bị bỏ qua, và bằng 1 nếu có lỗi, trừ khi người dùng đặt các cờ soft-fail hoặc hard-fail. Thiết kế này biến Checkov thành một cổng kiểm soát trong CI mà không cần tích hợp riêng: hệ thống CI nào cũng đọc được mã thoát. [6]
Từ thư mục Terraform đến mã thoát của pipeline: hành trình của một lần quét
Một lần quét bắt đầu bằng lệnh có tham số thư mục hoặc tệp, ví dụ chỉ định một thư mục hạ tầng hoặc nhiều tệp CloudFormation. Công cụ đọc tệp, phân tích cú pháp, đánh giá biến tới giá trị mặc định nếu có, dựng danh sách tài nguyên và đồ thị liên kết rồi chạy từng chính sách. [1]
Với Terraform plan, đường đi phức tạp hơn. README hướng dẫn xuất plan sang JSON bằng terraform show, và ghi chú rằng tệp này nằm trên một dòng nên mọi phát hiện đều báo số dòng 0. Cách khắc phục được nêu là định dạng lại bằng jq hoặc dùng cờ repo-root-for-plan-enrichment để bổ sung đường dẫn tệp, số dòng và đoạn mã, đồng thời cho phép xử lý các ghi chú bỏ qua. [1]
Cuối cùng, kết quả được xuất ra CLI hoặc các định dạng máy đọc được như JSON, JUnit XML, CSV, SARIF, CycloneDX. Theo phần Disclaimer của README, Checkov gọi API của Prisma Cloud để lấy đường dẫn hướng dẫn khắc phục, và có thể tắt lời gọi này bằng cờ skip-download. [1]
Những gì tài liệu xác nhận Checkov làm được, và hai con số không khớp nhau
Về phạm vi quét, README nêu Terraform, Terraform plan, Terraform JSON, CloudFormation, AWS SAM, Kubernetes, Helm, Kustomize, Dockerfile, Serverless framework, Ansible, Bicep, ARM và OpenTofu, cộng thêm sáu loại tệp pipeline CI. Trang What is Checkov liệt kê một danh sách ngắn hơn, gồm Terraform cho AWS, GCP, Azure và OCI, CloudFormation, ARM, Serverless, Helm, Kubernetes và Docker. Bài không có cách kiểm tra độc lập để biết danh sách nào phản ánh đúng hơn. [1][4]
Về số lượng chính sách, README viết hơn 1000 chính sách tích hợp, còn trang What is Checkov viết hơn 750. Hai con số cùng nằm trong kho tại một commit nhưng khác nhau, nên bài không dùng số nào làm tiêu chí đánh giá. Cách đúng là đối chiếu trực tiếp chỉ mục chính sách cho đúng loại tài nguyên bạn dùng trước khi quyết định. [1][4]
Về tùy biến, chính sách tự viết được hỗ trợ bằng Python cho kiểm tra thuộc tính và YAML cho cả thuộc tính lẫn composite. Siêu dữ liệu YAML gồm tên, mã theo dạng CKV2 kèm nhà cung cấp và số thứ tự, nhóm như ENCRYPTION, IAM hay NETWORKING, đường dẫn hướng dẫn tùy chọn và mức nghiêm trọng từ INFO đến CRITICAL. Các toán tử như equals, regex_match, exists, contains, within, starting_with được liệt kê. [8]
Ai nên đọc tiếp: đội đã có kho hạ tầng và muốn cổng kiểm soát bằng mã
Đối tượng phù hợp nhất là đội DevOps hoặc nền tảng có từ vài chục tới vài trăm tệp Terraform, Helm hay CloudFormation, đã dùng Git và có CI. Với họ, Checkov là thêm một bước vào pipeline, không phải một hệ thống mới. [1][8]
Nhóm thứ hai là đội tuân thủ hoặc kiểm toán nội bộ cần bằng chứng lặp lại được. Kết quả xuất dưới dạng SARIF hoặc JUnit có thể lưu theo từng lần chạy, và các ngoại lệ bỏ qua có lý do nằm ngay trong mã nguồn nên đi qua cùng quy trình duyệt như mọi thay đổi khác. Điều này hữu ích nhưng không tự động chứng nhận tuân thủ chuẩn nào. [1][7]
Trong ngữ cảnh sản xuất tri thức, một văn phòng nhỏ chạy hệ thống ghi chú và tài liệu riêng trên máy chủ thuê cũng có thể dùng Checkov để kiểm tra tệp Docker và Kubernetes của chính mình. Đây là hướng áp dụng khả dĩ cho các nhóm như BDSG Foundation khi tự dựng hạ tầng thử nghiệm; bài không khẳng định tổ chức nào đang dùng.
Tình huống giả định: xưởng in bao bì đưa cổng đặt hàng và kho tệp thiết kế vào kiểm tra tự động
Hãy hình dung một xưởng in bao bì carton và nhãn mác ở khu vực Bình Dương với khoảng 150 nhân sự. Xưởng vận hành một cổng đặt hàng cho khách doanh nghiệp, nơi khách tải lên tệp thiết kế, xem báo giá và theo dõi tiến độ máy in. Hạ tầng gồm vài máy chủ ứng dụng, một cơ sở dữ liệu đơn hàng, kho lưu trữ tệp lớn và một mạng riêng ảo nối về xưởng. Đây là tình huống đề xuất để minh họa, không phải một khách hàng thật.
Tệp thiết kế của khách là tài sản nhạy cảm: mẫu bao bì chưa ra mắt, nhãn hiệu, mã vạch. Một bucket lưu trữ đặt nhầm chế độ công khai là rủi ro kinh doanh lớn. Đội kỹ thuật hai người của xưởng khai báo hạ tầng bằng Terraform, và Checkov sẽ đứng ở bước pull request để kiểm tra thuộc tính như quyền truy cập công khai của kho lưu trữ, mã hóa dữ liệu lúc nghỉ, và nhật ký truy cập, với điều kiện chỉ mục chính sách có kiểm tra tương ứng cho nhà cung cấp đám mây họ dùng. [1]
Với ngoại lệ, xưởng có thể cần giữ một bucket công khai chứa catalog sản phẩm dành cho khách xem. Khi đó chú thích skip kèm lý do trong khối tài nguyên giúp ghi nhận quyết định, và kết quả sẽ hiển thị là SKIPPED cùng lý do. Quy tắc nội bộ đề xuất là mọi chú thích skip phải có tên người duyệt và mã phiếu; đó là quy trình của xưởng, không phải tính năng của Checkov. [7]
Đưa Checkov vào CI: ảnh Docker, tệp cấu hình đáng tin và nhịp cập nhật chính sách
Cách triển khai gọn nhất là chạy trong pipeline CI hiện có. README hướng dẫn cài bằng pip hoặc Homebrew và chạy bằng ảnh Docker với thư mục dữ liệu được gắn vào. Nó cũng lưu ý nên bỏ cờ tty khi cần ghi kết quả JUnit ra tệp, vì cờ này chèn ký tự điều khiển làm hỏng việc phân tích tệp. [1]
Về cấu hình, Checkov tìm tệp .checkov.yaml hoặc .checkov.yml theo thứ tự: thư mục đang quét, thư mục làm việc hiện tại, rồi thư mục người dùng. README cảnh báo nên nạp cấu hình từ nguồn đáng tin có danh tính xác minh, vì tệp cấu hình quyết định kiểm tra nào chạy và có nạp chính sách tùy chỉnh nào. [1]
Việc cập nhật là một câu hỏi thực tế. Công cụ thay đổi theo từng bản phát hành, chính sách mới có thể làm một pipeline đang xanh chuyển sang đỏ chỉ vì nâng phiên bản. Đề xuất là ghim phiên bản trong CI, nâng theo lịch, và chạy bản mới ở chế độ soft-fail trước khi đổi ngưỡng. Đây là thực hành chung, không phải khuyến nghị từ tài liệu dự án.
Công cụ bảo mật cũng là bề mặt tấn công: cấu hình, chính sách ngoài và khóa API
Rủi ro đầu tiên là nguồn của cấu hình và chính sách. README cảnh báo tệp cấu hình ảnh hưởng đến việc tệp nào được quét, mã kiểm tra nào được dùng và kiểm tra tùy chỉnh nào được nạp. Nếu một pull request có thể sửa tệp này, kẻ xấu hoặc người vô ý có thể tắt kiểm tra mà không chạm vào mã hạ tầng. Hãy đặt cấu hình ở kho riêng có kiểm soát quyền ghi. [1]
Rủi ro thứ ba là luồng mạng ra ngoài và khóa API. README cho biết dự án không lưu, công bố hay chia sẻ thông tin định danh khách hàng, và lời gọi enrich kết quả chỉ truy vấn các hướng dẫn công khai của Prisma Cloud. Dù vậy, khóa API nền tảng cần được coi là bí mật CI bình thường, và nếu dùng cờ cần khóa thì phải có kế hoạch xoay vòng. Tuyên bố của nhà phát triển không thay thế việc tự quan sát lưu lượng mạng. [1]
Về quy trình lỗ hổng của chính Checkov, SECURITY.md yêu cầu báo riêng qua email của nhóm PSIRT của Palo Alto Networks, không mở issue công khai. Mục tiêu nêu là phát hành bản vá trong vòng hai tuần kể từ lúc nhận báo cáo và công bố qua bản phát hành PyPI cùng kênh Slack. Đây là mục tiêu, không phải bảo đảm. [3]
Apache-2.0 cho mã nguồn, nhưng nền tảng thương mại đi kèm có điều khoản riêng
Tệp LICENSE tại commit đã ghim là văn bản Apache License 2.0 đầy đủ, với dòng bản quyền năm 2019 của Palo Alto Networks. Apache-2.0 cho phép dùng, sửa, phân phối, kể cả mục đích thương mại, miễn là giữ thông báo bản quyền và giấy phép, đồng thời nêu thay đổi và tuân thủ điều khoản về bằng sáng chế. Danh sách thư mục ở commit này không cho thấy tệp giấy phép bổ sung trong cây tài liệu mà bài đã xem. [2]
Cần phân biệt ba lớp. Lớp thứ nhất là mã nguồn Checkov tại commit này. Lớp thứ hai là các phụ thuộc bên thứ ba cài cùng, mỗi cái có giấy phép riêng cần kiểm tra bằng công cụ quản lý giấy phép của bạn. Lớp thứ ba là Prisma Cloud, nền tảng thương mại mà README và tài liệu nói Checkov hỗ trợ, nơi các tính năng như phát hiện lệch cấu hình lúc chạy hay chú thích pull request tự động được mô tả. Giấy phép Apache-2.0 trong kho này không tự động áp dụng cho dịch vụ đó. [1][2][4]
Dự án do Prisma Cloud duy trì theo README. Bài không tìm thấy trong các tệp đã đọc một thỏa thuận cấp quyền đóng góp hay điều khoản nhãn hiệu cụ thể, nhưng điều đó chỉ có nghĩa là các tệp đã đọc không đề cập, không phải xác nhận rằng chúng không tồn tại. [1]
Chi phí thật nằm ở thời gian chỉnh chính sách, không nằm ở tiền bản quyền
Vì Checkov là phần mềm Apache-2.0 nên không có phí bản quyền cho phần mã trong kho. Chi phí đến từ bốn loại nguồn lực: thời gian kỹ sư để tích hợp vào CI và viết chính sách riêng, thời gian của người duyệt cho cảnh báo mới, tài nguyên tính toán của máy chạy CI, và tùy chọn có phí nếu đội muốn dùng nền tảng thương mại. Bài không đưa giá vì không có nguồn đã đọc cho phép nêu giá hiện hành. [1][4]
Về phần cứng, một lần quét là tiến trình Python đọc tệp văn bản, chạy trên runner CI thông thường. Kho lớn với nhiều module Terraform được tải từ ngoài sẽ tốn thời gian và băng thông hơn; README có nhắc cờ tải module ngoài và thư mục đích mặc định, nên cần cân nhắc bộ nhớ đệm trong pipeline. [1]
Khoản chi dễ bị bỏ sót là đào tạo. Nhà phát triển cần hiểu vì sao một kiểm tra đỏ và khi nào được phép bỏ qua. Nếu mỗi cảnh báo bị xử lý bằng một dòng skip không lý do, giá trị bảo mật gần như mất. [7]
Đặt Checkov cạnh các hướng tiếp cận khác trong kiểm tra hạ tầng
Ở mức phương pháp có thể chia thành bốn hướng. Hướng thứ nhất là quét tĩnh tệp IaC trong CI như Checkov. Hướng thứ hai là chính sách thực thi tại thời điểm triển khai, chẳng hạn bộ điều khiển admission trong Kubernetes hay chính sách do chính nhà cung cấp đám mây áp lên tài khoản. Hướng thứ ba là quét môi trường đang chạy để tìm sai lệch.
Quét tĩnh phát hiện sớm và rẻ, nhưng chỉ thấy những gì nằm trong tệp. Tài nguyên tạo tay hoặc thay đổi ngoài pipeline sẽ không xuất hiện, và tài liệu của chính dự án thừa nhận phân tích tĩnh bị giới hạn bởi phạm vi phân tích, ví dụ tài nguyên quản lý thủ công hoặc bằng công cụ cấu hình khác. Hướng thực thi lúc triển khai chặn được cả thay đổi ngoài Git nhưng muộn hơn trong vòng đời. [7]
Quét môi trường chạy bù khoảng trống đó. Theo trang What is Checkov, đây là phần Prisma Cloud mở rộng, kèm phát hiện lệch cấu hình và pull request sửa tự động. Bài không so sánh chất lượng với sản phẩm cụ thể nào vì không có nguồn đã đọc để làm điều đó. [4]
Hạn chế: cảnh báo giả, mâu thuẫn tài liệu và giới hạn của phân tích tĩnh
Hạn chế đầu tiên là cảnh báo giả và cảnh báo đúng nhưng không liên quan. Một chính sách mặc định không biết ngữ cảnh kinh doanh của bạn, ví dụ bucket công khai có chủ đích. Cơ chế suppression sinh ra cho việc này, nhưng nếu lạm dụng thì cổng kiểm soát mất ý nghĩa. Trong giai đoạn đầu, hãy theo dõi tỷ lệ cảnh báo đã bị bỏ qua so với tổng số. [7]
Hạn chế thứ hai là tài liệu không hoàn toàn nhất quán, như số lượng chính sách và danh sách loại tệp hỗ trợ đã nêu. Điều này không phải lỗi phần mềm, nhưng khiến việc lập kế hoạch dựa trên tài liệu cần thêm bước xác minh trên môi trường thật. [1][4]
Không nên dùng Checkov như bằng chứng duy nhất về an toàn. Nó không kiểm thử ứng dụng, không phát hiện tài khoản bị chiếm, không biết ai đang truy cập dữ liệu. Với tổ chức chưa có người đủ thời gian xử lý cảnh báo, việc bật chế độ chặn sớm có thể làm chậm giao hàng mà không tăng an toàn tương xứng; chế độ soft-fail tồn tại chính là để tránh tình huống đó. [6]
Thử nghiệm sáu tuần: từ soft-fail đến hard-fail có tiêu chí thoát rõ ràng
Giai đoạn 1, tuần 1 và 2: chọn một kho hạ tầng đại diện và chạy Checkov với cờ soft-fail để không chặn ai. Ghi lại tổng số phát hiện, số theo từng chính sách, thời gian chạy trên runner CI và số phát hiện mà kỹ sư xác nhận là đúng sau khi xem thủ công một mẫu ngẫu nhiên. Mục tiêu giai đoạn này là có số liệu nền, không phải sửa hết lỗi. [6]
Giai đoạn 2, tuần 3 và 4: xử lý các phát hiện đúng ở mức nghiêm trọng cao, viết suppression có lý do cho trường hợp chấp nhận rủi ro, và viết một đến ba chính sách YAML thể hiện quy ước nội bộ. Đo số phút người duyệt tốn thêm cho mỗi pull request. Tiêu chí đề xuất: tỷ lệ phát hiện bị đánh giá là cảnh báo giả giảm xuống dưới ngưỡng đội tự đặt từ đầu giai đoạn. [7][8]
Giai đoạn 3, tuần 5 và 6: bật hard-fail cho nhóm chính sách đã ổn định, giữ soft-fail cho phần còn lại bằng các cờ soft-fail-on và hard-fail-on, rồi theo dõi số pipeline bị chặn và thời gian xử lý. Tài liệu mô tả rõ thứ tự ưu tiên khi kết hợp các cờ, nên đội cần kiểm thử các tổ hợp trên một nhánh thử trước khi áp dụng. [6]
Tiêu chí thoát, đều là đề xuất: tiếp tục nếu pipeline không bị chặn vì lý do không xử lý được trong cùng ngày làm việc, nếu mọi ngoại lệ đều có lý do và người duyệt, và nếu đội đánh giá chi phí duyệt thêm chấp nhận được. Dừng hoặc quay lại soft-fail nếu cảnh báo giả vẫn chiếm phần lớn, hoặc nếu việc cần khóa API nền tảng không phù hợp chính sách dữ liệu của tổ chức. [1]
Kết luận: dùng như hàng rào ở cổng vào, không như tấm khiên toàn năng
Checkov đáp ứng một nhu cầu cụ thể và rõ ràng: chặn cấu hình hạ tầng sai trước khi nó được triển khai, bằng chính sách có mã số và mã thoát dễ tích hợp vào mọi hệ thống CI. Tài liệu tại commit đã ghim mô tả phạm vi quét rộng, hai kiểu chính sách, cơ chế bỏ qua có lý do và các chế độ thất bại mềm hoặc cứng. [1][6][7]
Giấy phép Apache-2.0 ở mức mã nguồn rất thuận lợi, nhưng ranh giới với nền tảng Prisma Cloud thương mại cần được nhìn rõ khi lập kế hoạch, nhất là với các tính năng lọc theo mức nghiêm trọng và quét SCA, nơi ví dụ của README dùng khóa API. [1][2][4]
Với các nhóm như xưởng in trong tình huống giả định, bước đi hợp lý là thử nhỏ, đo, rồi mới siết.
Nguồn và phương pháp
Bài này là nghiên cứu tại bàn (desk research) và không phải công bố khoa học được bình duyệt. Dự án được chọn từ kho lưu trữ GitHub Trending có phạm vi giới hạn: kho chỉ gồm các danh sách Python, Go, JavaScript và Swift, thiếu các ngày 2026-09-03 và 2026-10-12, và không phải bảng xếp hạng chính thức top 100. Checkov xuất hiện một lần, ngày 2026-01-01, ở vị trí 15 trong danh sách Python. [9]
Nội dung được kiểm tra ngày 2026-10-12 tại commit a59eb500967c7186d0e8588f205912f42ea9b2b1, có ngày commit 2026-10-11. Các tệp đã đọc gồm README, LICENSE, SECURITY.md, và năm tài liệu bổ sung ở cùng commit: What is Checkov, Terms and Concepts, Hard and soft fail, Suppressing and Skipping Policies, YAML Custom Policies. [1][2][3][4][5][6][7][8]
Tác giả không cài đặt, không chạy, không đo hiệu năng và không triển khai Checkov. Mọi mô tả hành vi là diễn giải tài liệu; những chỗ là đề xuất, như tình huống xưởng in, lộ trình thử nghiệm và giả định chi phí, được ghi rõ là đề xuất. Số liệu chỉ lấy từ nguồn đã trích dẫn.
Xem mã nguồn Checkov trên GitHub