Yêu cầu phần cứng và phiên bản Kubernetes
Cấu hình tối thiểu cho Cluster
Để đảm bảo hiệu năng khi chạy Kong Gateway, OPA và xử lý mTLS, cluster Kubernetes cần đáp ứng các thông số sau. Kiến trúc này yêu cầu tài nguyên cho các pod xử lý request và policy evaluation.
Yêu cầu tối thiểu cho một node (hoặc tổng cluster nếu dùng single-node):
- CPU: Tối thiểu 4 Core (Khuyến nghị 8 Core cho production).
- RAM: Tối thiểu 8GB (Khuyến nghị 16GB để OPA và Kong chạy mượt).
- Disk: 50GB SSD (cho logs, ephemeral storage và image cache).
- OS: Linux (Ubuntu 20.04+, CentOS 8+, Rocky Linux 8+).
Phiên bản Kubernetes bắt buộc từ v1.25 trở lên để tận dụng các tính năng mới của API server và CRD cần thiết cho Cert-Manager.
Verify phiên bản Kubernetes
Thực hiện lệnh sau để kiểm tra phiên bản của cluster hiện tại. Kết quả phải hiển thị version >= v1.25.
kubectl version --short
Kết quả mong đợi: Dòng "Kubernetes v1.25.x" hoặc cao hơn. Nếu thấp hơn, bạn cần upgrade cluster trước khi tiếp tục.
Cài đặt và cấu hình công cụ quản lý
Cài đặt kubectl
Công cụ dòng lệnh để tương tác với Kubernetes API. Chúng ta sẽ tải binary chính chủ từ kho chứa của Google.
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/
Kết quả mong đợi: File kubectl được di chuyển vào thư mục bin hệ thống và có quyền thực thi.
Cài đặt Helm (v3)
Helm là package manager để triển khai các ứng dụng phức tạp như Kong và Cert-Manager dưới dạng Chart. Chúng ta cần Helm version 3.x.
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | HELM_INSTALL_DIR=/usr/local/bin HELM_VERSION=v3.13.0 HELM_BINARY_NAME=helm HELM_PLUGINS=helm-plugins bash -
Kết quả mong đợi: Thông báo "Helm has been installed" và file helm nằm trong /usr/local/bin.
Verify Helm
Chạy lệnh để kiểm tra phiên bản Helm đã cài.
helm version
Kết quả mong đợi: Hiển thị version >= v3.13.0.
Cài đặt Cert-Manager
Cert-Manager là thành phần bắt buộc để tự động hóa việc cấp phát và gia hạn chứng chỉ mTLS cho Kong và OPA. Chúng ta sẽ deploy qua Helm chart chính thức.
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.14.0 --set installCRDs=true
Kết quả mong đợi: Helm báo "Release 'cert-manager' has been installed".
Verify Cert-Manager
Đợi khoảng 60-90 giây để các pod của Cert-Manager khởi động xong. Sau đó kiểm tra trạng thái.
kubectl get pods -n cert-manager
Kết quả mong đợi: Tất cả pod (cert-manager, cainjector, webhook) đều ở trạng thái Running với restart count bằng 0.
Tổng quan kiến trúc Secure API Gateway
Thẻ hệ thống (Architecture Overview)
Trong series này, chúng ta xây dựng một kiến trúc 3 lớp bảo mật chặt chẽ. Luồng traffic sẽ đi qua các thành phần sau theo thứ tự:
- Client (Mô tả): Ứng dụng phía khách hàng (Mobile, Web, hoặc Service nội bộ). Client sẽ thực hiện mTLS handshake bằng chứng chỉ riêng của nó.
- Kong Gateway (Lớp 1): Đóng vai trò là Reverse Proxy và Entry Point. Nó thực hiện việc xác thực chứng chỉ Client (Client Certificate Authentication). Nếu hợp lệ, request mới được chuyển tiếp.
- OPA (Open Policy Agent - Lớp 2): Đóng vai trò là Policy Decision Point. OPA nhận request đã được xác thực từ Kong, kiểm tra các rule (ví dụ: "Client A chỉ được phép gọi Endpoint B trong giờ hành chính"). OPA trả về Allow hoặc Deny.
- Backend Service (Lớp 3): Microservice thực tế. Chỉ nhận request từ Kong nếu OPA phê duyệt.
Kiến trúc này tách biệt Authentication (ai là người gọi - mTLS) khỏi Authorization (người đó được làm gì - OPA Policy).
Vai trò của mTLS trong kiến trúc
mTLS (Mutual TLS) không chỉ là bảo mật kênh truyền tải (Server Auth) mà còn là cơ chế xác thực (Client Auth). Trong luồng này:
- Server Cert: Kong Gateway dùng chứng chỉ này để Client tin tưởng khi kết nối.
- Client Cert: Client dùng chứng chỉ này để chứng minh danh tính cho Kong Gateway.
Kong sẽ cấu hình plugin tls-auth để từ chối mọi request không có chứng chỉ hợp lệ hoặc chứng chỉ không nằm trong trust store (CA) đã định nghĩa.
Vai trò của OPA
Kong tích hợp với OPA thông qua plugin OPA. Thay vì hardcode logic vào config của Kong, OPA chạy độc lập (thường dùng sidecar hoặc service riêng) và đánh giá request dựa trên file policy viết bằng ngôn ngữ Rego. Điều này cho phép DevOps và Security Team cập nhật rule mà không cần restart Kong.
Kế hoạch triển khai chứng chỉ mTLS
Chiến lược quản lý chứng chỉ (Certificate Strategy)
Chúng ta sẽ sử dụng Cert-Manager để tự động hóa toàn bộ vòng đời chứng chỉ. Không tạo file .pem thủ công. Chiến lược chia làm 2 nhóm:
- Root CA (Self-Signed): Tạo một CA nội bộ để ký cho tất cả các chứng chỉ trong cluster. Đây là trust anchor.
- Server Certificate: Chứng chỉ dùng cho Kong Gateway (dành cho OPA và Backend). Tên miền sẽ là
kong-gateway.example.com.
- Client Certificates: Chứng chỉ dùng cho các client service. Mỗi client sẽ có một
Certificate resource riêng được ký bởi Root CA.
Thiết lập Root CA nội bộ
Bước đầu tiên là tạo một ClusterIssuer sử dụng backend selfSigned để đóng vai trò là Root CA. Cert-Manager sẽ tự động tạo key và cert cho CA này.
Đường dẫn config file: /etc/k8s-config/issuer-root-ca.yaml
cat > /etc/k8s-config/issuer-root-ca.yaml
Kết quả mong đợi: File được tạo. Sau khi apply, Cert-Manager sẽ tạo secret selfsigned-ca-cert trong namespace cert-manager chứa ca.crt và ca.key.
Apply Root CA vào Cluster
Đẩy cấu hình Root CA vào Kubernetes để Cert-Manager bắt đầu tạo chứng chỉ gốc.
kubectl apply -f /etc/k8s-config/issuer-root-ca.yaml
Kết quả mong đợi: ClusterIssuer created và Certificate created.
Verify Root CA
Chờ 10-20 giây rồi kiểm tra secret đã được tạo chưa.
kubectl get secret selfsigned-ca-cert -n cert-manager -o yaml | grep data
Kết quả mong đợi: Có trường ca.crt và ca.key trong phần data (được base64 encode).
Kế hoạch cho Server Certificate (Kong Gateway)
Trong Phần 2, chúng ta sẽ tạo một Certificate resource mới. Certificate này sẽ dùng selfsigned-ca (mà vừa tạo ở trên) làm Issuer. Điều này đảm bảo chứng chỉ của Kong Gateway được ký bởi CA nội bộ của chúng ta, tạo thành một chuỗi tin cậy.
Cấu trúc dự kiến cho Server Cert:
- Issuer: selfsigned-ca
- Common Name: kong-gateway.example.com
- IP Addresses: IP của LoadBalancer hoặc NodePort (tùy cách expose)
- Usages: server auth, client auth (để Kong cũng có thể dùng làm client khi gọi OPA nếu cần mTLS nội bộ).
Kế hoạch cho Client Certificates
Mỗi microservice hoặc client application sẽ có một Certificate riêng. Chúng ta sẽ tạo template để tự động hóa việc này. Trong Phần 3 và 5, chúng ta sẽ cấu hình Kong để trust vào Root CA này và yêu cầu client xuất trình chứng chỉ.
Yêu cầu kỹ thuật cho Client Cert:
- Issuer: selfsigned-ca
- Common Name: Tên service (ví dụ:
payment-service, mobile-app)
- Usages: client auth
- Secret: Chứa
tls.crt và tls.key để mount vào container của client.
Việc này đảm bảo khi client mount secret này vào container, chúng ta có ngay cặp key/cert hợp lệ để thực hiện mTLS handshake với Kong Gateway.
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Secure API Gateway với Kong, OPA và mTLS trên Kubernetes
Phần 2: Triển khai Kong Gateway trên Kubernetes »