Tích hợp Istio với Cilium và bật mTLS tự động
Bước đầu tiên là cài đặt Istio trong chế độ Ambient Mesh (CNI) để tận dụng khả năng của Cilium và eBPF. Chế độ này loại bỏ Sidecar Proxy khỏi từng Pod, giảm độ trễ và tiêu thụ tài nguyên bằng cách chuyển logic mạng sang kernel thông qua eBPF.
Cài đặt Istio với mode CNI (Ambient Mesh) và kích hoạt tính năng tích hợp sẵn với Cilium.
istioctl install --set profile=ambient --set meshConfig.enableAutomaticSidecarInjection=false --set meshConfig.enableCNI=true -y
Command này sẽ triển khai các control plane của Istio (pilot, citadel, etc.) và cấu hình CNI plugin để Cilium quản lý traffic thay vì Envoy sidecar.
Kết quả mong đợi: Bạn sẽ thấy thông báo "Installation complete" và các resource trong namespace 'istio-system' được tạo ra, bao gồm các DaemonSet của CNI.
Chuyển đổi Pod sang chế độ Ambient
Sau khi cài đặt control plane, các Pod hiện có và mới tạo cần được đánh dấu (label) để Cilium nhận diện và xử lý traffic theo mô hình Ambient Mesh.
Áp dụng label 'istio.io/dataplane-mode=ambient' cho namespace chứa ứng dụng mẫu (giả sử namespace 'default' hoặc namespace ứng dụng của bạn).
kubectl label namespace default istio.io/dataplane-mode=ambient --overwrite
Label này báo cho Cilium biết rằng tất cả các Pod trong namespace này sẽ sử dụng cơ chế eBPF để xử lý mạng thay vì Sidecar Envoy.
Kết quả mong đợi: Command chạy thành công và namespace 'default' có thêm label istio.io/dataplane-mode=ambient.
Tái khởi động Pod để áp dụng cấu hình mới
Các Pod đã chạy trước khi thêm label sẽ không tự động nhận diện chế độ Ambient. Cần xóa và tái tạo chúng để Cilium inject logic eBPF.
kubectl rollout restart deployment --all -n default
Command này sẽ restart tất cả Deployment trong namespace default, buộc Pod mới khởi động với cấu hình Ambient Mesh.
Kết quả mong đợi: Các Pod mới được tạo sẽ có thêm Cilium interface (cni0) và không có container Envoy sidecar trong danh sách container của Pod.
Cấu hình PeerAuthentication để bật mTLS toàn cluster
Istio sử dụng PeerAuthentication để kiểm soát việc xác thực giữa các service. Trong mô hình Ambient Mesh, việc bật mTLS là bắt buộc để đảm bảo tính bảo mật và quan sát được lưu lượng qua Hubble/Kiali.
Tạo PeerAuthentication cho toàn Cluster
Để bật mTLS bắt buộc cho tất cả các giao tiếp trong cluster, ta cần tạo một PeerAuthentication scope toàn cục (cluster-wide).
Định nghĩa file YAML cấu hình PeerAuthentication với chế độ STRICT.
cat
Resource này đặt trong namespace 'istio-system' sẽ áp dụng cho toàn bộ cluster. Chế độ STRICT yêu cầu cả client và server phải sử dụng mTLS để giao tiếp.
Kết quả mong đợi: Resource PeerAuthentication 'default' được tạo thành công trong namespace 'istio-system'. Tất cả traffic nội bộ bắt buộc phải mã hóa.
Triển khai ứng dụng mẫu để kiểm tra bảo mật
Cần có ít nhất hai ứng dụng đơn giản (client và server) để xác minh việc thiết lập mTLS và Ambient Mesh hoạt động chính xác.
Triển khai Service mẫu
Sử dụng các manifest mẫu từ repository của Istio (bookinfo hoặc hello-service) để triển khai 2 Pod trong namespace đã được label Ambient.
Triển khai 2 service đơn giản: 'sleep' (client) và 'httpbin' (server) trong namespace default.
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/sleep/sleep.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/httpbin/httpbin.yaml
Các file YAML này sẽ tạo Deployment và Service cho ứng dụng. Do namespace default đã có label Ambient, các Pod này sẽ chạy không có Sidecar Envoy.
Kết quả mong đợi: 2 Deployment 'sleep' và 'httpbin' được tạo, trạng thái RUNNING, và số lượng container trong mỗi Pod chỉ là 1 (không có sidecar).
Xác minh chứng chỉ mTLS và cơ chế xác thực tự động
Bước cuối cùng là kiểm chứng rằng lưu lượng giữa các service đã được mã hóa và xác thực tự động thông qua chứng chỉ mTLS do Istio (Citadel) cấp phát.
Kiểm tra trạng thái mTLS qua Istioctl
Sử dụng lệnh 'istioctl' để xem trạng thái mTLS của các service trong cluster.
Lệnh kiểm tra chi tiết trạng thái mTLS cho service 'httpbin'.
istioctl analyze -n default
Lệnh này sẽ phân tích cấu hình mesh và báo cáo nếu có bất kỳ cảnh báo nào về việc không thể thiết lập mTLS.
Kết quả mong đợi: Không có cảnh báo (warning/error) liên quan đến PeerAuthentication hoặc mTLS. Thông báo "No problems found" hoặc các cảnh báo không liên quan đến bảo mật.
Xác minh giao tiếp qua curl trong Pod
Chạy lệnh curl từ Pod client ('sleep') đến Pod server ('httpbin') để xác nhận kết nối thành công. Trong chế độ STRICT, nếu không có mTLS, kết nối sẽ bị từ chối.
Thực thi lệnh curl từ bên trong Pod 'sleep' để gọi service 'httpbin'.
kubectl exec -n default deploy/sleep -- curl -s http://httpbin.default.svc.cluster.local/ip
Trong môi trường mTLS STRICT, việc gọi qua HTTP thuần túy (không mã hóa) sẽ bị từ chối hoặc tự động nâng cấp lên HTTPS tùy cấu hình, nhưng ở đây chúng ta kiểm tra xem kết nối có thành công qua mTLS hay không.
Kết quả mong đợi: Nếu mTLS hoạt động, bạn sẽ nhận được phản hồi JSON chứa địa chỉ IP. Nếu mTLS thất bại, bạn sẽ thấy lỗi "Connection refused" hoặc "503 Service Unavailable".
Xác minh chứng chỉ mTLS bằng s_client
Để chứng minh chắc chắn rằng giao tiếp được mã hóa bằng chứng chỉ mTLS, ta sử dụng openssl s_client để xem thông tin chứng chỉ.
Sử dụng openssl s_client để kiểm tra chứng chỉ của service 'httpbin' từ Pod 'sleep'. Cần cài đặt openssl trong container hoặc dùng container riêng, ở đây giả sử container sleep có openssl hoặc ta dùng kubectl exec với hình ảnh hỗ trợ.
kubectl run -n default test-curl --rm -it --image=curlimages/curl:latest -- sleep 1000
kubectl exec -n default test-curl -- openssl s_client -connect httpbin.default.svc.cluster.local:8080 -servername httpbin.default.svc.cluster.local
Command này kết nối trực tiếp qua port 8080 của service httpbin và yêu cầu xem chứng chỉ TLS. Istio sẽ tự động giao tiếp qua mTLS.
Kết quả mong đợi: Bạn sẽ thấy phần "Certificate chain" hiển thị chứng chỉ do 'istiod-ca' (Istio CA) cấp phát, và thông tin "Verify return code: 0 (ok)". Điều này xác nhận mTLS đã được thiết lập tự động giữa 2 service.
Kiểm tra Hubble (Optional nếu đã cài)
Nếu Cilium đã được cấu hình Hubble, ta có thể xác minh traffic được đánh dấu là encrypted.
Lệnh xem log traffic của Cilium cho kết nối giữa sleep và httpbin.
kubectl run -n default test-hubble --image=kindest/node:latest --restart=Never -- sleep 1000
# Sau đó xem log (giả sử hubble-relay đã chạy)
kubectl logs -n kube-system -l name=hubble-relay | grep -E "sleep|httpbin"
Hubble sẽ hiển thị trạng thái của gói tin. Trong chế độ mTLS, bạn sẽ thấy các gói tin được đánh dấu là "Encrypted" hoặc "TLS".
Kết quả mong đợi: Trong log của Hubble, các dòng traffic giữa sleep và httpbin hiển thị trạng thái "Encrypted: true" hoặc thông tin về phiên bản TLS (v1.2/v1.3).
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Service Mesh nội bộ an toàn với Istio, Cilium và eBPF trên Kubernetes để quản lý lưu lượng mạng, bảo mật và quan sát chi tiết
« Phần 2: Triển khai Cilium làm CNI và nền tảng eBPF
Phần 4: Quản lý lưu lượng mạng chi tiết với Istio Traffic Policies »