DPTCloud
Quay lại danh sách
Tin tức công nghệ

Kiến trúc truy cập cơ sở dữ liệu Zero Trust trong Kubernetes với SPIFFE/SPIRE và Vault

13 tháng 8, 2026

Kiến trúc truy cập cơ sở dữ liệu Zero Trust trong Kubernetes với SPIFFE/SPIRE và Vault

Giới thiệu

Trong các kiến trúc Cloud-Native truyền thống, các ứng dụng thường dựa vào các thông tin đăng nhập cơ sở dữ liệu có thời hạn dài (long-lived credentials) được lưu trữ trong biến môi trường (environment variables), tệp cấu hình, hoặc các trình quản lý secret tĩnh. Nếu kẻ tấn công xâm nhập được vào một Container duy nhất hoặc giành được quyền truy cập trái phép vào kho lưu trữ Git (Git repository), những thông tin đăng nhập tĩnh này sẽ cung cấp cho chúng khả năng di chuyển ngang (lateral movement) vô thời hạn trong hệ thống mạng nội bộ. Để giải quyết triệt để rủi ro này, các kiến trúc bảo mật doanh nghiệp hiện đại đang chuyển dịch mạnh mẽ sang mô hình Zero Trust (Không tin tưởng ai, luôn luôn xác thực).

Bằng cách kết hợp SPIFFE (Secure Production Identity Framework for Everyone), bản triển khai tham chiếu của nó là SPIRE, cùng với HashiCorp Vault, các tổ chức có thể loại bỏ hoàn toàn các secret tĩnh. Bài viết này sẽ đi sâu vào việc thiết kế kiến trúc và triển khai một hệ thống kiểm soát truy cập dựa trên danh tính (identity-driven access), tự động cấp phát các danh tính có thể xác minh bằng mã hóa mã nguồn và các thông tin đăng nhập cơ sở dữ liệu động có thời hạn cực ngắn trực tiếp trong thời gian chạy (runtime).

Lợi ích cốt lõi

Việc áp dụng mô hình Zero Trust thông qua SPIFFE/SPIRE và HashiCorp Vault mang lại những lợi ích vượt trội sau:

  • Loại bỏ thông tin đăng nhập tĩnh (Zero Static Credentials): Triệt tiêu hoàn toàn rủi ro lộ lọt mật khẩu hoặc API Key được mã hóa cứng trong mã nguồn hoặc tệp cấu hình.

  • Danh tính mật mã mạnh (Cryptographically Verifiable Identity): Workload được định danh bằng chứng chỉ SVID (X.509 hoặc JWT) có chữ ký số từ thực thể gốc đáng tin cậy, thay thế cho các phương pháp xác thực lỏng lẻo dựa trên địa chỉ IP hoặc Token tĩnh.

  • Thông tin xác thực động có thời hạn ngắn (Ephesmeral Dynamic Credentials): Cơ sở dữ liệu tự động tạo người dùng tạm thời với quyền hạn tối thiểu và tự động thu hồi (revoke) ngay khi hết thời gian tồn tại (TTL - Time-To-Live).

  • Khả năng kiểm toán toàn diện (End-to-End Auditability): Mọi hành vi truy vấn cơ sở dữ liệu đều có thể truy vết ngược lại chính xác tới một Pod, một Service Account hoặc một container cụ thể trong Kubernetes Cluster.

Kiến trúc & Thiết kế hệ thống

Nguyên tắc cơ bản của kiến trúc này là sự tách biệt hoàn toàn (decoupling) giữa danh tính của Workload và bản thân các secret. Thay vì sử dụng một Token tĩnh để lấy thông tin đăng nhập cơ sở dữ liệu, ứng dụng sẽ sử dụng danh tính mật mã được cấp phát động để xác thực với HashiCorp Vault.

[ Pod / Workload ] │ │ 1. Attest & Get SVID ▼ [ SPIRE Agent ] <─── 2. Node/Workload Attestation ───> [ SPIRE Server ] │ │ 3. Return SVID (JWT) ▼ [ Pod / Workload ] ─── 4. Auth with JWT SVID ────────> [ HashiCorp Vault ] │ │ 5. Create Temp User ▼ [ PostgreSQL ]

