Khóa luận tốt nghiệp An toàn thông tin: Triển khai giải pháp bảo mật cho hệ thống Kubernetes và Azure Kubernetes Service sử dụng CIS Benchmark

° Nghiên cứu và thực hiện cấu hình hệ thống Kubernetes K8S được sử dụng đê triên khai ứng dụng Microservices.. Kich ban 1 — Thực hiện kiểm tra và cấu hình tự động đối vớiKubernetes có tr

So sánh GitLab CI/CD va Azure Pipelines

Bảng so sánh dưới đây mô tả những nội dung được hỗ trợ giữa Azure Pipelines và GitLab CI/CD Nội dung của bảng được nhóm tác giả lựa chọn nổi bật nhất để so sánh vì những tính năng của hai công cụ rất nhiều.

Nội dung Azure Pipelines GitLab CI/CD

Pipelines được thực thi khi Có Có có commit được day lênh

Remote Version Control hoặc được kích hoạt thủ công

Pipelines được thực thi trong Có Không một khoảng thời gian quy định

Pipelines được thực thi theo Có Có lịch

Hỗ trợ nhiều ngôn ngữ lập Có Có trình khác nhau

Hỗ trợ trực tiếp với Mirosoft Có Cần cấu hình script để Azure kết nối

Hỗ trợ trực tiếp với Amazon Có Cần cấu hình script để AWS kết nối

Hỗ trợ trực tiếp với Google Có Có hỗ trợ tuy nhiên vẫn GCP cần cấu hình script đề kết nối Câu trúc, cú pháp Phức tạp hơn Ngắn gọn hơn

Bang 2.1: So sánh giữa GitLab CI/CD va Azure Pipelines

Vì trong phạm vi của đề tài, nhóm tác giả triển khai ứng dụng trên môi trường Microsoft Azure, cụ thé là AKS nên nhóm tác gia lựa chọn sử dụng công cụ Azure Pipelines Tuy nhiên, nếu dự án sử dụng Version Control là GitLab và sử dụng những nền tang Cloud khác, việc lựa chọn GitLab CI/CD được khuyến khích hơn Do việc thực hiện các script trên GitLab sẽ ngắn gọn và được nhiều hỗ trợ từ cộng đồng.

PHƯƠNG PHAP THUC HIEN .ssssssssssssscccsccsessssnessnsnnnnnnsssesseeeee 28 3.1 Phương pháp triển khai hệ thông Kubernetes

Xây dựng hệ thống Kubernetes bằng Minikube

Dé có thể triển khai hệ thống này, nhóm tác giả tiễn hành cài đặt Minikube, sau đó tao 2 node trong cluster với 1 node đóng vai trò là master, node còn lại là worker Nhóm tác giả có sử dụng thêm công cụ kubectl - đây là công cụ cho phép sử dụng các dòng lệnh đề quan trị Kubernetes cluster Kubectl sử dụng Kubernetes API dé tương tác với Kubernetes cluster. ubuntu@ubuntu:~/Desktop$ kubectL get nodes

NAME STATUS ROLES AGE VERSION kuberv1.23 Ready control-plane,master 78d v1.23.1 kuberv1.23-m02 Ready 21d V1.23.1 ubuntu@ubuntu:~/Desktop$

Hình 3.1: Thông tin các node được tao bằng Minikube

Sau do, nhom tac gia tiến hành bật các addons như hình bên dưới để việc triển khai ứng dụng microservice trên kubernetes không gặp lỗi. ubuntu@ubuntu:~/Desktop$ minikube -p kuberv1.23 addons list | grep enable

