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 sử dụng Cilium

Việc sử dụng những giải pháp để bảo đảm các thành phần trong hệ thống an toàn và bảo mật đồng thời cũng quan sát được quá trình hoạt động của chúng là một quá trình cần được nghiên cứu v

BACH VAN XUAN THONG - 20521978

KHOA LUAN TOT NGHIEP

TRIEN KHAI GIAI PHAP BAO MAT CHO HE

THONG KUBERNETES SU DUNG CILIUM

IMPLEMENTING SECURITY SOLUTIONS FOR KUBERNETES

USING THE CILIUM

CU NHAN NGANH AN TOAN THONG TIN

GIANG VIEN HUGNG DAN:

ThS Tran Thi Dung

TP.H6 Chi Minh - 2024

LỜI CẢM ƠN

Trong quá trình học tập tại trường Đại học Công nghệ Thông tin, Đại học

Quốc gia Thành phố Hồ Chí Minh, em đã nhận được sự quan tâm, yêu mến từ quý thầy cô, bạn bè xung quanh và Ban Giám Hiệu nhà trường Đây là nguồn

động lực quý giá để em nỗ lực, cỗ gắng trau đồi và rèn luyện kiến thức để hoàn

thành tốt Khóa luận tốt nghiệp.

Đặc biết em xin gửi lời cảm ơn chân thành và sâu sắc đến Ths.Trần Thị Dung

~ Phó trưởng khoa Mạng máy tính và Truyền thông đã hướng dẫn em trong quá trình thực hiện Khóa luận tốt nghiệp Cô đã gợi ý những hướng nghiên cứu, mục tiêu, giải đáp những thắc mắc và đưa ra hướng giải quyết cho những khó khăn mà em gặp phải trong quá trình thực hiện Khóa luận tốt nghiệp.

Em cũng xin gửi lời cam ơn đến quý thầy cô khoa Mạng máy tính và Truyền

thông và Văn phòng các Chương trình Đặc biệt đã tạo điều kiện để em thực

hiện Khóa luận tốt nghiệp này Cảm ơn quý thầy cô trong hội đồng phản biện

đã dành thời gian để góp ý và đưa ra nhận xét, góp ý về đề tài này của em

Cuối cùng, em xin kính chúc sức khỏe đến tất cả các thầy cô và Ban Giám Hiệu tại trường Dại học Công nghệ Thông tin thật nhiều sức khỏe, có nhiều thành công trong cuộc sống Chúc trường Đại học Công nghệ Thông tin ngày

càng phát triển xứng đáng là nơi đào tạo nguồn nhân lực Công nghệ thông tin

tốt của cả nước.

Em xin chân thành cam on!

Bạch Văn Xuân Thông

1

MỤC LỤC

THONG TIN HỘI DONG CHAM KHÓA LUẬN TOT NGHIỆP i

LOICAMON 0000000002 eee eee ii

DANH MỤC CÁC KÝ HIỆU, CAC CHU VIET TAT vi

DANH MỤC CÁC HINH VE vii

DANH MUC CAC BANG BIBU ix

MỞ ĐẦU ge |

CHƯƠNG 1 TONG QUAN 2 11 Giới thiệu vấn đề Q2 v2 2 12 Mục tiêu 4a ee “ X4E§.Í/j .⁄ 3

1.3 Phạm vi nghiên ctu 2 0.2 00.0000 0 00000 3 1.4 Đối tượng nghiên cttu 2.2 ee ee 3 1.5 Phuong pháp thuc hién 00 4

1.6 Kết quả mong ddi 2 2 ee 4 1.7 Cau trúc Khóa luận tốt nghiệp 4

CHƯƠNG 2 CƠ SỞ LÝ THUYET 6 2.1 Kubernefes 0000000000002 ee 6 211 Giới thiệu về Kubernetes 6

2.1.2 Kiến trúc của Kubernetes 7

2.2 Minikube 0000000000022 eee 9 2.3 Mô hình Microservice 2.2.0.0 00000000 2 eee 10 2.4 Ung dung web dựa trên kiến trúc Microservices 11

2.5 WireGuard cà và va 12 2.6 Secure Production Identity Framework for Everyone - SPIFEFE 13

11

2/7 Giao tiếp trong Kubernetes 0 002.00050 14

2.7.1 Giao tiếp giữa các container trong cùng một pod 14

2.7.2 Giao tiếp giữa các pod ee 15 2.8 Các phương pháp bảo mật trong Kubernetes 17

2.8.1 Chính sách mạng - Network Policy 17

2.8.2 Bảo mật cho Pod 0 000000000 18 2.8.3 Bảo mật cho container ố 18 2.9 9i“ Ha a < 18 2.9.1 eBPEF 000000000 18 2.9.2 Giới thiệu về Cilium 19

2.9.3 Kiến trúc của Ciium 19

2.9.4 Hoạt động của Cilium 21

2.9.5 Các giải pháp bảo mật của Cilium 22

2.9.6 Hubble‹ ‹ Ặ ee ee ee eee 23 2.10 Chính sách mang của Cilium 24

CHƯƠNG 3 PHƯƠNG PHÁP THỰC HIỆN 28 3.1 Phương pháp triển khai hệ thống Kubernetes 28

3.2 Ứng dụng Microservice và phương pháp triển khai lên hệ thống Kubernetes vo 28 3.2.1 Ứng dụng dựa trên kiến trúc Mieroservice 28

3.2.2 Triển khai ứng dụng Mieroservice lên hệ thống Kubernetes 31 3.3 Phương pháp triển khai Cilium va Hubble cho hệ thống Kubernetes 32 3.3.1 Cilium 0.002000 00000000000 ee 33 3.3.2 Hubble va 34 3.3.3 Phương phap quan sát hoạt động của Kubernetes 34

3.4 Phương pháp bao mat cho hệ thống Kubernetes bằng Cilium 35

3.4.1 Xây dựng chính sách mang cho hệ thống Kubernetes 35

3.4.2 Áp dụng chính sách mang có sử dụng Cilium 37

1V

3.4.3 Phương pháp hạn chế kết nối ra bên ngoài của chính sách

mạng dựa vào DNS Quy 40

3.4.4 Phương pháp mã hóa trong suốt 42

3.45 Phương pháp xác thực lẫn nhau 43

CHƯƠNG 4 TRIEN KHAI VA THỰC NGHIỆM 46

4.2_ Triển khai Cilium và Hubble lên hệ thống Kubernetes 49

4.3 Thực hiện kiểm tra chính sách mạng của Cilium đối với hệ thống

4.3.1 Các chính sách 002000002 eee 52

4.3.2 Trién khaichinh sách 52

4.4 Thực hiện kiểm tra phương pháp mã hóa trong suốt của Cilium

đối với lưu lượng mạng trong hệ thống Kubernetes 60

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIET TAT

K8s: Kubernetes

API: Application Programming Interface

AWS: Amazon Web Services

GCP: Google Cloud Platform

YAML: YAML Ain’t Markup Language

CLI: Command Line Interface

SPIFFE: Secure Production Identity Framework for Everyone

PSP: Pod Security Policy

NP: Network Policy

CNP: Cilium Network Policy

eBPF: Extended Berkeley Packet Filter

CNI: Container Networking Interface

GUI: Graphical User Interface

UI: User Interface

vi

DANH MỤC CÁC HÌNH VE

8figure.caption.8

Hinh 2.2

Hinh 2.3

Hinh 2.4

Hinh 2.5

Hinh 3.1

Hinh 3.2

Hinh 3.3

Hinh 3.4

Hinh 3.5

Hinh 3.6

Hinh 3.7

Hinh 3.8

Hinh 3.9

Hinh 3.10

Mô hình Kubernetes gồm 2 Node khác nhau

Kiến trúc của Cilium Nguồn: cilium.io

Giao diện của Hubble

Script gan nhãn cho các node trong cum Kubernetes Kiến trúc của ứng dung Microservices

Dockerfile của dịch vụ Frontend

Cấu trúc của một file YAML

Menu lựa chon namespace trên Hubble UI

File YAML định nghĩa một Network Policy .

File YAML định nghĩa Cilium Network Policy

File YAML định nghĩa Cilium Network Policy trên tầng 7 File YAML định nghĩa chính sách mang dựa vào DNS File YAML định nghĩa chính sách mạng xác thực lẫn nhau giữa cấc DO 0 ng ng gà va Hình 4.1 Mô hình triển khai ứng dụng trên Minikube

