CFSDN nhấn mạnh vào giá trị tạo ra nguồn mở và chúng tôi cam kết xây dựng nền tảng chia sẻ tài nguyên để mọi nhân viên CNTT có thể tìm thấy thế giới tuyệt vời của bạn tại đây.

Bài blog CFSDN này sử dụng Cilium để tăng cường bảo mật mạng Kubernetes được tác giả sưu tầm và biên soạn. Nếu các bạn quan tâm đến bài viết này thì nhớ like nhé.

TL;DR

Cải thiện an ninh mạng thông qua các chính sách mạng có thể giảm đáng kể chi phí triển khai và bảo trì mà hầu như không ảnh hưởng đến hệ thống.

Đặc biệt, Cilium, dựa trên công nghệ eBPF, giải quyết vấn đề về khả năng mở rộng hạt nhân không đủ và cung cấp các kết nối mạng an toàn, đáng tin cậy và có thể quan sát được cho khối lượng công việc từ cấp hạt nhân.

lý lịch

Tại sao có rủi ro bảo mật trong mạng Kubernetes? Các Pod trong cluster không bị cô lập theo mặc định, tức là các mạng giữa các Pod được kết nối với nhau và có thể giao tiếp với nhau.

Sẽ có vấn đề ở đây, ví dụ, vì dịch vụ nhạy cảm với dữ liệu B chỉ cho phép dịch vụ A cụ thể truy cập, dịch vụ C không thể truy cập B. Để cấm dịch vụ C truy cập dịch vụ B, có một số tùy chọn:

• Một giải pháp chung được cung cấp trong SDK để triển khai chức năng danh sách trắng. Đầu tiên, yêu cầu phải có mã định danh nguồn, sau đó máy chủ có thể nhận cài đặt quy tắc để cho phép các yêu cầu có mã định danh cụ thể và từ chối các yêu cầu khác.
• Một giải pháp dựa trên nền tảng đám mây sử dụng các chức năng RBAC và mTLS của lưới dịch vụ. Nguyên tắc triển khai của RBAC tương tự như giải pháp SDK ở lớp ứng dụng, nhưng nó là một giải pháp chung trừu tượng ở lớp cơ sở hạ tầng; mTLS phức tạp hơn và việc xác thực được thực hiện trong giai đoạn bắt tay kết nối, liên quan đến việc cấp chứng chỉ, xác minh và các hoạt động khác. hoạt động.

Mỗi lựa chọn trong số hai lựa chọn trên đều có ưu điểm và nhược điểm:

• Giải pháp SDK dễ triển khai nhưng các hệ thống lớn hơn sẽ gặp phải các vấn đề như khó nâng cấp và quảng bá cũng như chi phí hỗ trợ đa ngôn ngữ cao.
• Giải pháp lưới dịch vụ là một giải pháp phổ quát cho lớp cơ sở hạ tầng và vốn hỗ trợ nhiều ngôn ngữ. Tuy nhiên, đối với người dùng chưa triển khai lưới, kiến ​​trúc sẽ thay đổi rất nhiều và chi phí cao. Nếu chỉ nhằm giải quyết các vấn đề về an ninh thì hiệu quả chi phí khi sử dụng giải pháp lưới điện là rất thấp, chưa kể đến khó khăn trong việc triển khai lưới điện hiện tại và chi phí sử dụng, bảo trì sau này cao.

Tiếp tục tìm kiếm giải pháp ở cấp cơ sở hạ tầng thấp hơn, bắt đầu từ lớp mạng. Kubernetes cung cấp chính sách mạng *NetworkPolicy*[1], có thể đạt được "cách ly cấp độ mạng".

Ứng dụng mẫu

Trước khi trình diễn thêm sơ đồ NetworkPolicy, một ứng dụng mẫu để trình diễn sẽ được giới thiệu. Chúng tôi sử dụng cảnh "Chiến tranh giữa các vì sao" được Cilium sử dụng trong hướng dẫn tương tác bắt đầu sử dụng Cilium[2].