1. Lớp Định danh (Identity Layer - SPIFFE/SPIRE)

SPIRE Agent chạy như một DaemonSet trên mỗi Node trong Kubernetes Cluster. Khi một Pod (Workload) khởi chạy, nó sẽ giao tiếp với SPIRE Agent thông qua một Unix Domain Socket cục bộ (Workload API). SPIRE Agent sẽ thực hiện quá trình đối soát (attestation) để xác minh các thuộc tính runtime của Pod (như Namespace, Service Account, Pod UID, và Container Image ID) thông qua Kubernetes API Server. Sau khi xác thực thành công, SPIRE Server sẽ ký và cấp phát một SPIFFE Verifiable Identity Document (SVID) dưới dạng X.509 Certificate hoặc JWT Token cho Pod.

2. Lớp Quản lý Secret & Xác thực (Secret & Auth Layer - HashiCorp Vault)

HashiCorp Vault được cấu hình để tin tưởng thực thể phát hành OIDC/JWT của SPIRE. Khi nhận được yêu cầu đăng nhập từ Workload kèm theo JWT SVID, Vault sẽ kiểm tra chữ ký của Token này dựa trên các khóa công khai được công bố bởi SPIRE Server. Nếu hợp lệ, Vault sẽ ánh xạ SPIFFE ID của Workload vào một Policy cụ thể bên trong Vault.

3. Lớp Cơ sở dữ liệu (Database Layer - PostgreSQL/MySQL)

Vault sử dụng Database Secrets Engine để kết nối trực tiếp với cơ sở dữ liệu đích. Thay vì lưu trữ sẵn tài khoản, khi nhận được yêu cầu từ một Workload đã được xác thực, Vault sẽ thực thi một câu lệnh SQL mẫu để tạo ra một User hoàn toàn mới với mật khẩu ngẫu nhiên trên cơ sở dữ liệu, cấp quyền hạn giới hạn và đặt thời gian hết hạn (TTL) nghiêm ngặt (ví dụ: 15 phút). Khi hết TTL, Vault sẽ tự động xóa User này khỏi cơ sở dữ liệu.

Quy trình triển khai kỹ thuật

Để triển khai luồng công việc này, chúng ta cần cấu hình HashiCorp Vault để tin tưởng các JWT SVID do SPIRE cấp phát, ánh xạ SPIFFE ID của Workload tới một Vault Role cụ thể, và thiết lập Database Secrets Engine.

Bước 1: Cấu hình Vault JWT Auth Method

Đầu tiên, kích hoạt và cấu hình phương thức xác thực JWT trong Vault để tin tưởng OIDC discovery endpoint của SPIRE:

hcl

Cấu hình Vault JWT Authentication cho SPIRE

path "auth/jwt/config" { capabilities = ["create", "read", "update", "delete", "list"] }

Tạo một vai trò xác thực ánh xạ SPIFFE ID của Workload vào một Vault Policy

resource "vault_jwt_auth_backend_role" "spire_workload" { backend = "jwt" role_name = "payment-service-role" token_policies = ["payment-db-access"] bound_claims = { "sub" = "spiffe://example.org/ns/production/sa/payment-service-sa" } user_claim = "sub" role_type = "jwt" }

Bước 2: Cấu hình Database Secrets Engine cho PostgreSQL

Tiếp theo, kích hoạt Database Secrets Engine trong Vault để quản lý và tạo tài khoản động cho cơ sở dữ liệu PostgreSQL:

hcl

Kích hoạt database secrets engine

path "database/config/postgres-db" { capabilities = ["create", "read", "update"] }

Định nghĩa role động và cấu hình câu lệnh SQL mẫu để tạo user

path "database/creds/payment-db-role" { capabilities = ["read"] }

Cấu hình vai trò Vault (Vault Role) tương ứng cho PostgreSQL sẽ định nghĩa câu lệnh SQL động để tạo người dùng với các quyền hạn được phân tách rõ ràng:

CREATE USER "{{name}}" WITH PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO "{{name}}";