29 30 31 32 35 36 38 39 41 AT Hình 4.2 Một phan của file manifest deployment để triển khai front-end 48 Hinh 4.3 Hinh 4.4 Hinh 4.5 Hinh 4.6 Hinh 4.7 Cac pod trong ứng dung Microservices

Giao diện trang chủ của ứng dung

Giao diện đăng nhập của ứng dụng

Giao diện chi tiết sản phẩm của ứng dung

Trạng thái của Cllium và HUbble sau khi đã cai đặt thành

vil

48

Hình 4.8 Các pod của Cilium và Hubble trên hệ thống 51

Hình 4.9 Loc ra các giao tiếp từ pod front-end tới các pod khác 51

Hình 4.10 Chính sách mang (1) giới hạn truy cập tới các pod 52

Hình 4.11 Chính sách mạng áp dụng trên tầng 7 53

Hình 4.12 Chính sách mạng ngăn chặn các kết nối ra bên ngoài cụm Kubernetes dựa trên DNS Ố ee 53 Hình 4.13 Ap dụng các chính sách cho cum Kubernetes 53

Hình 4.14 Kiểm tra trạng thái của các chính sách mang 54

Hình 4.15 Luồng kết nối với chính sách mang (1) 54

Hình 4.16 Kiểm tra chính sách mạng (1) với lệnh ping 55

Hình 4.17 Quan sát trạng thái các kết nối thông qua Hubble 55

Hình 4.18 Luong kết nối với chính sách mạng (2) - 56

Hình 4.19 Luồng kết nối với chính sách mang (2) đã sửa đổi 56

Hình 4.20 Chính sách mạng (2) khi chưa sửa đổi 57

Hình 4.21 Chính sách mạng (2) khi đã sửa đổi 57

Hình 4.22 Sau khi sửa đổi chính sách mạng (2) 58

Hình 4.23 API GET /login đã bị drop - 58

Hình 4.24 Luong kết nối với chính sách mang (3) - 59

Hình 4.25 Kết nối khi chưa áp dụng chính sách mang (3) 59

Hình 4.26 Kết nối khi đã áp dụng chính sách mạng (3) 60

Hình 4.27 Tạo shell bash trong pod cillum agent 61

Hình 4.28 Kiểm tra trạng thái của WireGuard 61

Hình 4.29 Sử dụng công cu tcpdump để bắt các gói tin 61

Hình 4.30 Dùng lệnh ping để gửi gói ICMP từ pod front-end tới pod carts 62 Hình 4.31 Các gói tin được bắt bằng tepdump 62

Hình 4.32 Các pod và service của SPIRH 63

Hình 4.33 Trang thái của SPIRE server 63

vill

Hình 4.34 Xác định Cilium agent va operator đã có các Identity trên

SPIRE serVer 2 64

Hình 4.35 ID của các pod trong Mieroservices 64

Hình 4.36 Kiểm tra 2 pod trên SPIRE server 65

Hình 4.37 Kết nối bi drop do yêu cầu xác thuc - 65

Hình 4.38 Kết nối đã được cho phép 66

Hình 4.39 Logs của pod cilium agenis 66

Hình 4.40 Không tim thay Identity của pod carts trên SPIRE server 66 Hình 4.41 File YAML định nghĩa chính sách mang yêu cầu xác thực kếtnối we 67 Hình 4.42 Không thể thực hiện lệnh ping từ pod front-end tới pod carts 67 Hình 4.43 Kết nối từ pod front-end tới pod carts đã bidrop 68

1X

DANH MỤC CÁC BANG BIEU

Bảng 2.1 Bảng so sánh chính sách mạng của Kubernetes và Cilium 27

Bảng 4.1 Chỉ tiết các thành phần trong mô hình 47

TÓM TẮT ĐỀ TÀI

Tên đề tài: Triển khai giải pháp bảo mật cho hệ thống Kubernetes

sử dụng Cilium.

Trong thời đại mà hệ thống Kubernetes và kiến trúc Microservices ngày càng

được sử dụng rộng rãi và phổ biến thì việc đảm bảo cho hệ thống này hoạt động

một cách an toàn và bảo mật cũng là một vấn đề cần quan tâm Việc sử dụng

những giải pháp để bảo đảm các thành phần trong hệ thống an toàn và bảo

mật đồng thời cũng quan sát được quá trình hoạt động của chúng là một quá

trình cần được nghiên cứu và tìm hiểu kỹ càng Trong đề tài này, tôi đã quyết

định nghiên cứu, triển khai và sử dụng giải pháp bảo mật Cilium cho hệ thống

Kubernetes Đây là một giải pháp mã nguồn mở có những cải tiến về bảo mật

so với những gì mà một hệ thống Kubernetes đem lại, bên cạnh đó khả năng

tích hợp với các công cụ, giải pháp khác cũng sẽ đảm bảo khả năng hoạt động

mạnh mẽ của Cilium trên hệ thống Kubernetes.

Trong đề tài này, tôi sẽ thực hiện xây dựng một ứng dụng web sử dụng kiến

trúc Microservice trên hệ thống Kubernetes, đồng thời cũng sẽ triển khai giảipháp bảo mật Cilium lên trên hệ thống Kubernetes này để thực hiện quá trình

quan sát, quản lý và bảo mật cho hệ thống Nhờ vào Cilium, các thành phan trong ứng dụng web sẽ hoạt động một cách an toàn, tránh được những sự cố an toàn thông tin không mong muốn Tôi cũng đã thực hiện quan sát hoạt động

của hệ thống để phân tích các vấn đề liên quan

Sau quá trình nghiên cứu và thực hiện đề tài, tôi đã có nhiều kiến thức hơn

về hệ thống Kubernetes, kiến trúc Microservices và những van đề bảo mat, giao

tiếp liên quan đến chúng Đồng thời so sánh được ưu nhược điểm của Cilium

so với các giải pháp bảo mật khác, qua đó rút ra những kết luận để có nhữngnghiên cứu và hướng phát triển sau này

CHƯƠNG 1 TONG QUAN

Chương này giới thiệu về van đề va các nghiên cứu liên quan Đồng thời, trong chương này tôi cũng trình bày phạm vi và cấu trúc của Khóa luận.

1.1 Giới thiệu vẫn đề

Với sự phát triển không ngừng và mạnh mẽ của các nền tảng ứng dụng, nhucầu về các công nghệ hỗ trợ phát triển ứng dụng quy mô lớn và tốc độ cao ngàycàng tăng để đáp ứng yêu cầu của người dùng Docker là một trong những công

nghệ tiên tiến, cho phép container hóa các ứng dụng trong môi trường san xuất Tuy nhiên, việc quản lý một hệ thống sử dụng container chỉ với Docker gặp phải nhiều khó khăn, bao gồm:

- Quản lý nhiều host chứa container

- Cập nhật ứng dụng

- Mở rộng hoặc thu hẹp hệ thống

- Tự động khởi động lại container khi có sự cố

- Cân bằng tải

- Giám sát giao tiếp trong hệ thống

- Quản lý dữ liệu, ghi log và quy trình làm việc

Để khắc phục những khó khăn này, các giải pháp mới đã được phát triển,

trong đó Kubernetes (K8s) là một bước tiến vượt bậc, thay đổi cách thức pháttriển và triển khai ứng dụng vốn đã lỗi thời và kém hiệu quả Kubernetes là một

nền tảng mã nguồn mở, cung cấp khả năng tự động hóa, mở rộng/thu hẹp linh

hoạt và dé dàng cấu hình, giúp việc quan lý, xây dựng và phát triển ứng dụng

container hóa trở nên đơn giản hơn Kubernetes giải quyết được nhiều hạn chế

mà Docker gặp phải, và còn mang lại nhiều ưu điểm khác đang được phát triển

thêm.

Tuy nhiên, việc xây dựng một hệ thống Kubernetes an toàn và hiệu quả là

một thách thức lớn Để đảm bảo an toàn và nâng cao hiệu quả cho hệ thống,

cần có những giải pháp bảo mật bổ sung và các cải tiến liên tục.

1.2 Mục tiêu

Trong Khóa luận này, tôi hướng tới các mục tiêu như sau:

- Nâng cao tính bảo mật cho hệ thống Kubernetes có sử dụng kiến trúc Microservice một cách hiệu quả, dễ dàng tiếp cận với người dùng, không yêu cầu kiến thức bảo mật cao