Dưới đây là ba ứng dụng mà người hâm mộ Star Wars có thể quen thuộc:

• Death Star: Cung cấp dịch vụ web trên cổng 80, với 2 bản sao và cung cấp dịch vụ "đăng nhập" bên ngoài cho các chiến binh Imperial thông qua cân bằng tải của Kubernetes Service.
• Tiefighter: Thực hiện yêu cầu hạ cánh.
• Máy bay chiến đấu cánh X xwing: thực hiện yêu cầu hạ cánh.

Như trong hình, chúng tôi sử dụng Nhãn để xác định ba ứng dụng: tổ chức và lớp. Chúng tôi sử dụng hai thẻ này để xác định tải trọng khi thực thi chính sách mạng.

# ứng dụng.yaml --- Phiên bản api: v1 loại: Siêu dữ liệu dịch vụ: tên: nhãn tử thần: ứng dụng.kubernetes.cái đó/tên: deathstarspec: kiểu: Cổng ClusterIP: - cảng: 80 bộ chọn: tổ chức: lớp đế chế: ngôi sao tử thần --- Phiên bản api: ứng dụng/v1 loại: Siêu dữ liệu triển khai: tên: nhãn tử thần: ứng dụng.kubernetes.cái đó/tên: deathstarspec: bản sao: 2 bộ chọn: Nhãn phù hợp: tổ chức: lớp đế chế: mẫu deathstar: siêu dữ liệu: nhãn: tổ chức: lớp đế chế: ứng dụng deathstar.kubernetes.cái đó/tên: đặc điểm deathstar: thùng chứa: - tên: hình ảnh ngôi sao tử thần: người đóng tàu.cái đó/lông mi/chiến tranh giữa các vì sao --- Phiên bản api: v1 loại: Siêu dữ liệu con: tên: nhãn hiệu tiefighter: tổ chức: lớp đế chế: ứng dụng tiefighter.kubernetes.cái đó/tên: tiefighterspec: thùng chứa: - tên: hình ảnh tàu vũ trụ: người đóng tàu.cái đó/đồ thị/netperf --- Phiên bản api: v1 loại: Siêu dữ liệu con: tên: nhãn xwing: ứng dụng.kubernetes.cái đó/tên: tổ chức xwing: lớp liên minh: xwingspec: thùng chứa: - tên: hình ảnh tàu vũ trụ: người đóng tàu.cái đó/đồ thị/netperf

Chiến lược mạng Kubernetes

Thông tin chi tiết hơn có thể được lấy thông qua tài liệu chính thức [3] Tại đây chúng tôi trực tiếp công bố cấu hình:

# tự nhiên/chính sách mạng.yaml Phiên bản api: mạng lưới.k8s.cái đó/v1 loại: Chính sách mạng siêu dữ liệu: tên: không gian tên chính sách: thông số mặc định: podSelector: Nhãn phù hợp: tổ chức: lớp đế chế: chính sách deathstarCác loại: - Vào vào vào: - từ: - podSelector: Nhãn phù hợp: tổ chức: cảng đế chế: - giao thức: Cổng TCP: 80 

• podSelector: Cho biết cân bằng khối lượng công việc mà chính sách mạng sẽ được áp dụng và hai Pod của deathstar được chọn thông qua nhãn.
• PolicyTypes: Cho biết loại lưu lượng truy cập, có thể là Ingress hoặc Egress hoặc cả hai. Ingress được sử dụng ở đây để thực thi các quy tắc về lưu lượng truy cập vào của Deathstar Pod đã chọn.
• ingress.from: Cho biết khối lượng công việc nguồn của lưu lượng truy cập. Nó cũng được chọn bằng cách sử dụng podSelector và Label. Ở đây, org=empire được chọn, tất cả đều là "máy bay chiến đấu của đế chế".
• ingress.ports: Cho biết cổng vào của lưu lượng truy cập. Các cổng dịch vụ của deathstar được liệt kê ở đây.

Tiếp theo, hãy kiểm tra nó.

Bài kiểm tra