| default-storageclass | kuberv1.23 | enabled [4 | Kubernetes |

| tngress-dns | kuberv1.23 | enabled [J | Google |

| storage-provisioner | kuberv1.23 | enabled [Á | Google | ubuntu@ubuntu:~/Desktop$ ẽŸ

Hình 3.2: Thông tin các addons trong Minikube

Xây dựng hệ thống Kubernetes bằng Azure Kubernetes Service

Để triển khai hệ thống Kubernetes trên nền tảng Azure Kubernetes Service, nhóm tác giả tiến hành tạo Kubernetes cluster trên AKS Nhóm tác giả lựa chọn phương pháp tạo AKS cluster sử dụng Azure Portal Sau khi triển khai Kubernetes cluster trên AKS, nhóm dùng AZ CLI để lấy kubectl context dé kubectl có thé kết nối tới Kubernetes API Server và quản lý được các resource trong AKS. trind@trind2-lap:~$ az aks get-credentials resource-group aks-cis-bench name demo-cis Merged "demo-cis" as current context in /home/trind/.kube/config trind@trind2-lap:~$ kubectl get nodes -o wide

NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTER NAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME aks-agentpool-14585136-vmss000000 Ready agent 6m28s v1.24.6 10.224.0.4 Ubuntu 18.64.6 LTS 5.4.8-1098-azure containerd://1.6.4+azure-4

Ứng dụng Microservices và phương pháp triển khai lên Kubernetes

3.2.1 Ung dụng web dựa trên Microservices Ứng dụng web dựa trên Microservices của nhóm tác giả là ứng dụng open source sử dung framework Flask Về cơ bản, ứng dụng web được chia thành 4 ứng dụng nhỏ Ứng dung front-end hiền thị giao diện được viết bằng ReactJS và phần xử lí thì sử dụng Flask Khi tương tác trên giao diện này, ứng dụng frontend sẽ gửi các API tương ứng với các chức năng mà người dùng muốn sử dụng về các ứng dụng backend xử lí Và về phía backend sẽ chia thành 3 services khác nhau tương ứng với 3 loại API khác nhau mà ứng dụng frontend sẽ sử dụng 3 service đó là 3 ứng dụng web viết theo framework Flask, 1an lượt là order, product, user Theo repository project gốc thi ứng dụng microservice này sẽ sử dung 3 database khác nhau cho 3 service và MySQL là database ma project dùng. Để triển ứng dụng Microservice nay thì ban đầu nhóm tác giả sé build các

Docker Image, sau đó chạy các container của 3 services backend cũng như các container cua frontend, database.

Cụ thể mô hình triển khai ứng dụng với Docker Container được diễn tả như hình sau: micro network a Je docker order-sve

Flask order-db frontend-app user-sve user-db vs _.— product-dban

Mỗi ứng dụng Python Flask tương ứng với mỗi service của ứng dụng web tổng và mỗi service này sẽ có 1 database riêng Với database thì ở giai đoạn này nhóm sẽ tạo và khởi chạy bằng container Vì các container đều chạy trong | mạng container ảo được nhóm tạo, do đó chúng đều có thể liên lạc, gửi dữ liệu cho nhau thông qua tên host được đặt Từ tên host thông qua dns sẽ được dịch sang địa chỉ IP nhất định dé kết nối với nhau.

Dockerfile dé build image của các ứng dụng như sau:

C0PY requirements.txt /orderapp/requirements.txt WORKDIR /orderapp

RUN pip install -r requirements.txt Copy /orderapp

Hinh 3.5: Dockerfile cua service orderapp trong tmg dung

Nội dung của file Dockerfile này chi là tải các thư viện python cần thiết va khởi chạy ứng dụng Flask khi container được start bằng cách chạy file run.py Vì là ứng dụng Flask đơn giản nên việc tạo Dockerfile cũng hầu như không cầu kì Các ứng dụng Flask khác cũng được viết Dockerfile tương tự.

Nhóm tác gia cũng sử dung Docker compose dé cho việc chạy ứng dụng từ các image một cách nhanh gọn hơn Cụ thể về docker compose file thì có thể xem tại mã nguồn của ứng dụng được nhóm tác giả lưu trên GitHub!.

3.2.2 Triển khai ứng dụng lên Kubernetes Ứng dụng này sẽ được triển khai lên nền tảng Minikube/Azure Kubernetes Services bằng file deployment có định dạng là YAML Các file Deployment là đơn vị để Kubernetes triển khai, cập nhật, quản trị các Pod một cách dễ dàng và thuận tiện hơn.

' https://github.com/trisngo/flask-microservices-deployment

31 apiVersion: apps/v1 kind: Deployment metadata: name: spec: replicas: selector: matchLabels:

- name: image:

- name: image:

Hình 3.6: Cấu trúc file YAML Cấu trúc một file Deployment [10] bao gồm các trường sau: name: là tên của Deployment replicas: là số lượng Pod mà người dùng muốn

Deployment đảm bảo. labels: định nghĩa label cho Pod. name: là tên của container sau khi khởi tạo bên trong Pod. name: là tên của Image dùng dé tạo container. selector: định nghĩa cách mà Deployment tìm các Pod cần quản lý Selector sử dụng thuộc tính matchLabels để làm điều này Bất kỳ Pod nào có label định nghĩa là “” sẽ được Deployment select và quản lý. template: template ding để định nghĩa thông tin về Pod mà người ding muốn chạy. containers: Mỗi container sẽ có ít nhất là tên container và Image được sử dụng để tạo container.

3.3 Phương pháp triển khai CI/CD cho ứng dụng lên AKS

Mô hình CI/CD Pipelines được em xây dựng nhằm triển khai ứng dụng lên

Ca m Monitor ari Azure i ‘a Container Grafana

Hình 3.7: Sơ đồ CI/CD pipeline của ứng dụng được triển khai

Giai đoạn plan: bộ phận phát trién cũng như triển khai sẽ được lên plan, công việc bằng công cu Azure Boards Day là một trong những công cụ thuộc Azure

DevOps, trong đó cũng có công cụ Azure Pipelines là công cụ CI/CD chính mà nhóm tác sử dụng Để trò chuyện cũng như nhận các task, alert về ứng dụng, hệ thống khi gặp trục trặc thì nhóm tác giả quyết định sử dụng Microsoft Teams Đây là ứng dụng trò chuyện có nhiều tính năng, trong đó nó hỗ trợ việc webhook giúp cho các công cụ monitor như Grafana có thể gửi cho các alert khi các metric giám sát hệ thống bat thường.

Giai đoạn build và test: nhóm tác giả khuyến khích bộ phận phát triển sử dụng Visual Studio Code dé thực hiện code ứng dụng vì nó có hỗ trợ nhiều extension cho việc code ứng dụng Flask Sử dung git dé lưu trữ mã nguồn và GitHub dé lưu trữ mã nguồn ở remote Vì đây là ứng dung web Python Flask đơn giản nên việc test chiếm phần khá nhỏ, nhóm tác giả khuyến khích sử dụng framework test Pytest, là một framework test python đơn giản, giúp cho việc test tính năng nhanh, hiệu quả.

Khi push code lên GitHub, Azure Pipelines sẽ tự động trigger sự kiện commit hoặc sự kiện merge, nhờ file azure-pipeline mà nhóm tác giả đã viết Azure sẽ tự động thực hiện build các Docker Image, nếu giai đoạn này gặp lỗi thì sẽ thông báo thất bại và sẽ không triển khai lên AKS Cụ thể nội dung pipelines thì sẽ được nói trong phan Pipelines ở Chương Triển khai — Thực nghiệm.

Sau khi thực hiện việc build các image, pipeline sẽ tự động release các phiên bản Image lên Registry, lưu trữ nó tại dây theo từng phiên bản Khi đến giai đoạn triển khai các pod lên AKS, thì hệ thống sẽ tự động kéo các image được lưu trữ này về và tạo các pod mới từ image này Sau đó khi ứng dụng đã chạy thành công trên hệ thống AKS thì việc giám sát nó sẽ do Prometheus và Grafana mà em đã cài quản lí và hiện lên giao diện web Khi một trong các metric được giám sát có sự tăng hay giảm bat thường và vượt qua mức quy định thì Grafana sẽ gửi 1 thông báo alert về cho team thông qua Microsoft Teams, việc này giúp cho giám sát, quản lí ứng dụng tốt hơn Cụ thể việc triển khai, tạo các pod từ image sẽ được mô tả trong phần

3.4 Phương pháp kiểm tra và cấu hình hệ thống Kubernetes

Phương pháp này được dùng cho tat cả hệ thống Kubernetes Dé quá trình cấu hình tự động bằng Ansible được thành công, cần đảm bảo cho các node trong hệ thống có thể sử dụng giao thức SSH dé kết nối tới nó.

Quá trình tự động hoá bao gồm một số bước như sau:

-_ Triển khai hệ thống gồm Control Server và các máy Remote Host, các máy này chính là các node trong Kubernetes cluster Và đảm bảo trên máy

Control Server đã cài đặt sẵn công cụ Ansible.

- Khởi tao thông tin các Remote Host thông qua file Inventory.

- Dựa vào tài liệu về chuẩn CIS Benchmark, xây dựng các Playbook phù hợp với hệ thống Kubernetes.

- _ Tiến hành kiểm tra và cấu hình một cách tự động: e _ Khi một nhiệm vụ kiểm tra hoặc cấu hình tự động hoá được kích hoạt,

Ansible thiết lập một kết nối SSH đến các Remote Host để gửi và triển khai Package gồm các Inventory, Playbook, Module. e Trên các máy được chọn, các tác vụ của package đó sẽ được thực thi.

Sau khi kết thúc, Ansible sẽ nhận kết quả trả về với định dạng JSON chứa kết quả thực thi từ các máy này. e_ Kết thúc quá trình tự động hoá, các Package đã được gửi lên các máy này sẽ bị xóa.

3.4.1 Phương pháp kết nối SSH vào các node AKS

3.4.1.1 Trường hợp kết nối SSH tới private node

AKS cluster oe agentnode1 agentnode2

Pod ọ tubect! exec- > aks-ssh-session ssh và

Hình 3.8: Mô hình SSH vào AKS node

B 2.2 Phương pháp thực hiện với mô hình sử dụng AKS 4 Xõy dựng Playbook kiểm tra cấu hỡnh . - c -. c 3ỉ 4.1 Mục đích 4.2 Cấu trúc các file playbook .: c:22cvvr+eevvvvrrerrrsrrrrrr 39 4 Định dạng của file output HTML 2-5-5 2 =<++=s2 43 4.4 Phương pháp thực hiện kiểm tra cầu hình với CIS Benchmark

Nhóm đã nghiên cứu lí do, cách các thành phần trong Kubernetes hoạt động và chỉnh sửa, áp dụng các câu lệnh được CIS Benchmark quy định để phù hợp với hệ thống.

3.4.4.1 Cấu trúc một tiêu chuẩn kiểm tra cấu hình theo CIS

Một tiêu chuẩn kiểm tra hoặc cấu hình theo CIS benchmark bao gồm một số phần như sau [13]:

- Profile Applicability: bao gồm thông tin về level của cau hình và node nào sẽ được cấu hình.

- Description: mô tả về tiêu chuẩn đó.

- Rationale: giải thích lí do tại sao nên câu hình theo tiêu chuẩn này.

- Impact: ảnh hưởng của tiêu chuẩn đến hệ thống khi thực hiện kiểm tra hoặc cầu hình.

- Audit: cách kiểm tra xem hệ thống có đạt được tiêu chuẩn được nêu ra chưa.

- Remediation: cách dé cấu hình lại nếu node được kiểm tra không đạt chuẩn.

- Default Value: giá trị được thiết lập sẵn của đối tượng được kiểm tra.

Profile Applicability: e Level 1 - Master Node

Ensure that the API server pod specification file ownership is set to root: root.

The API server pod specification file controls various parameters that set the behavior of the API server You should set its file ownership to maintain the integrity of the file.

The file should be owned by root: root.

Run the below command (based on the file location on your system) on the Control

Plane node For example, stat -c %U:%G /etc/kubernetes/manifests/kube-apiserver.yaml

Verify that the ownership is set to root: root.

Run the below command (based on the file location on your system) on the Control

Plane node For example, chown root:root /etc/kubernetes/manifests/kube-apiserver.yaml

By default, the kube-apiserver.yam1 file ownership is set to root: root.

Hình 3.17: Tiêu chuẩn cấu hình 1.1.2 của CIS benchmark

Dựa vào tiêu chuẩn được đưa ra, nhóm sẽ thực hiện viết các Playbook với các câu lệnh phù hợp, tuy nhiên nhóm sẽ sửa chữa dé nó phù hợp với hệ thống mình đang áp dụng trong đề tài khóa luận.

~ name: 1.1.2 Ensure that the API server pod specification file ownership is set to root:root block:

~ ansible builtin.shell: stat -c %U:%G /etc/kubernetes/manifestskube-apiserver.yaml register: filestat ignore_errors: yes changed_when: false

~ name: Add passed task to list set_fact: section1_tasks: '{{ section1_tasks + [{ "task_number""1.1.2","task_description":"Ensure that the API server pod specification file

‘ownership is set to root:root”,"task_status":"PASSED’, "configuration" filestat.stdout,"script"."" }]}}' when: filestat.stdout [oot:root'

- name: Add failed task to list set_fact: section1_tasks: '{{ section1_tasks + [{ "task_number":"1.1.2","task_description":"Ensure that the API server pod specification file ownership is set to root:root”,"task_status"."FAILED", "configuration" filestat.stdout,"script"."Script here” }] }}|

Hình 3.18: Task thực hiện kiểm tra tiêu chuẩn 1.1.2

Trong task này, nhóm sẽ sử dụng module là shell để thực hiện câu lệnh stat, câu lệnh này với option là -c %U:%G sẽ lấy thông tin của file xem nó thuộc user nao cũng như group nào Nếu output của câu lệnh là “root:root” thi task này sẽ được đánh dau là PASSED, sau đó lưu vào một mảng bao gồm thông tin kiểm tra tiêu chuẩn của nhiều task khác nhau Mang nay sẽ được dùng để ghi ra file output

3.4.4.2 Các tiêu chuẩn được áp dung để kiểm tra cấu hình trong đề tài

(a) Kubernetes/Minikube Đối với đề tài, nhóm đã chọn lọc 90 trên 124 nội dung các tiêu chuẩn kiểm tra cầu hình cho Kubernetes để tiến hành xây dựng các Playbook Những nội dung mà nhóm lựa chọn là những nội dung có thẻ thực hiện tự động thông qua Ansible playbook Còn những nội dung yêu cầu cần phải câu hình thủ công hoặc cần phải tùy thuộc vào nhu cầu triển khai ứng dụng thì nhóm không áp dụng vào phạm vi đề tài này Chỉ tiết những nội dung không áp dụng, cần cấu hình thủ công nằm ở phụ lục Các Playbook sẽ được chia thành 2 loại là Playbook ding dé kiểm tra cấu hình và Playbook dùng dé tự động cấu hình lai các tiêu chuẩn mà Playbook kiểm tra cấu hình đã chỉ ra là chưa đạt Các nội dung mà nhóm lựa chọn để viết playbook kiểm tra và cấu hình được ghi chỉ tiết ở phụ lục.

Section Số nội dung Số nội dung Số play sử Số play sử theo chuẩn tiêu chuẩn dụng trong dụng trong

CIS được áp dụng playbook playbook

Bang 3.1: Số playbook được sử dụng đối với Minikube

(b) Azure Kubernetes Service Đối với đề tài, nhóm đã chọn lọc 30 trên 56 nội dung các tiêu chuẩn kiểm tra cấu hình cho AKS đề tiến hành xây dựng các Playbook Tương tự với phần Kubernetes/Minikube, những nội dung nhóm lựa chọn cho phần AKS là những nội dung có thé tự động thực hiện bằng Ansible Những nội dung không áp dung là những nội dung cần cấu hình thủ công, cầu hình thông qua Azure Portal, cũng như cần thêm Azure Monitor, Azure Active Directory Chỉ tiết những nội dung không áp dụng, cần

4 cấu hình thủ công nằm ở phụ lục Các Playbook sẽ được chia thành 2 loại là Playbook ding đề kiểm tra cấu hình và Playbook dùng dé tự động cấu hình lại các tiêu chuẩn mà Playbook kiểm tra cấu hình đã chi ra là chưa đạt Các nội dung mà nhóm lựa chọn đề viết playbook kiểm tra và cầu hình được ghi chỉ tiết ở phụ lục.

Section Số nội dung Số nội dung Số play sử Số play sử theo chuẩn tiêu chuẩn dụng trong dụng trong

CIS được áp dụng playbook playbook

Bảng 3.2: Số playbook được sử dụng đối với AKS

Chương 4 TRIEN KHAI - THỰC NGHIEM

4.1 Triển khai ứng dụng Mieroservices

4.1.1 Triển khai ứng dụng lên Kubernetes/Minikube

Trước tiên, để triển khai ứng dụng lên Kubernetes thì nhóm tác giả sẽ build các image tương ứng với các ứng dụng riêng biệt và push nó lên Container Registry.

Khi lưu trữ các image trên Registry thì khi nhóm chạy ứng dụng lên K8S, nó sẽ không cần build lại các image nữa.

Dé triển khai các ứng dụng va service lên K8S nhóm tác giả đã viết file manifest deployment như sau:

Hinh 4.1: File manifest deployment trién khai service frontend

Nội dung file manifest trên là khởi tạo pod cho ứng dụng frontend và chạy service tương ứng của pod đó Tương tự như deployment cho frontend, các file deployment khác cho các service cũng như vậy, tuy nhiên cần phải thay đổi các port tương ứng với từng pod.

Với database dé giảm chi phí và đảm bảo hiệu suất vẫn được tối ưu, thay vì chạy 3 pod database như chạy 3 container đã đề cập ở phần trước, nhóm sẽ gộp lại thành 1 pod database trong đó có 3 database khác nhau ứng với mỗi service Về nội dụng file manifest deployment cho pod database sử dụng MySQL như sau:

1 # this pvc will be used to store downloaded init.sql file

29 # this pvc will be used to store mysql database

Hinh 4.2: File manifest trién khai Volume cho MySQL

Nhóm tác giả đã tạo volume cho database, việc tạo volume này giúp cho việc nếu pod database có bị ngắt hoặc khởi động lại thì các file lưu trữ database vẫn được lưu lại.

Phần deployment nhóm đã thực hiện ở phần đồ án chuyên ngành nên không trình bày chi tiết ở khóa luận Nhìn chung, nội dung của phần deployment là khởi tạo container MySQL bằng image mysqI:8 là phiên bản 8 của MySQL mà nhóm tác giả lựa chọn Phần deployment cũng liên kết volume tạo ở trước vào ứng dụng, đặc biệt nhóm tác giả sử dung | file sql được trích xuất ra khi chạy ở local, vì khi triển khai lên Kubernetes thì đây là môi trường production nên cần đảm bảo việc không khởi tạo database ban dau tại đây Do đó, nhóm tác giả đã khởi tạo database từ trước và khi triển khai ứng dụng, pod database chi cần import các bảng, dữ liệu đã được trích xuất vào và sau đó các đữ liệu đã sẵn sàng.

Cuối cùng, nhóm tác giả tạo service cho pod database để các pod khác có thể kết nói được.

Dé expose port tương ứng với Frontend-app nhóm tác gia sử dụng Nodeport trong service Frontend-app, điều này giúp cho người dùng có thé truy cập thông qua địa chỉ IP của node và port được chỉ định.

Dưới đây là mô hình triển khai ứng dụng lên Kubernetes Mô tả việc sử dụng Nodeport của service Frontend-app dé điều khiển hướng truy cập tới từng service, và số lượng cụ thể các pod được triển khai:

Hình 4.3: Mô hình triển khai ứng dụng trên Minikube 4.1.2 Triển khai ứng dụng lên Azure Kubernetes Service

4.1.2.1 Mô hình triển khai lên AKS

Cụ thể mô hình triển khai ứng dụng lên AKS như sau:

"4 đa wie oe cm conaler wot

Hình 4.4: Mô hình triển khai ứng dụng trên AKS