Bước 3: Luồng thực thi của ứng dụng tại thời điểm chạy (Runtime Flow)

Khi ứng dụng thanh toán (payment-service) khởi động trong Kubernetes, quy trình sau sẽ diễn ra tự động:

  1. Ứng dụng gửi yêu cầu tới SPIRE Agent thông qua Unix Domain Socket được gắn kết (mounted) vào Pod tại đường dẫn /run/spire/sockets/agent.sock để lấy JWT SVID.

  2. Ứng dụng gửi JWT SVID này đến endpoint /v1/auth/jwt/login của Vault để đổi lấy một Vault Client Token.

  3. Sử dụng Vault Client Token vừa nhận, ứng dụng gửi yêu cầu HTTP GET đến /v1/database/creds/payment-db-role.

  4. Vault tạo một tài khoản PostgreSQL mới (ví dụ: v-jwt-payment-se-xyz123), thiết lập thời hạn sử dụng là 15 phút, và trả thông tin đăng nhập (username/password) về cho ứng dụng.

  5. Ứng dụng kết nối tới cơ sở dữ liệu PostgreSQL bằng thông tin đăng nhập động này.

  6. Khi hết thời hạn 15 phút, nếu ứng dụng không thực hiện gia hạn (renew), Vault sẽ tự động thực thi lệnh DROP USER trên PostgreSQL để dọn dẹp tài khoản.

Khuyến nghị bảo mật doanh nghiệp

Triết lý Zero Trust yêu cầu danh tính phải được xác thực liên tục và các đặc quyền phải hết hạn nhanh nhất có thể nhằm giảm thiểu tối đa phạm vi ảnh hưởng khi xảy ra sự cố bảo mật (blast radius).

  • Siết chặt các bộ chọn đối soát (Attestation Selectors): Không nên chỉ dựa vào các bộ chọn ở cấp độ Namespace trong SPIRE. Hãy áp dụng các điều kiện kiểm tra nghiêm ngặt bao gồm k8s:container-image, k8s:sa (Service Account), và k8s:pod-uid để đảm bảo chỉ có tệp nhị phân chính xác và đáng tin cậy mới có thể lấy được SPIFFE ID tương ứng.

  • Thiết lập TTL ngắn tối đa: Định cấu hình TTL cho thông tin đăng nhập động ở mức tối thiểu phù hợp với bối cảnh hoạt động của ứng dụng (ví dụ: từ 5 đến 15 phút). Đồng thời, hãy triển khai cơ chế tự động gia hạn (auto-renewal loops) trong mã nguồn của ứng dụng để làm mới thông tin đăng nhập trước khi chúng hết hạn.

  • Tích hợp kiểm toán và liên kết log (Correlated Logging): Đảm bảo tất cả audit log từ HashiCorp Vault và PostgreSQL được chuyển tiếp về hệ thống SIEM tập trung. Vì tên người dùng được tạo động bởi Vault có chứa mã định danh giao dịch (transaction ID) của Vault, đội ngũ bảo mật có thể dễ dàng truy vết bất kỳ câu lệnh SQL đáng ngờ nào ngược lại chính xác thực thể Pod và SPIFFE ID đã yêu cầu cấp quyền đó.

Kết luận

Chuyển dịch từ việc sử dụng các secret tĩnh sang mô hình danh tính động được xác thực bằng mật mã là một bước tiến quan trọng trong bảo mật Cloud-Native hiện đại. Bằng việc kết hợp sức mạnh của SPIFFE/SPIRE và HashiCorp Vault, doanh nghiệp có thể thiết lập một mô hình truy cập cơ sở dữ liệu Zero Trust có độ tin cậy và khả năng phục hồi cao. Kiến trúc này không chỉ loại bỏ hoàn toàn các rủi ro liên quan đến rò rỉ thông tin đăng nhập cố định, giới hạn vòng đời của thông tin xác thực, mà còn cung cấp cho các kỹ sư nền tảng (Platform Engineering) khả năng kiểm soát chặt chẽ, minh bạch đối với các kho lưu trữ dữ liệu quan trọng phía backend.