Trước tiên hãy chuẩn bị môi trường. Chúng tôi sử dụng K3s[4] làm môi trường Kubernetes. Tuy nhiên, do Flannel plug-in CNI mặc định của K3s không hỗ trợ các chính sách mạng nên chúng tôi cần thay đổi một plug-in. Ở đây chúng tôi chọn Calico[5], đây là giải pháp của K3s + Calico.

Đầu tiên tạo một cụm nút đơn:

xoăn -sfL https://lấy.k3s.cái đó | K3S_KUBECONFIG_MODE="644" CÀI ĐẶT_K3S_EXEC="--flannel-backend=none --cluster-cidr=10.42.0.0/16 --vô hiệu hóa-chính sách-mạng --vô hiệu hóa=traefik" cô ấy - 

Tại thời điểm này, tất cả các Pod đều ở trạng thái Đang chờ xử lý vì Calico vẫn cần được cài đặt:

kubectl áp dụng -fhttps://dự áncalico.tài liệu. hổ.cái đó/biểu hiện/vải hoa.yaml 

Sau khi Calico chạy thành công thì tất cả các Pod cũng sẽ chạy thành công.

Bước tiếp theo là triển khai ứng dụng:

kubectl áp dụng -ứng dụng f.yaml 

Trước khi thực hiện chiến lược, hãy thực hiện lệnh sau để xem liệu "máy bay chiến đấu có thể hạ cánh trên Ngôi sao chết" hay không:

kubectl thực hiện tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing Tàu hạ cánh kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing Tàu đã cập bến

Đánh giá từ kết quả, cả hai "máy bay chiến đấu" (tải trọng Pod) đều có thể truy cập dịch vụ deathstar.

Tại thời điểm này, chính sách mạng được thực thi:

kubectl áp dụng -f bản địa/chính sách mạng.yaml 

Hãy thử "đăng nhập" lại và yêu cầu đăng nhập xwing sẽ dừng ở đó (bạn cần sử dụng ctrl+c để thoát hoặc thêm --connect-timeout 2 khi thực hiện yêu cầu).

nghĩ

Sử dụng chính sách mạng Kubernetes, chúng tôi đã đạt được những gì mình mong muốn, thêm chức năng danh sách trắng vào dịch vụ từ cấp độ mạng. Giải pháp này không tốn chi phí chuyển đổi và hầu như không ảnh hưởng đến hệ thống.

Có phải nó đã kết thúc trước khi Cilium xuất hiện? Hãy tiếp tục xem xét:

Đôi khi các dịch vụ của chúng tôi sẽ hiển thị một số điểm cuối quản lý với thế giới bên ngoài và các lệnh gọi hệ thống sẽ được sử dụng để thực hiện một số thao tác quản lý, chẳng hạn như cập nhật nóng, khởi động lại, v.v. Các điểm cuối này không được phép gọi bởi các dịch vụ thông thường, nếu không sẽ gây ra hậu quả nghiêm trọng.

Ví dụ: trong ví dụ, tiefighter truy cập vào điểm cuối/cổng xả quản lý của deathstar:

kubectl thực hiện tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port Hoảng loạn: deathstar nổ tung goroutine 1 [đang chạy]: chủ yếu.Xử lý rác(0x2080c3f50, 0x2, 0x4, 0x425c0, 0x5, 0 lần) /mã số/nguồn/github.với/đế chế/ngôi sao tử thần/ nhiệt độ/chủ yếu.đi:9 +0x64 chủ yếu.chủ yếu() /mã số/nguồn/github.với/đế chế/ngôi sao tử thần/ nhiệt độ/chủ yếu.đi:5 +0x85 

Xảy ra lỗi hoảng loạn. Kiểm tra Pod và bạn sẽ thấy rằng Dealhstar không hoạt động.

Chính sách mạng của Kubernetes chỉ có thể hoạt động trên lớp L3/4 và bất lực trên lớp L7.

Vẫn phải yêu cầu Cilium.

Chiến lược mạng Cilium