- Cải tiến những tính năng mà Kubernetes mang lại, giúp quá trình quản lý

an toàn và hiệu quả

1.4 Đối tượng nghiên cứu

Các đối tượng mà tôi sẽ thực hiện nghiên cứu trong Khóa luận này là:

- Ứng dụng web sử dụng kiến trúc Mieroservice

- Nền tảng Kubernetes thông qua công cụ Minikube

- Các giải pháp bảo mật của Cilium

- Tim hiểu và áp dụng các giải pháp của Cilium nhằm đảm bảo tinh an toàn

và hiệu quả cho hệ thống

1.6 Kết quả mong đợi

Sau quá trình thực hiện nghiên cứu và thực nghiệm, tôi mong sẽ thu được các

kết quả như sau: - Hiểu được cách các thành phần trong môi trường Kubernetes

và cách chúng giao tiếp, kết nối với nhau

- Xây dung được ứng dụng dựa trên kiến trúc Microservice trên môi trường

Kubernetes

- Ap dụng được các giải pháp bảo mật mà Cilium đem lai cho hệ thống

- Nâng cao kiến thức cho bản thân và giới thiệu cho người dùng các phương

pháp bảo mật trên môi trường Kubernetes để đảm bảo an toàn cho hệ thống

trước những thách thức an toàn thông tin

1.7 Cau trúc Khóa luận tốt nghiệp

Toi xin trình bày nội dung của Luận án theo cấu trúc như sau:

- Chương 1: Giới thiệu tổng quan về đề tài của Khóa luận

- Chương 2: Trình bày cơ sở lý thuyết và kiến thức nền tang liên quan đến

đề tài.

- Chương 3: Trình bay các phương pháp thực hiện.

- Chương 4: Trình bày thực nghiệm và đánh giá.

- Chương 5: Kết luận và hướng phát triển của đề tài

CHƯƠNG 2 CƠ SỞ LÝ THUYET

Chương này trình bày cơ sở lý thuyết của nghiên cứu về Kubernetes, croservices, Cilium và các lý thuyết liên quan khác

Mi-2.1 Kubernetes

2.1.1 Giới thiệu vé Kubernetes

Kubernetes, thường được gọi tắt là k8s, là một phần mềm mã nguồn mở có khả năng tự động hóa quy trình triển khai, quản lý và điều phối các ứng dụng

chạy trên container Được thiết kế để hỗ trợ các ứng dụng quy mô lớn và phức

tạp, Kubernetes giúp đơn giản hóa việc quản lý các tiến trình đa dạng trong

một môi trường phân tán.

Một trong những điểm mạnh của Kubernetes là khả năng cho phép các nhàphát triển triển khai và quản lý ứng dụng mà không cần phải quan tâm đến các

chi tiết cơ sở hạ tầng phức tạp bên dưới Nó cung cấp một framework mạnh mẽ

để tự động hóa các quy trình triển khai, mở rộng quy mô và quản lý ứng dụngcontainer trong các cluster máy chủ Với Kubernetes, người dùng có thể dễ dàngtriển khai và quản lý ứng dụng trên nhiều loại môi trường khác nhau, bao gồm

cả hạ tầng phần cứng truyền thống, các trung tâm dit liệu, và các dịch vụ đám

mây công cộng như Amazon Web Services (AWS), Microsoft Azure va Google Cloud Platform (GCP).

Kubernetes cung cấp một loạt các tính năng quan trọng giúp tối ưu hóa và đơn giản hóa quá trình quản lý container Đầu tiên, tính năng tự động cân bằng tải (load balancing) giúp phân phối tải công việc một cách hiệu quả giữa các container, đảm bảo hiệu suất hệ thống được tối ưu Thứ hai, khả năng tự phục

hồi (self-healing) cho phép Kubernetes tự động khởi động lại các container khi

chúng gặp sự cố, đảm bảo tính liên tục của dịch vụ Ngoài ra, Kubernetes cũng

hỗ trợ việc tự động thay đổi quy mô (scaling), cho phép tăng hoặc giảm số

lượng container dựa trên nhu cầu thực tế, và khả năng cập nhật tuần tự (rolling

updates) giúp triển khai các bản cập nhật mà không làm gián đoạn dịch vụ

Kubernetes cung cấp các công cụ mạnh mẽ dé quản lý hạ tầng container, bao

gồm hệ thống mang (networking), lưu trữ (storage), bảo mat (security) và ghi log (logging) Diều này giúp người dùng dễ dàng giám sát và điều chỉnh hoạt

động của các ứng dụng theo thời gian thực.

Một điểm đáng chú ý là Kubernetes không bị giới hạn ở một loại công nghệcontainer cụ thể Nó hỗ trợ nhiều công nghệ container khác nhau như Docker,

containerd và nhiều công nghệ khác Sự linh hoạt này giúp Kubernetes dễ dàng

tích hợp vào nhiều hệ thống hiện có và hỗ trợ đa dạng các yêu cầu triển khai

Kubernetes có một hệ sinh thái phong phú và dang phát triển mạnh mẽ N6bao gồm nhiều công cụ và tiện ích bổ sung mở rộng khả năng của Kubernetes

Ví dụ, Istio là một công cụ quản lý service mesh giúp quản lý giao tiếp giữa các dịch vụ vi mô (microservices), trong khi Prometheus là một hệ thống giám sát mạnh mẽ cho phép theo dõi và cảnh báo dựa trên các chỉ số hệ thống và ứng

dụng.

Kubernetes áp dụng cách tiếp cận khai báo (declarative), trong đó người dùng

mô tả trạng thái mong muốn của ứng dụng và hệ thống trong các tệp cấu hình

YAML Ain’t Markup Language (YAML) Kubernetes sau đó sẽ sử dụng những

khai báo này để tự động triển khai và quản lý hệ thống theo yêu cầu Điều nàygiúp giảm thiểu công việc thủ công và đảm bảo rằng hệ thống luôn ở trạng thái

mong muốn, ngay cả khi có sự cố xảy ra.

2.1.2 Kiến trúc của Kubernetes

Kiến trúc của Kubernetes bao gồm nhiều thành phần hoạt động cùng nhau với nhiệm vụ quản lý các ứng dụng container Dưới đây là các thành phần chính

ĩ

của Kubernetes

Hình 2.1: Kiến trúc của Kubernetes Í

- Master Node: Là phần chịu trách nhiệm điều khiển toàn bộ hoạt động của

cụm Kubernetes

- Worker Node: Dây là nơi các ứng dụng container được triển khai Nó chịu

trách nhiệm chạy các ứng dụng container và cung cấp các tài nguyên cần thiết

như CPU, bộ nhớ, và mạng.

- etcd: Day là một cơ sở dữ liệu sử dụng để lưu giữ trạng thái và các tài

nguyên của cluster.

- API server: Thành phần chính để giao tiếp với các thành phần khác của

Kubernetes.

- Controller manager: Bao gồm nhiều controller, mỗi container thực hiện chức

năng cụ thể cho từng tài nguyên trong Kubernetes, chang hạn như tao pod hoặc

tạo deployment.

- Scheduler (kube-scheduler): Chạy trên node master, kube-scheduler có nhiệm

vụ sử dụng thông tin về tài nguyên của các thành phần trong hệ thống để triển

khai và chạy các ứng dụng trên các node thích hợp, đảm bảo tính ổn định của

Ihttps://bizflycloud.vn/tin-tuc/tong-quan-ve-kien-truc-k8s-20210306114153127.

htm

hệ thống.

- kubelet: Day là dịch vụ luôn chạy trên tất cả các worker node, với nhiệm

vụ quản lý các container Nó giám sát, chạy hoặc dừng các container và duy

trì các ứng dụng chạy trên node để đảm bảo sự ổn định của container Ngoài

ra, kubelet cũng đảm bảo việc giao tiếp với node master để chắc chắn rằng các

container hoạt động như mong đợi.

- Kubernetes Proxy (kube-proxy): Kubernetes proxy quản lý lưu lượng mạng

giữa các dich vụ khác nhau đang chạy trên cluster Nó định tuyến lưu lượng

đến các dịch vụ thích hợp và thực hiện cân bằng tải để đảm bảo lưu lượng được

phân phối đồng đều trên các node hiện có.

- Pod: Là đơn vị cơ bản nhất để triển khai và chạy một ứng dụng, được tạo và

quản lý bởi Kubernetes Pod gộp và chạy một hoặc nhiều container cùng nhau

