HashiCorp Vault: quản lý secrets và mã hóa
/vault
HashiCorp Vault là một secrets manager chạy dạng server, tập trung API key, thông tin xác thực database và encryption key vào một điểm truy cập có kiểm soát và có audit log. Vault đáng dùng khi có nhiều hơn vài hệ thống chia sẻ secrets thủ công: lease-and-revoke tốt hơn nhét credentials vào file config, dù bạn phải vận hành thêm một service chứ không chỉ import thư viện.
Vì sao bạn cần một công cụ quản lý secrets chuyên dụng
Mỗi service trong một hệ thống hiện đại đều cần credentials riêng: mật khẩu database ở đây, AWS key ở kia, chứng chỉ TLS ở chỗ khác. Mặc định, chúng nằm bất cứ đâu mà người viết deploy script để chúng: một file .env, một CI secret store, hay một tin nhắn Slack từ nhiều năm trước. Xoay vòng (rotate) bất kỳ secret nào cũng có nghĩa là phải tìm ra mọi nơi nó bị hardcode, còn thu hồi quyền truy cập sau sự cố lại có nghĩa là phải đoán xem người hoặc service đó có thể chạm tới những secrets nào. Vault ra đời vì phần lớn team không thể trả lời được câu hỏi 'secrets nào đang tồn tại, ai đọc được, khi nào hết hạn' nếu không có một hệ thống chuyên trách theo dõi việc đó. Đó chính là khoảng trống Vault lấp vào.
Vault: quản lý secrets và mã hóa hợp nhất
Vault là công cụ của HashiCorp dùng để lưu trữ, sinh ra và kiểm soát quyền truy cập vào secrets như API key, thông tin xác thực database, chứng chỉ và encryption key. Vault đưa mọi secrets qua một API thống nhất thay vì để chúng rải rác trong file config, biến môi trường, hay các kho lưu trữ riêng lẻ của từng team, và mỗi lần đọc secrets đều được kiểm soát quyền truy cập và ghi vào audit log.
Các tính năng cốt lõi của Vault
- ✓Lưu trữ secrets an toàn: Vault mã hóa dữ liệu key/value trước khi ghi xuống đĩa, nên chỉ có quyền truy cập vào storage thô cũng không đủ để đọc secrets. Vault có thể ghi vào đĩa local, vào Consul, hoặc các backend khác.
- ✓Dynamic secrets: thay vì lưu một mật khẩu AWS hay database tồn tại mãi mãi, Vault sinh secrets theo yêu cầu. Khi một app xin quyền truy cập S3, Vault tạo một AWS keypair mới có quyền giới hạn và tự thu hồi nó khi lease hết hạn.
- ✓Encryption as a service: Vault có thể mã hóa và giải mã dữ liệu mà không cần lưu trữ dữ liệu đó, nên một team có thể đẩy logic mã hóa vào Vault thay vì tự viết crypto trong app rồi ghi vào database SQL.
- ✓Leasing và renewal: mỗi secret Vault cấp ra đều đi kèm một lease. Client renew lease đó qua API renew có sẵn trước khi hết hạn; nếu không ai renew, Vault tự thu hồi.
- ✓Revocation, kể cả thu hồi hàng loạt: Vault có thể thu hồi một secret đơn lẻ hoặc cả một cây secrets cùng lúc, mọi secret một user cụ thể từng chạm tới, hoặc mọi secret thuộc một loại, điều này quan trọng khi cần khóa hệ thống lại sau một vụ xâm nhập.
Bạn có thể làm gì với Vault
- •Ngừng hardcode mật khẩu database và API key vào config của app, để service lấy chúng từ Vault ngay lúc chạy.
- •Cấp AWS credentials ngắn hạn cho từng request thay vì dùng chung một IAM key tồn tại mãi mà không bao giờ được xoay vòng.
- •Mã hóa dữ liệu ứng dụng, ví dụ các field ghi vào database SQL, bằng cách gọi API mã hóa của Vault thay vì tự quản lý thư viện crypto riêng.
- •Theo dõi chính xác ai đã đọc secret nào, vào lúc nào, qua audit log của Vault, phục vụ compliance hoặc điều tra sự cố.
- •Thu hồi mọi secret mà một service hoặc user bị xâm nhập có thể chạm tới, chỉ trong một thao tác, sau một sự cố bảo mật.
Chạy Vault trên máy local
Theo README, chạy Vault ở local nghĩa là build từ source cho môi trường dev, chứ không phải tải một bản release đóng gói sẵn: cài Go, thiết lập GOPATH và GOBIN, rồi clone repo hashicorp/vault ra ngoài GOPATH (Vault dùng Go Modules). Chạy `make bootstrap` một lần để tải build tooling, sau đó `make dev` để build ra bản dev binary vào `bin/vault`. Nếu muốn có cả web UI, chạy `make static-dist dev-ui` thay vào đó. Chạy bộ test đầy đủ (`make test`) cần có Docker. README không mô tả cách cài qua binary đóng gói hay qua package manager ngoài hướng build dev này.
Cách ứng dụng lấy secrets từ Vault
Một application nói chuyện với Vault qua API thay vì đọc secrets từ file: nó authenticate, xin thứ nó cần (ví dụ credentials cho S3), và Vault trả về giá trị cùng một lease mà app phải renew qua API renew có sẵn trước khi lease hết hạn. Riêng với Go, HashiCorp publish package github.com/hashicorp/vault/api như một client library có thể import được; lưu ý import thẳng module hashicorp/vault chính là cách dùng không được hỗ trợ. Với các ngôn ngữ khác, README trỏ tới repo vault-examples riêng và một sample app tên hello-vault-go; ngoài hai chỗ đó, README của repo này không nói rõ cách dùng theo từng ngôn ngữ.
Điểm mạnh
- ✓Dynamic secrets cộng với auto-revoke nghĩa là một AWS credential bị lộ sẽ tự hết hạn thay vì sống mãi trong một file config.
- ✓Một audit log duy nhất cho mọi lượt đọc secrets, ở mọi backend, thay vì phải ráp log riêng lẻ từng service lại sau sự cố.
- ✓Encryption as a service giúp team tập trung chính sách mã hóa một chỗ, thay vì để từng service tự viết code mã hóa riêng.
- ✓Đi kèm client library cho Go (github.com/hashicorp/vault/api), nên nối một service Go vào Vault không cần tự viết HTTP client thô.
Giới hạn của Vault
- △README chỉ mô tả cách build từ source cho dev (Go + make); không có binary đóng gói sẵn, công thức brew, hay đường cài qua apt được mô tả trong docs của repo.
- △Module Go chính hashicorp/vault không được thiết kế để import vào project khác, chỉ có hai package api và sdk là dùng được; README cảnh báo rõ ràng không nên phụ thuộc trực tiếp vào toàn bộ module.
- △Một số tính năng nằm trong Vault Enterprise chứ không có ở bản mã nguồn mở mà README này mô tả, nên bản miễn phí sẽ không có mọi tính năng bạn đọc thấy trên trang HashiCorp.
- △Trường license của repo này không được nêu rõ trong các fact có sẵn ở đây, nên hãy kiểm tra file LICENSE của chính repo trước khi phụ thuộc vào Vault trong một sản phẩm thương mại.
- △Chạy hết bộ test, đặc biệt là acceptance test, cần Docker, và theo cảnh báo của chính README, acceptance test có thể tạo và xóa tài nguyên cloud thật, tức là tốn tiền thật nếu không cẩn thận.
Các lựa chọn thay thế cho HashiCorp Vault
Câu hỏi thường gặp về Vault
Source code của Vault được công khai trong repo GitHub hashicorp/vault, và HashiCorp cũng bán riêng một bản Vault Enterprise trả phí với thêm tính năng. Điều khoản license chính xác cho bản mã nguồn mở không được nêu rõ trong các fact công khai ở đây, nên hãy kiểm tra file LICENSE của chính repo trước khi dùng Vault trong một sản phẩm thương mại.
Vault lưu được secrets dạng key/value tùy ý, có thể sinh dynamic credentials theo yêu cầu cho các hệ thống như AWS hay database SQL, và cung cấp encryption as a service để app mã hóa và giải mã dữ liệu mà Vault không bao giờ lưu bản plaintext. Mỗi secret Vault cấp ra đều đi kèm một lease mà Vault có thể tự renew hoặc thu hồi.
Vault tập trung secrets bên ngoài một cluster cụ thể và có thêm những thứ mà object Secrets có sẵn của Kubernetes không tự có: dynamic credentials ngắn hạn sinh theo yêu cầu, lease tự hết hạn và tự thu hồi, cùng một audit log duy nhất cho mọi lượt đọc secrets. Kubernetes Secrets dễ dùng ngay hơn nhưng không tự sinh hay tự xoay vòng credentials cho bạn.
Có, Vault sinh được AWS credentials theo yêu cầu: khi một application cần quyền truy cập, ví dụ vào một S3 bucket, nó xin Vault, Vault tạo một AWS keypair mới chỉ có đúng quyền cần thiết, và tự thu hồi keypair đó ngay khi lease liên quan hết hạn.
HashiCorp publish package github.com/hashicorp/vault/api như một client library cho Go, dùng riêng để giao tiếp với một Vault server đang chạy; lưu ý import thẳng module chính hashicorp/vault không phải cách dùng được hỗ trợ. Để có ví dụ thực tế bằng Go và các ngôn ngữ khác, HashiCorp duy trì một repo riêng tên vault-examples và một sample app tên hello-vault-go.
Có, HashiCorp publish một image Docker chính thức tên hashicorp/vault, được chính tooling test Docker-based của project tham chiếu tới trực tiếp, mặc định dùng tag 'latest'. Cùng tooling đó cũng hỗ trợ một image riêng tên hashicorp/vault-enterprise dành cho team dùng bản trả phí.
Nên dùng Vault khi nào — và khi nào nên bỏ qua
Những team đang chạy nhiều hơn một vài service, mỗi service cần mật khẩu database, API key hay chứng chỉ riêng, là nhóm cảm nhận rõ nhất vấn đề mà Vault giải quyết; một khi credentials đã rải rác trong cả chục file config, một kho tập trung có lease và audit log sẽ đáng công sức bỏ ra. Một app nhỏ chỉ có vài secrets thì không cần: bỏ chúng vào secret store có sẵn của cloud provider, hoặc một biến môi trường được bảo vệ tốt, vẫn đỡ tốn công vận hành hơn dựng và duy trì một cluster Vault. Nếu bạn chưa sẵn sàng chạy và vá thêm một stateful service nữa, hãy bỏ qua Vault cho tới khi số lượng secrets thực sự gây đau đầu.
Repo liên quan
Vẫn đang phân vân về vault?
Một cú bấm sẽ gửi câu hỏi kèm trang này cho AI — xem AI nói gì về vault.