Vì Cilium liên quan đến nhiều điểm kiến ​​thức như nhân Linux và mạng nên sẽ mất nhiều thời gian để giải thích rõ ràng các nguyên tắc triển khai. Vì vậy, ở đây tôi chỉ trích phần giới thiệu từ trang web chính thức, hy vọng sau này sẽ có thời gian viết một bài khác về việc thực hiện.

Giới thiệu về Cilium

Cilium[6] là một phần mềm nguồn mở để cung cấp, bảo mật và quan sát các kết nối mạng giữa khối lượng công việc của container (bản địa đám mây), được hỗ trợ bởi công nghệ hạt nhân mang tính cách mạng eBPF[7].

eBPF là gì?

Nhân Linux luôn là nơi tuyệt vời để triển khai các khả năng giám sát/quan sát, kết nối mạng và bảo mật. Tuy nhiên, trong nhiều trường hợp, điều này không dễ dàng, vì những tác vụ này yêu cầu sửa đổi mã nguồn hạt nhân hoặc tải các mô-đun hạt nhân. Việc thực hiện cuối cùng là đặt chồng các lớp trừu tượng mới lên trên các lớp trừu tượng hiện có. eBPF là một công nghệ mang tính cách mạng có thể chạy các chương trình sandbox trong kernel mà không cần sửa đổi mã nguồn kernel hoặc tải các mô-đun kernel.

Việc làm cho nhân Linux có thể lập trình sẽ cho phép bạn xây dựng phần mềm cơ sở hạ tầng thông minh hơn, 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 mới) mà không làm tăng độ phức tạp của hệ thống hoặc hy sinh tính bảo mật và hiệu quả Thực thi.

Hãy cùng xem chiến lược mạng của Cilium:

#lông mi/chính sách mạng-L4.yaml Phiên bản api: "cilium.io/v2" loại: CiliumNetworkPolicysiêu dữ liệu: tên: "quy tắc 1" đặc điểm kỹ thuật: Sự miêu tả: "Chính sách L7 hạn chế quyền truy cập vào cuộc gọi HTTP cụ thể" Bộ chọn điểm cuối: Nhãn phù hợp: tổ chức: lớp đế chế: sự xâm nhập của ngôi sao chết: - từĐiểm cuối: - Nhãn phù hợp: tổ chức: đế chế đếnCảng: - cổng: - cảng: "80" giao thức: Giao thức TCP

Nó không khác nhiều so với chiến lược mạng gốc của Kubernetes. Bạn có thể hiểu nó bằng cách tham khảo phần giới thiệu trước.

Bài kiểm tra

Vì Cilium tự triển khai CNI nên không thể sử dụng cụm trước đó. Trước tiên, hãy gỡ cài đặt cụm đó.

k3s-gỡ bỏ cài đặt.sh #! ! ! Hãy nhớ dọn sạch plug-in cni trước đó sudo rm -tần số vô tuyến /vân vân/cni/mạng lưới.đ 

Hoặc sử dụng lệnh tương tự để tạo cụm nút đơn:

xoăn -sfL https://lấy.k3s.cái đó | K3S_KUBECONFIG_MODE="644" CÀI ĐẶT_K3S_EXEC="--flannel-backend=none --cluster-cidr=10.42.0.0/16 --vô hiệu hóa-chính sách-mạng --vô hiệu hóa=traefik" cô ấy - # cilium sẽ sử dụng biến này để xuất KUBECONFIG=/vân vân/người chăn nuôi/k3s/k3s.yaml 

Tiếp theo cài đặt Cilium CLI:

xoăn -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz{,.sha256sum} sha256sum --kiểm tra cilium-linux-AMD64.tar.gz.sha256sum sudo tar xzvfC lông mao-Linux-amd64.takes.gz /sử dụng/địa phương/binrm lông mao-Linux-amd64.takes.gz{,.sha256sum} phiên bản lông mao-máy tính: v0.10.2 biên dịch với go1.17.6 TRÊN Linux/hình ảnh amd64cilium (mặc định): v1.11.1 hình ảnh lông mao (ổn định): v1.11.1 hình ảnh lông mao (đang chạy): không rõ. Không thể có được phiên bản lông mao, không tìm thấy vỏ lông mao TRONG không gian tên "hệ thống kube" 