trên cùng một worker node, chia sẻ tài nguyên chung.

2.2 Minikube

(9) minikube

Hinh 2.2: Minikube

Trong Khóa luận này, tôi đã sử dụng công cu Minikube dé xây dựng một cum

Kubernetes đơn giản bao gồm một master node và một worker node nhằm thực

hiện triển khai ứng dụng Microservice lên đấy Minikube có cho Linux, macOS,

và Windows Minikube CLI, một bộ công cụ dòng lệnh, cung cấp khả năng điều

khiển cluster cho người sử dụng, như chạy, dừng chạy, xem trang thái, hoặc xóa

một thành phần trong cluster.

2.3 M6 hình Microservice

Kiến trúc Microservice là một cách tiếp cận trong việc xây dựng các ứng dụng bằng cách chia nhỏ các dịch vụ thành các phần riêng lẻ, hoạt động độc lập và phối hợp với nhau để tạo thành một hệ thống lớn hơn Mỗi dịch vụ trong kiến

trúc này đảm nhận một hoặc vài chức năng cụ thể và thường giao tiếp với các

dich vụ khác thông qua các giao thức linh hoạt, thường là qua các lời gọi API.

Kiến trúc Microservice khác biệt so với kiến trúc Monolithic (nguyên khối), phương pháp truyền thống trong đó tất cả các dịch vụ của ứng dụng được gói

gon trong một mã nguồn duy nhất Việc thay đổi hoặc sửa một phần của ứngdụng Monolithic có thé ảnh hưởng đến toàn bộ hệ thống, gây khó khăn trongviệc mở rộng, triển khai và bảo trì Ngược lại, do các dịch vụ trong ứng dụng

Microservice được chia nhỏ, kiến trúc này cho phép triển khai độc lập, mở rộng

quy mô và bảo trì dễ dàng và hiệu quả hơn.

Một số tính năng chính của kiến trúc Microservice bao gồm:

- Tính độc lập và tự chủ của dich vụ: Mỗi dich vụ trong kiến trúc Microservice

được thiết kế để hoạt động độc lập và tách biệt, với mã nguồn, cơ sở dữ liệu và

dữ liệu riêng Điều này mang lại sự linh hoạt trong việc phát triển và triển khai,

vì các dịch vụ có thể được cập nhật và thay đổi mà không ảnh hưởng đến các

- Tính linh hoạt và khả năng mở rộng: Kiến trúc Mieroservices cung cấp khả

năng linh hoạt và mở rộng cao hơn, vì mỗi dịch vụ có thể được triển khai và mởrộng độc lập Điều này cho phép các tổ chức mở rộng quy mô ứng dụng theochiều ngang bằng cách thêm nhiều phiên bản của các dịch vụ cụ thể, thay vì

10

phải mở rộng toàn bộ ứng dụng.

- Kha năng phục hồi và chịu lỗi: Kiến trúc Microservices cải thiện khả năng

phục hồi và khả năng chịu lỗi của ứng dụng, vì mỗi dịch vụ có thể được thiết kế

để xử lý lỗi một cách độc lập Nếu một dịch vụ gặp sự cố, các dịch vụ khác vẫn

có thể tiếp tục hoạt động bình thường, giảm thiểu rủi ro gián đoạn toàn bộ hệ

thống

2.4 Ứng dụng web dựa trên kiến trúc Microservices

Ứng dụng web (Web app) là chương trình phần mềm chạy trên nền tảng web

và được truy cập thông qua trình duyệt web các ứng dụng này thường được lưu

trự tại các máy chủ từ xa Máy chủ này xử lý các yêu cầu từ trình duyệt của người dùng, thực hiện các tác vụ cần thiết và gửi lại dữ liệu hoặc trang web đã

được cập nhật Các tính năng phổ biến nhất trên trang web như giỏ hàng, tìm

kiếm và lọc sản phẩm, nhắn tin tức thì và bảng tin trên mạng xã hội đều là các ứng dụng web về mặt thiết kế Nhờ ứng dụng web, ta có thể truy cập vào chức năng phức tạp mà không cần cài đặt hay cấu hình phần mềm.

Các thành phần của một ứng dụng web thường bao gồm

- Máy chủ web: hiển thị giao diện của ứng dụng web và tiếp nhận các yêu cầu

từ máy khách

- Máy chủ ứng dụng: xử lý các yêu cầu từ máy khách và trả về kết quả

- Database: nơi lưu trữ dữ liệu của ứng dụng web

Da số các ứng dụng sử dụng các công nghệ như HTML, CSS và Javascript

để lập trình cho phía giao diện người dùng (client-side) Lập trình phía máy

chủ ứng dụng (server-side) thường sử dụng các ngôn ngữ như Python, Java hay

Golang để xây dựng các tập lệnh xử lý yêu cầu

Ngày nay, các hệ thống ứng dụng web ngày càng phát triển mạnh mẽ với

nhiều nội dung và chức năng phức tạp đáp ứng nhu cầu người dùng Với sự gia

tăng của các hệ thống phụ và các ứng dụng web, tầm quan trọng về tính ổn

11

định, bảo mật và tin cậy của chúng ngày càng trở nên đáng kể Do đó việc xâydựng hệ thống đảm bảo an toàn, hiệu suất cao đồng thời quá trình triển khai,

bảo trì và quản lý đã trở thành một thách thức lớn cho các nhà lập trình hiện

nay.

2.5 WireGuard

WireGuard là một giải pháp Mạng Riêng Ảo (VPN) mã nguồn mở, nhẹ và

an toàn, được tích hợp vào nhân Linux bắt đầu từ phiên bản 5.6 Ban đầu, WireGuard chỉ được phát hành cho Linux, nhưng hiện nay đã có sẵn trên nhiều

nền tảng và thậm chí đã được chuyển ngược để hỗ trợ các nhân Linux cũ hơnphiên bản 5.6 Một trong những điểm mạnh độc đáo của WireGuard là sự đơngiản trong việc triển khai Theo báo cáo của WireGuard, triển khai trên Linux

có thể được thực hiện trong chưa đến 4.000 dòng mã nguồn Điều này làm chogiải pháp dễ dàng được kiểm tra với bề mặt tấn công tối thiểu Linus Torvalds

đã gọi WireGuard là “một tác phẩm nghệ thuật” so với OpenVPN và IPSec, vốn

có các cơ sở mã lên tới hàng trăm nghìn dòng.

WireGuard có hỗ trợ gốc cho các container và cung cấp mã hóa trong suốt

cho lưu lượng ứng dụng chạy trên các cụm Kubernetes Chủ sở hữu ứng dụng

không phải cấu hình hoặc quản lý bất kỳ khóa mã hóa hoặc chứng chỉ nào, làm cho việc triển khai trở nên liền mạch và tự động So với các dịch vụ mesh của

Kubernetes, WireGuard có cách triển khai đơn giản hơn nhiều, không yêu cầu

control-plane của dịch vụ mesh hoặc các container sidecar WireGuard cũng có

hiệu suất tốt hơn và sử dụng ít tài nguyên hơn so với một dịch vụ mesh.

Có nhiều cách để tích hợp WireGuard với Kubernetes Các plugin ƠNI tainer Network Interface) phổ biến của Kubernetes như Calico và Cilium đã

