CHƯƠNG 1: GIỚI THIỆU CHUNG sẽ và an toàn. Một số công cụ có thể sử dụng để quét container image như Trivy, Grype, Clair, v. Ký và xác minh container, container image trong quá trình build có thể bị xâm phạm, việc ký và xác minh đảm bảo sử dụng đúng container đạt chuẩn an toàn. Ngoài ra sử dụng distroless image không chỉ giảm kích thước image mà còn hạn chế được tấn công xâm nhập bề mặt.
Kiểm thử xác nhận container image bằng cách thêm 1 security layer vào container image để đảm bảo rằng container hoạt động đúng như mong đợi và có tất cả các file cần thiết với quyền chính xác. Một số công cụ có thể sử dụng như dgoss để kiểm thử cho container image và kgoss cho K8s Pod. Giai đoạn 4, tiến hành các kiểm thử sau: Smoke test, mặc dù là loại kiểm thử nhỏ nhưng có thể kiểm tra các thành phần và chức năng quan trọng của ứng dụng. Ví dụ có thể smoke test bằng cách chạy lệnh curl đến API để lấy respose code và độ trể phản hồi.
API testing có thể báo cáo về những hình thức xác thực được yêu cầu, liệu những dữ liệu nhạy cảm có được mã hoá qua HTTP và SQL Injection có cho phép vượt qua khâu đăng nhập hay không. Một số công cụ có thể triển khai API testing như Jmeter, Taurus, Postman và SoapUI. Kiểm thử bảo mật ứng dụng động (DAST), phương pháp này thực hiện kiểm thử các vấn đề về bao mật khi ứng dụng đang chạy. Kiểm thử bảo mật ừng dụng động có thể phát hiện một số lỗ hổng phổ biến như SQL Injection, XSS, Security misconfigurations, v.
Một số công cụ thực hiện DAST như HCL Appscan, ZAP, Burp Suite, và Invicti. Giai đoạn 5, giai đoạn triển khai có thể triển khai quét các tập tin cấu hình triển khai bao gồm: Quét tĩnh K8s manifest hoặc Helm chart, tương tự như code, các file manifest cũng có thể đặt những dữ liệu nhạy cảm như password, access token và điều này cũng cần được ngăn chặn. Ngoài ra việc cấu hình cũng có thể tạo ra các lỗ hổng khiến cho tin tặc dễ dàng xâm nhập và tấn công, một số công cụ có thể sử dụng để quét tĩnh manifest là Checkov, terascan, kubeLinter, Kyverno, Kubewarden và Gatekeeper. Quét CIS (the Center for Internet Security) benchmark đảm bảo môi trường K8s được cấu hình một cách an toàn và đáp ứng các phương pháp tốt nhất về bảo mật theo tiêu chuẩn ngành.
Có thể triển khai kube-bench như một K8s Job chạy hằng ngày và sử dụng báo cáo của kube-bench trong CI?CD để quyết định pipeline pass hay fail dựa trên mức độ nghiêm trọng. Giai đoạn 6, các thông tin nhạy cảm cũng có thể được rò rỉ bởi việc ghi nhật ký dưới dạng văn bản thuần tuý. Ví dụ để debug trong quá trình chạy ứng dụng, nhà phát triển đã cho ghi nhật ký header của request nhưng có thể header đó chứa access token. Một số công cụ để monitoring và alerting như Prometheus, Grafana, Elasticsearch, Nagios, Zabbix, Jaeger Tracing.
Lợi ích của DevSecOps bao gồm: Trần Trung Nam – D19HTTT04 11 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC CHƯƠNG 1: GIỚI THIỆU CHUNG Tìm lỗ hổng và lỗi ở giai đoạn phát triển trước đó. Tuân thủ hợp lý. Phục hồi nhanh chóng. Chuỗi cung ứng an toàn.
Tiết kiệm chi phí. Có thể bao gồm giám sát dựa trên AI để phát hiện sự bất thường. Giảm nguy cơ tấn công bề mặt và tăng độ tin cậy. Hiển thị đầy đủ các mối đe dọa tiềm ẩn và các cách khả thi để khắc phục nó.5 GitOps Cùng với sự ra đời của DevOps, GitOps sinh ra như một khung làm việc sử dụng các phương pháp hay nhất của DevOps để phát triển ứng dụng như kiểm soát phiên bản, tính cộng tác, sự tuân thủ nguyên tắc và quy trình CI/CD rồi áp dụng chúng vào tự động hóa cơ sở hạ tầng.
Như tên gọi, GitOps lấy Git làm trung tâm của các hoạt động của đội nhóm, doanh nghiệp. Ý tưởng chính của GitOps là biến Git trở thành Single Source of Truth (SSoT) lưu trữ toàn bộ cấu hình triển khai cơ sở hạ tầng cũng như cấu hình triển khai ứng dụng. GitOps yêu cầu 3 thành phần cốt lõi: GitOps = IaC + MRs + CI/CD [8]. IaC (Infrastrcuture as Code) - Cơ sở hạ tầng dưới dạng mã: GitOps sử dụng kho lưu trữ Git làm SSoT duy nhất cho các định nghĩa cơ sở hạ tầng.
Dựa vào tính năng kiểm soát phiên bản, theo dõi sự thay đổi source code của Git, việc thực hiện cơ sở hạ tầng dưới dạng mã giúp tăng tốc triển khai, giám sát trạng thái cấu hình hệ thống, đảm bảo khả năng phục hồi. MRs (Merge requests) - yêu cầu tích hợp source code: GitOps sử dụng các MR làm cơ chế thay đổi cho tất cả các bản cập nhật cơ sở hạ tầng. MR là nơi các đội nhóm có thể cộng tác thông qua các đánh giá và nhận xét và là nơi ra phê duyệt quyết định thay đổi cơ sở hạ tầng chính thức. CI/CD : GitOps tự động cập nhật cơ sở hạ tầng bằng quy trình làm việc Git với tích hợp liên tục (CI) và phân phối liên tục (CD).
Khi source code mới được hợp nhất, CI/CD pipeline thực hiện sự thay đổi trong môi trường. Bất kỳ sai lệch cấu hình nào, chẳng hạn như các thay đổi hoặc lỗi, đều được ghi đè bởi GitOps để môi trường thay đổi về trạng thái mong muốn được cấu hình trong Git. GitOps cung cấp: Quy trình làm việc tiêu chuẩn để phát triển ứng dụng. Tăng cường bảo mật để thiết lập trước các yêu cầu ứng dụng.
Cải thiện độ tin cậy với khả năng hiển thị và kiểm soát phiên bản thông qua Git. Tính nhất quán trên mọi môi trường cluster (cụm máy chủ), cloud (điện toán đám mây) và on-premise (tại doanh nghiệp). Trong đồ án này sẽ trình bày cụ thể về một trong các công cụ triển khai GitOps là ArgoCD. Bên cạnh đó còn có các công cụ khác như Flux, Gitkube, JenkinsX, v.
Trần Trung Nam – D19HTTT04 12 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC CHƯƠNG 1: GIỚI THIỆU CHUNG 1.3 Giới thiệu về hệ thống CI/CD Ở phần trước chúng ta đã tìm hiểu về DevOps và có đề cập tới CI/CD. DevOps ra đời mang theo một mô hình phát triển phần mềm mới đó là hệ thống tự động hóa CI/CD. Có thể nói CI/CD chính là trái tim của DevOps. Trong chương này ta sẽ tìm hiểu hệ thống CI/CD là gì? CI/CD pipeline là gì? Cách thức triển khai một hệ thống CI/CD hoàn chỉnh.1 Khái niệm CI/CD Hình 1.4: Mô hình CI/CD CI (Continuous Integration) - Tích hợp liên tục, đề cập đến việc tự động hóa việc tích hợp source code từ các thành viên trong nhóm phát triển vào một kho lưu trữ source code (ví dụ: Git) một cách sớm và thường xuyên hơn.
Mỗi khi có sự thay đổi về source code, code sẽ được tự động kiểm thử bằng các quy trình xác thực. Thông thường các quy trình bắt đầu bằng việc phân tích code tĩnh để xác minh chất lượng của code. Sau khi code vượt qua các bài kiểm thử tĩnh, các quy trình CI tự động sẽ đóng gói và biên dịch code để kiểm thử động. Các quy trình CI phải có hệ thống kiểm soát phiên bản theo dõi các thay đổi để biết phiên bản code được sử dụng.
Mục tiêu của CI là đảm bảo rằng source code mới được thêm vào dự án không gây ra lỗi tích hợp và không làm hỏng công việc của các thành viên khác. Với sự tích hợp liên tục, các lỗi và vấn đề bảo mật có thể được xác định và sửa chữa dễ dàng hơn và sớm hơn nhiều trong quá trình phát triển. Bằng cách hợp nhất các thay đổi thường xuyên và kích hoạt các quy trình kiểm thử và xác thực tự động, hệ thống CI giúp giảm thiểu khả năng xung đột code, ngay cả khi có nhiều nhà phát triển làm việc trên cùng một ứng dụng. Một lợi ích lớn mà hệ thống CI mang lại đó chính là rút ngắn khoảng thời gian chờ từ khi các nhà phát triển commit code cho đến khi nhận được phản hồi đánh giá chất lượng source code từ các bộ phận khác và tiến hành thay đổi, sửa lỗi.
Với CI, các nhà phát triển không phải đợi Trần Trung Nam – D19HTTT04 13 ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC CHƯƠNG 1: GIỚI THIỆU CHUNG lâu để có kết quả đánh giá chất lượng source code từ đó có thể sẵn sàng sửa các lỗi và vấn đề bảo mật sớm nhất có thể. CD (Continuous Delivery/Continuous Deployment), thuật ngữ CD có 2 nghĩa là Phân phối liên tục và Triển khai liên tục. Phân phối liên tục đề cập đến việc tự động hóa quy trình cung cấp cơ sở hạ tầng và release ứng dụng. Sau khi code đã được test và build, hệ thống Phân phối liên tục sẽ tiếp quản các giai đoạn cuối cùng để đảm bảo code được đóng gói với mọi thứ cần thiết để triển khai trên mọi môi trường vào bất kỳ lúc nào.
Phân phối liên tục có thể bao gồm mọi công đoạn từ việc cung cấp cơ sở hạ tầng đến việc phân phối ứng dụng tới các môi trường thử nghiệm hoặc sản xuất. Với Phân phối liên tục, phần mềm được xây dựng có thể triển khai vào môi trường sản xuất bất kỳ lúc nào. Việc triển khai có thể kích hoạt theo cách thủ công hoặc chuyển sang Triển khai liên tục trong đó việc triển khai cũng được tự động hóa. Triển khai liên tục là giai đoạn cuối của quá trình CI/CD.
Triển khai liên tục là phần mở rộng của Phân phối liên tục, cho phép các tổ chức triển khai ứng dụng của họ một cách tự động, loại bỏ nhu cầu can thiệp của con người. Với việc triển khai liên tục, các nhóm DevOps đặt ra trước các tiêu chí cho việc release code và khi các tiêu chí đó được đáp ứng và xác thực, code sẽ được triển khai vào môi trường sản xuất. Điều này cho phép các tổ chức hoạt động linh hoạt hơn và đưa các tính năng mới đến người dùng nhanh hơn. Mặc dù có thể thực hiện CI mà không cần CD, nhưng thực sự không thể thực hiện CD nếu không có sẵn CI.
Đó là bởi vì sẽ cực kỳ khó để có thể triển khai vào môi trường sản xuất bất cứ lúc nào nếu không thực hành các nguyên tắc cơ bản về CI như tích hợp code vào kho lưu trữ chung, tự động hóa kiểm thử và build cũng như thực hiện tất cả các công việc đó theo từng đợt nhỏ hàng ngày. Thực tế việc Triển khai liên tục sẽ không được khuyến khích áp dụng với môi trường production mà chỉ áp dụng với các môi trường dev, test, UAT, stagging, v.