Cài đặt Cilium vào cụm:

cài đặt lông mao

Đợi Cilium chạy thành công:

tình trạng lông mi /¯¯\ /¯¯\__/¯¯\ Cilium: ĐƯỢC RỒI \__/¯¯\__/ Người điều hành: ĐƯỢC RỒI /¯¯\__/¯¯\Hubble: tàn tật \__/¯¯\__/ Cụm Lưới: tàn tật \__/ Triển khai lông mao-nhà điều hành mong muốn: 1, Sẵn sàng: 1/1, Có sẵn: 1/1 DaemonSet cilium mong muốn: 1, Sẵn sàng: 1/1, Có sẵn: 1/1 Container: lông mao Chạy: 1 lông mi-Người điều hành đang chạy: 1 Cụm Pod: 3/3 được quản lý qua Phiên bản CiliumImage cilium-bến tàu của người vận hành.cái đó/lông mi/người điều hành-chung chung:v1.11.1@sha256:977240a4783c7be821e215ead515da3093a10f4a7baea9f803511a2c2b44a235: 1 bến cảng lông mao.cái đó/lông mi/lông mi:v1.11.1@sha256:251ff274acf22fd2067b29a31e9fda94253d2961c061577203621583d7e85bd2: 1 

Triển khai ứng dụng:

kubectl áp dụng -ứng dụng f.yaml 

Kiểm tra cuộc gọi dịch vụ sau khi ứng dụng được khởi động:

kubectl thực hiện tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing Tàu hạ cánh kubectl exec xwing -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing Tàu đã cập bến

Thực thi chính sách mạng L4:

kubectl áp dụng -lông mi/chính sách mạng-L4.yaml 

Đã cố gắng "hạ cánh" lên Death Star một lần nữa, nhưng máy bay chiến đấu xwing cũng không thể hạ cánh, cho thấy các quy tắc của lớp L4 đã có hiệu lực.

Hãy thử lại các quy tắc của lớp L7:

#lông mi/chính sách mạng-L7.yaml Phiên bản api: "cilium.io/v2" loại: CiliumNetworkPolicysiêu dữ liệu: tên: "quy tắc 1" đặc điểm kỹ thuật: Sự miêu tả: "Chính sách L7 hạn chế quyền truy cập vào cuộc gọi HTTP cụ thể" Bộ chọn điểm cuối: Nhãn phù hợp: tổ chức: lớp đế chế: sự xâm nhập của ngôi sao chết: - từĐiểm cuối: - Nhãn phù hợp: tổ chức: đế chế đếnCảng: - cổng: - cảng: "80" giao thức: Quy tắc TCP: http: - phương pháp: "BƯU KIỆN" con đường: "/v1/yêu cầu-đích" 

Quy tắc thực hiện:

kubectl áp dụng -lông mi/chính sách mạng-L7.yaml 

Lần này dùng tiefighter để gọi giao diện quản lý của Death Star:

kubectl thực hiện tiefighter -- curl -s -XPUT deathstar.default.svc.cluster.local/v1/exhaust-port Truy cập bị từ chối# Giao diện đăng nhập hoạt động bình thường kubectl exec tiefighter -- curl -s -XPOST deathstar.default.svc.cluster.local/v1/request-landing Tàu đã cập bến

Lần này Quyền truy cập bị từ chối đã được trả lại, cho biết các quy tắc của lớp L7 đã có hiệu lực.

Địa chỉ gốc: https://mp.weixin.qq.com/s/7ysmnPqnRY0JiOBhAO-o5w.

Cuối cùng, bài viết về việc sử dụng Cilium để tăng cường bảo mật mạng Kubernetes kết thúc tại đây. Nếu bạn muốn biết thêm về cách sử dụng Cilium để tăng cường bảo mật mạng Kubernetes, vui lòng tìm kiếm các bài viết về CFSDN hoặc tiếp tục duyệt các bài viết liên quan. blog tương lai! .