(Con-thêm hỗ trợ cho WireGuard.

12

2.6 Secure Production Identity Framework for Everyone

- SPIFFE

SPIFFE là một tập hợp các tiêu chuẩn mã nguồn mở để nhận dang hệ thống

phần mềm một cách an toàn trong các môi trường động và không đồng nhất.

Các hệ thống áp dụng SPIFFE có thé dễ dang và đáng tin cậy xác thực lẫn

nhau ở bất kỳ đâu chúng đang chạy.

Các mô hình được thiết kế theo kiến trúc Microservices, container tors và điện toán đám mây đã dẫn đến các môi trường sản xuất ngày càng động

orchestra-và không đồng nhất Các thực hành bảo mật truyền thống (như các chính sách

mạng chỉ cho phép lưu lượng giữa các địa chỉ IP cụ thể) gặp khó khăn trong

việc mở rộng dưới sự phức tạp này Một khung nhận dạng hàng đầu cho các

workloads trong một tổ chức trở nên cần thiết

Hơn nữa, các lập trình viên hiện đại được mong đợi hiểu và đóng vai trò trongcách các ứng dụng được triển khai và quản lý trong môi trường sản xuất Các

quản trị viên yêu cầu có cái nhìn sâu hơn về các ứng dụng mà họ đang quản lý.

Khi chúng ta chuyển sang một lập trường bảo mật tiến bộ hơn, chúng ta phảicung cấp các công cụ tốt hơn cho cả hai đội để họ có thể đóng vai trò tích cực

trong việc xây dựng các ứng dụng phân tán, an toàn.

SPIFFE là một tập hợp các đặc tả mã nguồn mở cho một khung có khả năng khởi tạo và cấp phát danh tính cho các dịch vụ trong các môi trường không

đồng nhất và các ranh giới tổ chức Trọng tâm của các đặc tả này là đặc tả định

nghĩa các tài liệu danh tính mã hóa ngắn hạn thông qua một API đơn giản Các

workloads sau đó có thể sử dụng các tài liệu danh tính này khi xác thực với các

workloads khác, chang hạn như bằng cách thiết lap một kết nối TLS hoặc bằng

cách ký và xác minh một mã thông báo.

Hiện nay SPIFFE được sử dụng bởi nhiều doanh nghép và tổ chức lớn như

Google, IBM, Intel,

Một số lợi ích mà SPIRE mang lại cho các hệ thống như sau:

13

- Cấp phát danh tính đáng tin cậy: SPIFFE cung cấp một cơ chế tiêu chuẩn

để cấp phát và quản lý danh tính Nó dam bảo rằng mỗi dịch vụ trong một hệthống phân tán nhận được một danh tính duy nhất và có thể xác minh, ngay

cả trong các môi trường động nơi các dịch vụ có thể tăng hoặc giảm quy mô

thường xuyên.

- Chứng thực danh tính: SPIFFE cho phép các dịch vụ chứng minh danh tính

của họ thông qua chứng thực Nó đảm bảo rằng các dich vụ có thể chứng minh

tính xác thực và toàn vẹn của mình bằng cách cung cấp bằng chứng có thể xác

minh về danh tính của họ, như chữ ký số hoặc các bằng chứng mã hóa.

- Môi trường động và có khả năng mở rộng: SPIFFE giải quyết các thách thức về quản lý danh tính trong các môi trường động Nó hỗ trợ cấp phát, luân

chuyển và thu hồi danh tính tự động, điều này rất quan trọng trong các kiếntrúc cloud-native nơi các dịch vụ có thể được triển khai, cập nhật hoặc hủy bỏ

liên tục.

SPIRE là một giải pháp mạnh mẽ và linh hoạt cho việc quản lý danh tinh

và chứng thực trong các môi trường san xuất hiện đại N6 giúp giải quyết các thách thức về bảo mật và quản lý trong các hệ thống phân tán, đồng thời tăng cường khả năng mở rộng và tính linh hoạt cho các kiến trúc cloud-native và

microservices Việc tích hợp SPIRE với các công cụ như Cilium càng làm tăng cường tính bảo mật và hiệu quả quản lý cho các môi trường này.

2.7 Giao tiếp trong Kubernetes

2.7.1 Giao tiếp giữa các container trong cùng mét pod

2.7.1.1 Giao tiếp thông qua các port

Khi một Pod được tạo, nó sẽ được gấn cho một địa chỉ IP cho nên mỗi Pod

sẽ có một địa chỉ IP của riêng nó và các container nằm trong pod sẽ sử dụng

chung địa chỉ IP này Vì vậy các container này có thể giao tiếp tự do với nhau

14

bằng cách sử dung localhost và các port khác nhau Điều này cũng có nghĩa là 2

container không thể listen cùng một port giống nhau được, đây là một hạn chế

nhưng nó không khác gì việc chạy nhiều process trên cùng một máy host.

2.7.1.2 Chia sé volume trong một Pod

Trong Kubernetes, ta có thể sử dụng một shared Kubernetes volume mộtcách đơn giản và hiệu qua để chia sé dit liệu giữa các container trong một Pod

Đối với hầu hết các trường hợp, nó đơn giản là sử dụng một thư mục trên máy

chủ (host) để chia sẻ cho tất cả các container trong một Pod

Kubernetes Volume cho phép dit liệu tồn tại khi khởi động lại một container, những volume này có cùng lifetime với Pod Điều đó có nghĩa là volume (và dữ liệu trong đó) tồn tại tới chừng nào mà Pod còn tồn tại Nếu Pod đó bị xoá vì bất kỳ lý do gì, ngay cả khi có một thay thế giống hệt được tạo ra, shared volume

cũng bị huỷ và được tạo lại Một trường hợp chuẩn (standard use case) cho việc

sử dụng Pod nhiều container với một shared Volume là khi một container chứa

log hoặc các file khác cho thư mục chung, và các container khác đọc từ thư mục

chia sẻ (share directory).

2.7.2 Giao tiếp giữa các pod

2.7.2.1 Các pod trong cùng một node

Trong một cụm Kubernetes, giao tiếp từ pod đến pod là rất quan trọng để

các ứng dụng chạy trong đó hoạt động đúng cách Khi các ứng dụng Kubernetes

được triển khai trên một nút duy nhất, các pod gồm các ứng dụng này cần phải

giao tiếp với nhau Mỗi pod trong cum được gán một địa chỉ IP duy nhất, dựa vào địa chỉ IP đó cho phép chúng giao tiếp trực tiếp.

Tuy nhiên, vì các pod là tạm thời và có thể được tạo ra, xóa đi hoặc khôi

phục lại bất kỳ lúc nào, nên địa chi IP của chúng không chỉ là duy nhất mà còn phải được duy trì nhất quán trong suốt vòng đời của chúng Sự nhất quán này

15

cho phép giao tiếp liền mạch giữa các pod ngay cả khi chúng được tạo ra, bị xóa

hoặc di chuyển trong cụm

2.7.2.2 Giữa các Node khác nhau

Mỗi node trong cụm Kubernetes có các network interface, trong đó eth0 là

interface chính với địa chỉ IP trên mạng riêng, và docker0 là một bridge network

được quản lý bởi Docker Các pod được kết nối thông qua các veth (virtual ethernet) interface, được tạo ra bởi một container pause Kiến trúc có dạng như

vetho 10.244.1.2

\ nm / 1

Hình 2.3: Mô hành Kubernetes gồm 2 Node khác nhau

Để thực hiện giao tiếp giữa các pod nằm ở 2 node khác nhau, Kubernetes

sẽ thực hiện như sau Đầu tiên Kubernetes gán các dia chỉ IP cho các bridge network trên mỗi node, giúp mỗi pod có địa chỉ IP duy nhất không trùng lặp trên toàn cụm Điều này giải quyết van đề gói tin có cùng source và destination

IP Tiếp theo Kubernetes cấu hình các bảng định tuyến (routing table) để định

tuyến gói tin đến node đích phù hợp Khi một gói tin được gửi từ một pod đến một pod trên node khác, nó sẽ được định tuyến đến node đích trước, sau đó

16

được chuyển tiếp đến pod đích thông qua bridge network của node đó Trong

đó kube-proxy là một thành phần của Kubernetes chịu trách nhiệm quản lý các

rules trong bảng định tuyến No thêm, sửa đổi và xoá các rules để đảm bảo giao

tiếp hiệu quả giữa các pod trên các node khác nhau.

2.8 Các phương pháp bảo mật trong Kubernetes

2.8.1 Chính sách mang - Network Policy

Trong hệ thống Kubernetes, các thành phần có thể giao tiếp với nhau qua nhiều phương thức khác nhau Tuy nhiên, một số pod, container quan trọng chỉ

cho phép số lượng nhất định các thành phần khác giao tiếp với chúng Dé thực

hiện việc này, Kubernetes sẽ sử dụng chính sách mang (Network Policy - NP).

Network Policy trong Kubernetes là một khái niệm tập trung vào ứng dụng

được thiết kế để quản lý và kiểm soát lưu lượng mạng vào và ra từ các pod

Chúng cho phép xác định các quy tắc chỉ định cách các pod được phép giao tiếp với các thực thể khác qua mạng Những thực thể này có thể bao gồm các pod

khác, dịch vụ hoặc các điểm kết nối bên ngoài

Khi xác định một Network Policy, ta có thể chỉ định các quy tắc quy định

các pod được phép giao tiếp với pod liên kết với chính sách và ngược lại Điều

này cho phép kiểm soát chỉ tiết hơn về lưu lượng mạng trong cụm Kubernetes

Đồng thời nó cũng đảm bảo ngăn chặn các truy cập trái phép đến các dữ liệu

và dịch vụ nhạy cảm

Quan trọng nhất, Network Policy chỉ áp dụng cho các kết nối liên quan đến các pod được liên kết với chính sách Chúng không ảnh hưởng đến các kết nối khác trong cụm Điều này cho phép ta thực hiện các chính sách giao tiếp mạng

cụ thé cho từng pod hoặc nhóm pod, đảm bảo an ninh và cách ly tốt hon trong

môi trường Kubernetes Network Policy là một resource trong Kubernetes, vi

vậy ta sẽ sử dụng file YAML để định nghĩa chúng

17

2.8.2 Bao mật cho Pod

Pod Security Policy (PSP) là một tài nguyên trong Kubernetes được sử dung

để thiết lap và quan lý các chính sách bảo mat cho các pod trong cum

Kuber-netes PSP cho phép xác định các quy tắc bảo mật mà các pod phải tuân thủ

khi chạy trên các node trong cụm Tương tự như Container’s security context,

PSP cũng có một số tính năng như ngăn chặn container run với root user, chặn

process có thể ghi vào trong filesystem của container, Tuy nhiên PSP đã bị

loại bỏ khỏi Kubernetes từ phiên bản 1.21 do van đề về tính linh hoạt và quan

lý Thay vào đó, Kubernetes khuyến khích sử dụng các bên thứ 3 trong việc

quản lý bảo mật Pod.

2.8.3 Hảo mật cho container

Bên cạnh Network Policy, Kubernetes còn cung cấp cho ta thuộc tính

secu-rityContext, cho phép có thể config một số thuộc tính container như ngăn chặn

container run với root user, chặn process có thể ghi vào trong filesystem của

container, qua đó tăng thêm tính bảo mật và an toàn cho container quan

cao trong không gian kernel mà không cần phải thay đổi mã nguồn kernel hoặc

tải các mô-đun kernel Được phát triển ban đầu như một công cụ lọc gói mạng,eBPF đã phát triển để hỗ trợ một loạt các ứng dụng khác nhau, bao gồm giám

sát/quan sát hệ thống, bảo mật, và tối ưu hóa hiệu suất mang

Vi các chương trình eBPF chạy trong nhân, chúng mang lại những lợi ích

18

như: Chỉ quy trình có đặc quyền được chạy, linh hoạt, hiệu quả, nâng cao khả

năng giám sát, bảo mat

Việc làm cho kernel Linux có thể lập trình được cho phép tạo ra phần mềm

ha tầng thong minh hon và giàu tính năng hơn dựa trên các lớp trừu tượng hiện

có (thay vì thêm các lớp mới), mà không làm tăng độ phức tạp của hệ thống,

hy sinh hiệu quả thực thi, hoặc làm tổn hại đến bảo mật

2.9.2 Giới thiệu vé Cilium

Cilium là một giải pháp bảo mật mã nguồn mở, hiện dai và nâng cao Nó

cung cấp khả năng hiển thị và kiểm soát ở mức độ cao đối với lưu lượng mạng,

đồng thời cung cấp các tính năng bảo mật nâng cao, bao gồm mã hóa, thực thi chính sách mang, Cilium có cốt lõi là eBPF, cho phép chèn động logic điều

khiển bên trong Linux do đó các chính sách bảo mật của Cilium có thể được áp

dụng và cập nhật mà không cần thay đổi mã ứng dụng hoặc cấu hình container.

Nhìn chung đây là một giải pháp bao mật linh hoạt và mạnh mẽ cho việc bảo

mật và quản lý mạng trong các hệ thống phân tán hiện đại Việc sử dụng công

nghệ eBPF và tập trung vào bao mật ở mức mạng làm cho Cilium trở nên đặc biệt phù hợp cho các môi trường container hóa, nơi mà các giải phấp bảo mật

và mạng truyền thống có thể không đủ hiệu quả Cilium không chỉ cung cấp

bảo mật và hiệu suất cao mà còn giúp đơn giản hóa việc quản lý và mở rộng các

ứng dụng container hóa, tạo điều kiện cho các tổ chức phát triển và vận hành

các ứng dụng một cách an toàn và hiệu quả.

2.9.3 Kiến trúc của Cilium

Cilium là giải pháp bảo mật và quan sát lưu lượng cho các hệ thống hoạt động trên môi trường Kubernetes Kiến trúc của Cilium bao gồm các thành phần

- Agent: Mỗi agent chạy trên một node của cum Kubernetes và chịu trách

nhiệm thiết lập kết nối với máy chủ API của Kubernetes, duy trì các chính sách

19

Hình 2.4: Kiến trúc của Cilium Nguồn: cilium.io

mang và bảo mật Agent sử dụng eBPF để chèn các chính sách này vào nhân

Linux, đảm bảo hiệu suất cao và độ an toàn.

- Operator: Quan lý các nhiệm vụ của toàn bộ cụm, nhưng không quan trong

đối với các quyết định chính sách mạng Nếu Operator không khả dụng, có thểxảy ra sự chậm trễ trong việc quản lý địa chỉ IP và tình trạng không ổn định

của kvstore, dẫn đến việc khởi động lại agent

- Cilium CLI: Giao diện dòng lệnh (CLI) cung cấp khả năng tương tác với máy chủ API của Cilium, cho phép quan lý và cấu hình các chính sách của

Cilium một cách hiệu quả.

- CNI Plugin (Container Networking Interface): Plugin CNI được kích hoạt

bởi Kubernetes trong quá trình lập lịch hoặc kết thúc pod trên một node Nó

giao tiếp với API của Cilium trên node để khởi tạo cấu hình đường truyền dữ

liệu (datapath) cần thiết cho mạng, cân bằng tải, và các chính sách mạng cho

pod.

Kiến trúc của Cilium rất linh hoạt và có thể xử lý các cấu trúc mạng phức

tạp Nó cung cấp nhiều tính năng như khả năng da cụm và đa đám mây, cân

20

bằng tải nâng cao, mã hóa trong suốt, và khả năng bảo mật mạng mở rộng Với eBPF là cốt lõi, Cilium có thể đạt được mạng và bảo mật hiệu suất cao và độ trễ thấp cho các hệ thống phân tán hiện đại.

2.9.4 Hoạt động của Cilium

Như đã đề cập trước đó, Cilium là một công cụ mạng mạnh mẽ hoạt động ở lớp mạng và cung cấp các tính năng bảo mật tiên tiến cho các cụm Kubernetes.

O mức cao, Ơilium hoạt động bằng cách chặn và phân tích lưu lượng mạng giữa

các pod của Kubernetes và sử dụng thông tin này để thực thi các chính sách

bảo mật.

Khi một gói tin được gửi giữa hai pod, Cilium sẽ chặn gói tin và kiểm tra nguồn và đích của nó Sau đó, nó xác định xem gói tin có được phép truyền đi

hay không dựa trên tập hợp các chính sách bảo mật do quản trị viên của cụm

định nghĩa Các chính sách này có thể dựa trên nhiều yếu tố khác nhau, như

danh tính của các pod nguồn và đích, nhãn hoặc chú thích của chúng, và loại lưu lượng đang được truyền.

Việc thực thi chính sách của Cilium dựa vào eBPF, một máy ảo cho phép

các chính sách bảo mật phức tạp chạy trực tiếp trong nhân Linux để xử lý lưu

lượng mang một cách hiệu quả Điều này cho phép Cilium thực thi các chính

sách mà không cần thay đổi mã ứng dụng hoặc cấu hình mạng

Cilium cung cấp một số tính năng mang nâng cao có thể cải thiện độ tin cậy

và hiệu suất của các cụm Kubernetes ngoài việc thực thi chính sách Trong số các tính năng này, Cilium có thể thực hiện cân bằng tải và định tuyến lưu lượng

giữa các pod, cũng như cung cấp khả năng quan sát lưu lượng mạng thông qua các công cụ giám sát và truy vết nâng cao.

Kiến trúc service mesh của Cilium, mặt khác, sử dung các chương trình eBPF

được chèn vào nhân Linux để cho phép thực thi chính sách minh bạch và cung

cấp khả năng quan sát sâu vào lưu lượng mạng Khả năng này cho phép Cilium

thực thi các chính sách dựa trên danh tính để đảm bảo giao tiếp dịch vụ an

21

toàn và thực hiện phân tích luồng mạng toàn điện để tăng cường bảo mật và

khả năng quan sát.

2.9.5 Các giải pháp bảo mat của Cilium

Cilium cung cấp một loạt các tính năng và chức năng giúp tăng cường mạng

và bảo mật trong các môi trường Kubernetes

- Khả năng khám phá mạng và dịch vụ: Cilium cung cấp khả năng khám phá mạng và dịch vụ mạnh mẽ, cho phép giao tiếp hiệu quả giữa các dịch vụ trong cụm Kubernetes Nó tự động khám phá va theo dõi tất cả các pod, dịch vụ va

điểm cuối theo thời gian thực, đảm bảo rằng các chính sách mạng và quyết định

định tuyến luôn được cập nhật.

- Các tùy chọn cân bằng tải và định tuyến nâng cao: Cilium cung cấp các tùy chọn cân bằng tải và định tuyến nâng cao giúp cải thiện khả năng mở rộng và hiệu suất của các ứng dụng Kubernetes No hỗ trợ nhiều thuật toán cân bằng tải khác nhau, như vòng lặp, băm nhất quán và kết nối ít nhất, cho phép phân phối lưu lượng hiệu quả qua nhiều phiên bản của một dịch vụ.

- Mã hóa và xác thực minh bạch: Bảo mật là một khía cạnh quan trọng của

bất kỳ triển khai Kubernetes nào, và Cilium cung cấp các cơ chế mã hóa và xácthực minh bach để đảm bảo giao tiếp an toàn giữa các dịch vụ N6 hỗ trợ xác

thực Transport Layer Security (mTLS) tương hỗ, cho phép các dịch vụ xác thực

lẫn nhau trước khi thiết lập kết nối Diều này ngăn chặn truy cập trái phép và bảo vệ chống lại các cuộc tấn công man-in-the-middle.

- Chính sách bảo mật mạng và kiểm soát truy cập: Cilium cung cấp các chínhsách bảo mật mạng mạnh mẽ và cơ chế kiểm soát truy cập Ta có thể định nghĩacác quy tắc chi tiết để cho phép hoặc từ chối lưu lượng dựa trên nhiều tham

số khác nhau như IP nguồn, IP đích, cổng, giao thức và thậm chí là các HTTP

header Điều này cho phép ta thực thi các mô hình bảo mật không tin tưởng

(zero-trust) và triển khai các chiến lược phòng thủ sâu Bằng cách tận dụng cácchính sách bảo mật mạng của Cilium, ta có thể hạn chế giao tiếp giữa các dịch

22

vụ, thực thi các kiểm soát truy cập cụ thể cho ứng dụng và bảo vệ dữ liệu nhạy

cảm Điều này nâng cao tình trạng bảo mật tổng thể của cụm Kubernetes, giảm

thiểu nguy cơ truy cập trái phép và tiềm an sự cố dữ liệu

- Công cụ quan sát và xử lý sự cố: Cilium cung cấp các công cụ quan sát và

xử lý sự cố toàn diện để giúp ta giám sát và chan đoán hành vi mạng trong cum

Kubernetes N6 cung cấp các số liệu phong phú và dữ liệu telemetry, cho phép

ta có được cái nhìn sâu sắc về các mô hình lưu lượng mạng, độ trễ, gói tin bị mất, và nhiều hơn nữa Cilium tích hợp với các nền tảng quan sát phổ biến, như

Prometheus và Grafana, giúp trực quan hóa và phân tích các số liệu liên quan đến mạng N6 cũng cung cấp khả năng truy vết tích hợp sẵn, cho phép ta truy

vết các yêu cầu qua các dịch vụ và xác định các nút cổ chai hoặc vấn đề hiệu

suất.

2.9.6 Hubble

Hubble là một nền tảng giám sát bảo mat và mang phân tán Nó được xây

dựng dựa trên Cilium và eBPF để cho phép hiển thị (nhìn thấy) sâu hơn về giao tiếp và hành vi của các service cũng như cơ sở hạ tầng mạng một cách hoàn

toàn minh bạch.

Bằng cách xây dựng trên nền Cilium, Hubble có thể tận dụng eBPF để cókhả năng hiển thi (visibility) Bằng cách dựa vào eBPF, tất cả khả năng hiểnthị đều có thể lập trình được và cho phép một cách tiếp cận động giúp giảmthiểu chi phí (overhead) trong khi vẫn cung cấp khả năng hiển thị sâu và chitiết theo yêu cầu của người dùng Hubble đã được tạo ra và thiết kế đặc biệt để

tận dụng tốt nhất các sức mạnh eBPF Các thành phần của Hubble bao gồm:

- Máy chủ (Server): Máy chủ Hubble chạy trên mỗi node và lấy dit liệu quan

sát dựa trên eBPF từ Cilium Nó được nhúng vào agent của Cilium để đạt đượchiệu suất cao và ít overhead nhất có thể

- Relay: là một thành phần độc lập có ý thức về tất cả các máy chủ Hubble đang chạy và cung cấp khả năng quan sát toàn cụm bằng cách kết nối đến các

23

API gRPC của chúng và cung cấp một API đại diện cho tất cả các máy chủ

trong cụm.

- Client (CLI): CLI của Hubble (hubble) là một công cụ dòng lệnh có khả

năng kết nối vào API gRPC của hubble-relay hoặc máy chủ cục bộ để lấy các

sự kiện luồng dữ liệu.

- Giao diện đồ họa (GUI): Giao diện người dùng đồ họa (hubble-ui) sử dung

quan sát dựa trên truyền dẫn để cung cấp một bản đồ phụ thuộc và kết nối dịch

vụ dưới dạng đồ họa.

£5 Choose namespace v Idle

SeWelcome!

+ cilium-spire

« default

« kube-node-lease + kube-public

« kube-system

« sock-shop

Hình 2.5: Giao diện của Hubble

2.10 Chính sách mạng của Cilium

Cilium thực hiện tiêu chuẩn chính sách mạng của Kubernetes Chính sách

mạng Kubernetes của ta hoạt động ngay lập tức với Cilium mà không cần bất

kỳ thay đổi bổ sung nào Tuy nhiên, Cilium cũng tiến xa hơn và mở rộng tiêuchuẩn chính sách của Kubernetes thông qua các chính sách mạng của Cilium,

cung cấp tính linh hoạt, chi tiết và các tính năng tiên tiến hơn Với các chính

sách mạng của Cilium, ta có thể triển khai các quy tắc hiệu quả hơn tại các

tầng 3, 4 và 7 của mô hình OSI, phục vụ cho các trường hợp sử dụng trong các môi trường rộng lớn và cải tiến hơn so với chính sách mạng tiêu chuẩn của

24

Cilium giới thiệu hai định nghĩa tài nguyên tùy chỉnh Kubernetes mới (CRDs):

CiliumNetworkPolicy và CiliumClusterwideNetworkPolicy Với các CRD này, ta

có thể xác định các chính sách bảo mật với Cilium như là các đối tượng

Kuber-netes, và Kubernetes sẽ tự động phân phối các chính sách này đến tất cả các node

trong cụm CRD CiliumNetworkPolicy có phạm vi namespace, trong khi CRD CiliumClusterwideNetworkPolicy hoạt động tương tự như CiliumNetworkPolicy

nhưng có phạm vi cụm.

Với Network Policy truyền thống, việc thực thi bảo mật đã dựa vào các bộ lọc địa chỉ IP Tuy nhiên, với sự xuất hiện của các môi trường điều phối container

đám mây gốc rất động như Kubernetes, việc dựa vào địa chi IP để thực thi bảo

mật hạn chế khả năng mở rộng và linh hoạt trong các môi trường này Trong

Kubernetes, chang hạn, mỗi pod được gán một địa chi IP duy nhất và khi thực

thi bảo mật dựa trên địa chỉ IP, các bộ lọc địa chỉ IP (quy tắc iptables do

kube-proxy định nghĩa) được đặt trên mỗi node trong cụm Mỗi khi một pod được khởi động hoặc dừng lại, các bộ lọc địa chi IP trên mỗi node trong cụm phải

được cập nhật Trong một cụm lớn, tùy thuộc vào tỷ lệ thay đổi của các pod

được triển khai, việc cập nhật các quy tắc bảo mat dựa trên dia chỉ IP này cóthể đòi hỏi cập nhật hàng ngàn node trong cụm nhiều lần mỗi giây! Điều này

cũng có nghĩa là việc khởi động một số pod mới phải bị trì hoãn cho đến khi các cập nhật liên quan đã được thực hiện đối với các quy tắc bảo mật trên các node trong cụm Cách tiếp cận này không linh hoạt, dễ bị lỗi và không mở rộng tốt.

Cilium hoàn toàn tách biệt bảo mật khỏi địa chỉ mạng bằng cách sử dụng danh tính workload được tao ra từ sự kết hợp giữa nhãn và siêu dit liệu do người dùng và hệ thống định nghĩa Khi một pod được tạo ra, Cilium tạo ra

một endpoint đại diện cho pod trên mang Endpoint được gan một địa chỉ [Pv4

và IPv6 nội bộ Danh tính của endpoint được tạo ra từ các nhãn của pod; nếu

các nhãn thay đổi, Cilium sẽ cập nhật danh tính của endpoint tương ứng Danh

tính này được sử dụng để thực thi kết nối cơ bản giữa các endpoint Các pod

25

bây giờ chỉ cần giải quyết danh tính của chúng từ một khoá-giá trị, điều này đơn giản hơn nhiều so với việc cập nhật các quy tắc bảo mật cho mỗi node trong

cụm.

O tầng 3, các chính sách dựa trên điểm cuối của Cilium có thể xác định các

quy tắc kết nối dựa trên nhãn pod Các chính sách dựa trên dịch vụ sử dụng

các dịch vụ hệ thống ví dụ như các dịch vụ điểm cuối của Kubernetes để xácđịnh các quy tắc kết nối Các chính sách dựa trên thực thể cho phép phân loại

các peer từ xa mà không cần biết địa chỉ IP của chúng Các chính sách dựa trên IP/CIDR xác định các quy tắc kết nối cho các dịch vụ bên ngoài bằng cách sử dụng các địa chỉ IP hoặc mạng con đã cấu hình trước Các chính sách dựa trên

DNS có thể xác định các quy tắc kết nối dựa trên tên DNS được phân giải thành

địa chi IP.

Ỏ tầng 4, các chính sách mạng Cilium có thể xác định các quy tắc cho phép

một điểm cuối gửi và nhận các gói trên một cổng cụ thể bằng cách sử dụng một

giao thức được chỉ định Cuối cùng, ở tầng 7, các chính sách mạng của Cilium

cho phép xác định các quy tắc bảo mật cấp API cho các giao thức tầng 7 phổ

biến như HTTP, Kafka, gRPC, v.v.

Ta có thể áp dụng các chính sách mạng Cilium cho một pod duy nhất, một

nhóm pod có chung nhãn, một namespace hoặc toàn bộ cụm Điều này cung cấp khả năng áp dụng cùng một mô hình bảo mật mạng nhất quán trên các mức độ khác nhau của toàn bộ cơ sở hạ tầng.

Cilium cũng hỗ trợ các chính sách host với CRD

CiliumClusterWideNet-workPolicy Tinh năng này về cơ bản là một tường lửa cấp host cho các node

được chọn trong cụm, mở rộng mô hình chính sách bảo mật mạng Kubernetes

nhất quán đến các máy chủ Một ví dụ về điều này là chặn truy cập SSH đến các node và các lệnh ICMP ping tới các node Kết hợp chính sách mạng Cilium

và CRD có thể đơn giản hóa quản lý chính sách bảo mật Các chính sách bảomật cơ sở được áp dụng cho tất cả các pod có thể được chỉ định là các chínhsách cụm Cilium, và các chính sách cụ thể cho pod(s) có thể được chỉ định là

26

Thuộc tính | Kubernetes Cilium

Selectors Pod Endpoints (bao gồm

Pod), Node

Traffic Direction | Ingress, Egress Ingress, Egress

Traffic Filtering | Pod and Namespace la- | Endpoints (Pod and

bels, CIDR, L4 Namespace), CIDR ,

L3/4/7, DNS, Entities,

Services Bang 2.1: Bang so sánh chính sách mang của Kubernetes va Cilium

các chính sách mang Cilium Một ví dụ về chính sách cơ bản sé là một quy tắc

từ chối mặc định cho tất cả các pod và cho phép lưu lượng egress đến kube-dns cho tất cả các pod trong cụm.

27

CHƯƠNG 3 PHƯƠNG PHÁP THỰC HIỆN

lộ chương này tôi sẽ trình bày về phương pháp triển khai cụm Kubernetes,

ứng dụng Microservice và các giải pháp bảo mật của Cilium

3.1 Phương pháp triển khai hệ thống Kubernetes

Để triển khai hệ thống Kubernetes, tôi đã sử dụng công cụ Minikube, sau đó

tạo ra 3 node trong cum bao gồm 1 đóng vai trò Master Node và 2 node đóng

vai Worker Node Ở đây tôi còn sử dụng thêm công cu kubectl - đây là công cụ

cho phép sử dụng các dòng lệnh để quản lý cũm Kubernetes Kubectl sử dungKubernetes API để tương tác với cum Kubernetes

Tôi sẽ phân chia vai trò chừng Node với mỗi Node tương ứng với một vai

trò trong hoạt động của ứng dụng web Master Node sẽ là vùng chứa các Pod

Front-end, 2 Worker Node sẽ đóng vai trò lần lượt là back-end và database

Để thực hiện phân chia vai trò, tôi sẽ thực hiện tạo một đoạn script gán nhãn

cho từng Node sử dụng công cụ kubectl như sau:

3.2 Ứng dụng Microservice và phương pháp triển khai

lên hệ thống Kubernetes

3.2.1 Ung dung dựa trên kiến trúc Microservice

Ứng dụng Microservice được sử dụng là một ứng dung mã nguồn mở với nhiều

ngôn ngữ khác nhau (NodeJS, Go, ) nhằm tối đa hóa số lượng microservice và

thúc đẩy tính đa ngôn ngữ của ứng dụng Ứng dụng này cho phép có một một

hệ sinh thái đa dạng các dịch vụ và công nghệ, điều này có thể có lợi cho việc

28

$ node_labels.sh x

$ node_labels.sh

1 #!/bin/bash

2

3 # Script to label multiple nodes in Kubernetes

4 declare -A NODES LABELS=(

10 Tor NODE in "${!NODES LABELS[@]}"; do

11 LABEL=${N0DES_ LABELS[ $N0DE ] }

12 echo "LabeLing node $N0DE with $LABEL"

13 kubectl label node $NODE $LABEL

Hinh 3.1: Script gan nhan cho cac node trong cum Kubernetes

khám phá các giải phép và phương pháp khác nhau cho các thách thức khác

nhau.

Về cơ bản ứng dụng được chia làm các dịch vụ nhỏ như sau:

1 Eront end: là giao diện người dùng được viết bằng Reactjs Khi người tương

tác trên giao diện, ứng dung front-end sẽ gửi các API tương ứng tới từng service khác đề xử lí.

2 Back-end: Là phần xử lí các chức năng của ứng dụng web này bao gồm các

dịch vụ sử dụng nhiều ngôn ngữ lập trình khác nhau:

- Java/ NET: dịch vu Order thực hiện chức năng đặt hàng - Golang: bao

gồm các dịch vụ Payment, User và Catalogue - Java: dịch vụ Cart và xử

lý dịch vu shipping - Framework RabbitMQ: Thực hiện nhiệm vu tạo hàng

chờ (queue)

3 Về database, theo reposity gốc thì các dịch vụ sẽ sử dụng các loại database

khác nhau để lưu trữ dit liệu

29

Hình 3.2: Kién trúc của ứng dung Microservices

- MongoDB: lưu trữ dữ liệu cho các service Order, User va Cart

- MySQL: lưu trữ dữ liệu của Catalogue

Để triển khai ứng dụng Microservice này, tôi đã sử dụng các docker image

được xây dựng san cho từng dịch vụ tại mã nguồn trên Github Dockerfile để

build image cho các dịch vụ Frontend như sau

Doan mã này định nghĩa một image Docker chứa một ứng dụng Node.js.

Cụ thể, nó sử dụng image base là node:10-alpine, thiết lập môi trường cho ứngdụng Node.js là "production" và cổng mặc định là 8079, sau đó khai báo rằngcontainer sẽ lắng nghe trên cổng 8079 Container được thiết lập với người dùng

và nhóm mới myuser, và tất cả các tệp và thư mục trong thư mục làm việc của

ứng dụng được sao chép vào container Sau đó, lệnh yarn install được chạy để

cài đặt các phụ thuộc của ứng dụng, và lệnh mặc định khi container chạy là

"npm start"

30