Cấu hình Service và Route cho API Backend
Tạo đối tượng Service trong Kong để định nghĩa backend API đích (giả sử là một dịch vụ internal chạy ở port 8080).
Việc này thiết lập điểm cuối mà Kong sẽ forward traffic đến sau khi xác thực thành công.
kubectl run kong-admin-api --image=kong:3.0 --port=8001 --port=8443 --expose --namespace=kong
Sau khi Pod chạy, expose service để truy cập từ bên ngoài cluster nếu cần, hoặc dùng port-forward để cấu hình.
kubectl port-forward svc/kong-admin-api 8001:8001 -n kong
Truy cập API Admin của Kong để tạo Service mới.
curl -i http://localhost:8001/services \
-X POST \
--data "name=secure-api-backend" \
--data "protocol=http" \
--data "host=backend-api-service.default.svc.cluster.local" \
--data "port=8080"
Kết quả mong đợi: HTTP 201 Created với JSON trả về chứa id của service vừa tạo. Lưu id này để dùng cho bước tạo Route.
Tạo Route và ánh xạ URL
Tạo Route để ánh xạ một đường dẫn cụ thể (ví dụ: /secure/*) tới Service đã tạo ở trên.
Đây là bước liên kết request của client vào luồng xử lý của Kong.
curl -i http://localhost:8001/routes \
-X POST \
--data "name=secure-api-route" \
--data "paths=/secure/*" \
--data "service=secure-api-backend" \
--data "strip_path=false"
Kết quả mong đợi: HTTP 201 Created. JSON trả về xác nhận Route đã gắn với Service và đường dẫn /secure/.
Gán Plugin mTLS và OPA vào Route
Cấu hình Plugin mTLS (mutual-tls) cho Route để yêu cầu client phải cung cấp chứng chỉ hợp lệ khi gọi API.
Plugin này sẽ từ chối connection ngay nếu client không gửi chứng chỉ hoặc chứng chỉ không được trust bởi CA của Kong.
curl -i http://localhost:8001/routes/secure-api-route/plugins \
-X POST \
--data "name=mutual-tls" \
--data "config.verify_cert=true" \
--data "config.verify_depth=1"
Tham số verify_depth=1 yêu cầu chứng chỉ client phải được ký trực tiếp bởi CA gốc đã cấu hình trong Kong (theo phần 3).
Kết quả mong đợi: HTTP 201 Created. Plugin mTLS đã được gắn vào Route.
Cấu hình Plugin OPA (Open Policy Agent)
Gắn Plugin OPA vào cùng Route để kiểm tra policy (chính sách) sau khi mTLS xác thực thành công.
Plugin này gọi OPA server để đánh giá request dựa trên các rule (ví dụ: chỉ cho phép IP cụ thể hoặc user role).
curl -i http://localhost:8001/routes/secure-api-route/plugins \
-X POST \
--data "name=opa" \
--data "config.url=http://opa-server.default.svc.cluster.local:8181/v1/data/api/secure" \
--data "config.timeout=5000"
Tham số url trỏ tới endpoint của OPA đã triển khai trong phần 4. Đảm bảo OPA đã có policy file tương ứng với đường dẫn /api/secure.
Kết quả mong đợi: HTTP 201 Created. Luồng xử lý bây giờ gồm: mTLS -> OPA -> Backend.
Tạo chứng chỉ Client cho người dùng thử nghiệm
Sử dụng OpenSSL để tạo Private Key và CSR (Certificate Signing Request) cho client giả lập.
Chứng chỉ này sẽ được dùng để test kết nối mTLS.
openssl genrsa -out client-test.key 2048
Đợi khi key được tạo, tạo file CSR từ key đó.
openssl req -new -key client-test.key -out client-test.csr -subj "/CN=test-user"
Sử dụng CA private key (đã tạo trong Phần 3) để ký cho CSR của client, tạo ra chứng chỉ hợp lệ.
openssl x509 -req -in client-test.csr -CA /etc/kong/certs/ca.crt -CAkey /etc/kong/certs/ca.key -CAcreateserial -out client-test.crt -days 365 -set_serial 01
Đảm bảo đường dẫn đến ca.crt và ca.key chính xác theo cấu hình trong Phần 3. Kết quả là file client-test.crt.
Thực hiện test API với các kịch bản
Kịch bản 1: Test kết nối hợp lệ với mTLS và Policy cho phép.
Sử dụng curl với tham số --cert và --key để gửi chứng chỉ client, gọi endpoint /secure/test.
curl -v https://kong-proxy:443/secure/test \
--cert /path/to/client-test.crt \
--key /path/to/client-test.key \
--cacert /path/to/ca.crt
Thay thế /path/to/ bằng đường dẫn thực tế trên máy client. Kết quả mong đợi: HTTP 200 OK nếu Policy cho phép, hoặc 403 Forbidden nếu Policy chặn.
Kịch bản 2: Test mTLS lỗi (không gửi chứng chỉ)
Thử gọi API mà không kèm tham số --cert và --key để kiểm tra Kong có từ chối kết nối hay không.
Mục đích là xác nhận plugin mTLS đang hoạt động và từ chối request thiếu chứng chỉ.
curl -v https://kong-proxy:443/secure/test \
--cacert /path/to/ca.crt
Kết quả mong đợi: HTTP 400 Bad Request hoặc 401 Unauthorized. Log của Kong sẽ ghi nhận lỗi "certificate required".
Kịch bản 3: Test Policy Deny (Chứng chỉ hợp lệ nhưng bị chặn bởi OPA)
Giả sử Policy OPA được cấu hình để từ chối user "test-user" (CN=test-user).
Gọi API với chứng chỉ hợp lệ nhưng OPA sẽ trả về deny.
curl -v https://kong-proxy:443/secure/test \
--cert /path/to/client-test.crt \
--key /path/to/client-test.key \
--cacert /path/to/ca.crt
Kết quả mong đợi: HTTP 403 Forbidden. Body response thường chứa thông báo từ OPA hoặc lỗi policy.
Verify kết quả cuối cùng
Kiểm tra trạng thái của các plugin đã cấu hình trong Kong Admin API.
curl http://localhost:8001/routes/secure-api-route/plugins
JSON trả về phải liệt kê 2 plugin: mutual-tls và opa với trạng thái enabled.
Kiểm tra logs của Kong Gateway để xem request đi qua luồng xử lý.
kubectl logs -f -n kong kong-proxy-xxxxx --tail=50
Logs sẽ hiển thị dòng: "access" với status code 200 (thành công), 400 (mTLS lỗi), hoặc 403 (Policy deny).
Kiểm tra logs của OPA để xem request policy đã được đánh giá chưa.
kubectl logs -f -n default opa-server-xxxxx --tail=20
Logs OPA sẽ hiển thị query decision và kết quả allow/deny tương ứng với request.
Đ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 4: Triển khai và tích hợp OPA (Open Policy Agent)
Phần 6: Tự động hóa chứng chỉ và quản lý vòng đời »