Vault
Last updated
Last updated
Vault hoạt động như một ứng dụng client-server
Sử dụng cờ -help để liệt kê các tùy chọn có sẵn cho vault server
Khởi động Vault server trong chế độ development (dev server). Dev server là một máy chủ tích hợp, được cấu hình sẵn, không an toàn nhưng hữu ích khi thao tác với local Vault.
Chạy một cửa sổ terminal mới
Chạy lệnh sau để cấu hình máy Vault client giao tiếp với máy Dev . Vault CLI xác đinh Vault server nào sẽ gửi yêu càu bằng cách sử dụng biến môi trường VAULT_ADDR
Đặt giá trị biến môi trường VAULT_TOKEN thành Root Token đã được tạo trong bước Khởi động Dev server.
export VAULT_TOKEN="hvs.XHApczAxj0bqP115hfdxx3eM"
Xác minh máy chủ đang chạy bằng cách chạy dưới đây . Nếu lệnh thành công, đầu ra sẽ như sau:
Khi vault chạy ở Dev mode, Key/Value V2 secret engine được bật tại đường dẫn secret/ . Key/Value secret engine là một kho lưu trữ khóa và giá trị chung được sử dụng để lưu trữ các bí mật tùy ý trong bột lưu trữ vật lí đã được cấu hình cho Vault. Các bí mật được ghi vào Vault được mã hóa và sau đó được ghi vào Storage Backend. Do đó, cơ chế backend storastorage không bao giờ nhìn thấy giá trị không được mã hóa.
Bạn có thể tương tác với công cụ bí mật key/value bằng cách sử dụng lệnh vault kv
Bây giờ viết bí mật key-value vào đường dẫn hello với khóa là foo và giá trị là world. Sử dụng lẹnh vault kv put đối với đường dẫn mount secret, đây là nơi công cụ bí mật KV v2 được gắn kết. Lệnh này tạo một phiên bản mới của các bí mật và thay thế mọi dữ liệu đã tồn tại trước đó tại đường dẫn này nếu có.
-mount=string: chỉ định đường dẫn mà KV backend được mounted. Nếu được chỉ định, đối số tiếp theo sẽ được hieeur là đường dẫn bí mật. Nếu cờ này không được chỉ định, đối số tiếp theo sẽ được hiểu là đường dẫn gắn kết và đường dẫn bí mật kết hợp với /data/ được tự động được thêm vào giữ bí mật KV v2
Các bí mật có thể được truy xuất bằng vault kv get
Để chỉ in giá trị của một trường duy nhất định, hãy sử dụng cờ: -field=<key_name>
Sử dụng lệnh vault kv delete
Chú ý: tham số destroyed có giá trị false nghĩa là có thể khôi phục dữ liệu đã xóa nếu việc xóa là không có chủ ý.
Định nghĩa: Secret engine là thành phần của Vault lưu trữ, tạo hoặc mã hóa bí mật.
Để bắt đầu, bật secret engine KV mới tại path kv. Mỗi path hoàn toàn bị cô lập và không thể talk với những path khác. Ví dụ: secret engine KV được tạo tại foo không có khả năng giao tiếp với secret engine KV tại bar
Kết quả cho thấy có 5 secret engines được kích hoạt trên máy chủ này.
Để tạo bí mật, sử dụng lệnh kv put:
Để đọc các bí mật được lưu trữ rong đường dẫn kv/hello, sử dụng lệnh kv get:
Tạo bí mật tại đường dẫn: kv/my-secret
Đọc những bí mật tại đường dẫn: kv/my-secret
Không giống như các bí mật kv (dữ liệu phải tự đưa vào store) các bí mật động được tạo khi chúng được truy cập.
Bí mật động không tồn tại cho đến khi chúng được đọc, vì vậy không có nguy cơ ai đó đánh cắp chúng hoặc khách hàng khác sử dụng cùng bí mật. Vì Vault có các cơ chế thu hồi tích hợp, các bí mật động có thể được thu hồi ngay sau khi sử dụng, điều này giảm thiểu thời gian bí mật tồn tại.
Không giống như kv là được bật theo mặc , AWS secrets engine phải được bật trước khi sử dụng. Bước này thường được thực hiện thông qua một hệ thống quản lí cấu hình.
Đang cập nhật
Mã xác thực token được bật tự động. Khi khởi động Dev , đầu ra hiển thị root . Vault CLI đọc root token từ biến môi trường $VAULT_TOKEN. Root token này có thể thực hiện bất kì hoạt động nào trong Vault vì nó được chỉ định root policy.
Create a new token
Token đã tạo được hiển thị dưới dạng: hvs.Ve8Iqi6JvD5gswYqMh55LadG
Mã thông báo này là mã con của root token và theo mặc định, mã này kế thừa các chính sách từ mã gốc của .
Token là phương thức xác thực cốt lõi. Có thể sử dụng mã thông báo đã tạo để đăng nhập Vault bằng cách sao chép và dán token khi được nhắc
Chú ý: Mỗi token Vault là duy nhất. Khi một mã token không còn cần thiết, nó có thể bị thu hồi. Ví dụ:
Mã token bị thu hồi và không còn giá trị sử dụng.
Để xác thực, Vault có nhiều tùy chọn hoặc phương pháp có thể được kích hoạt và sử dụng. Vault luôn sử dụng cùng một định dạng cho cả ủy quyền và chính sách. Tất cả các phương thức xác thực ánh xạ danh tính return các chính sách cốt lõi được định cấu hình với Vault.
Các chính sách được viết bằng HCL nhưng tương thích với JSON. Ví dụ:
Giải thích: với chính sách này, người dùng có thể ghi bất kì bí mật nào vào secret/data/, ngoại trừ vào secret/data/foo (chỉ cho phép đọc). Các chính sách mặc định là từ chối, vì vậy mọi quyền truy cập vào một đường dẫn không xác định đều không được phép.
Tất cả mọi thứ trong Vault phải được truy cập thông qua API, điều này mang lại quyền kiểm soát chặt chẽ đối với mọi khía cạnh của Vault (bật công cụ bí mật, bật phương thức xác thực, quyền truy cập bí mật....)
Có một số chính sách tích hợp không thể xóa được. Ví dụ như chính sách root, và default là các chính sách bắt buộc và không thể xóa được. Chính sách default cung cấp một tập hợp các quyền chung và được bao gồm trên tất cả các token mặc định. Chính sách root cung cấp cho người dùng mã token với quyền siêu quản trị viên.
Sử dụng lệnh vault policy write để viết một chính sách.
Tạo một policy có tên là my-policy với nội dụng từ stdin:
Liệt kê những chính sách hiện có:
Tạo token, thêm chính sách my-policy và đặt ID mã token làm giá trị của biến môi trường VAULT_TOKEN để sử dụng sau này.
Chính sách này cho phép tạo và cập nhật cho mọi đường dẫn trong secret/ ngoài trừ một đường dẫn.
Viết bí mật cho đường dẫn secret/data/creds
Chính sách chỉ cho phép cho đường dẫn secret/data/foo. Mọi nỗ lực ghi vào đường dẫn này đều bị từ chối.
Đang cập nhật
Vault được định cấu hình bằng tệp HCL. Tạo cấu hình Vault trong tệp config.hcl
Trong tệp cấu hình này có 2 cấu hình chính:
storage: là physical backend mà Vault sử dụng để lưu trữ. Cho đến thời điểm này, Dev server đã sử dụng "inmem".
listener: một hoặc nhiều trình lắng nghe xác định cách Vault lắng nghe các yêu cầu API. Ví dụ trên lắng nghe trên cổng 8200 của máy chủ cục bộ không có TLS.
api_addr: chỉ định địa chỉ để thông báo cho route yêu cầu của khách hàng.
cluster_addr: cho biết địa chỉ và cổng sẽ được sử dụng để liên lạc giữa các node Vault trong 1 cụm.
ThThe ./vault/data directory that raft storage backend uses must exist.
Đặt cờ -config để trỏ đến dường dẫn mà đã lưu cấu hình config.hcl trước đó:
Vault xuất thông tin chi tiết về cấu hình của nó, sau đó block
Mở phiên làm việc mới và chạy lệnh sau:
export VAULT_ADDR='http://127.0.0.1:8200'
Để khởi tạo Vault, sử dụng vault operator init. Đây là yêu cầu chưa được xác thực, nhưng nó chỉ hoạt động trên các Vault hoàn toàn mới mà không có dữ liệu hiện có:
Giải thích: Quá trình khởi tạo cho 2 thông tin quan trọng: unseal key và root token. Tuy nhiên đây là lần duy nhất mà Vault cho các unseal key gần nhau đến vậy. Nhưng trong thực tế, không lưu tập trung các khóa này cùng nhau. Thay vào đó có thể sử dụng PGP và Keybase.io của Vault để mã hóa từng khóa này bằng khóa PGP của người .
Mọi máy chủ Vault khởi chạy đều bắt đầu ở trạng thái SEAL. Từ cấu hình, Vault có thể truy cập physical storage nhưng không thể đọc bất kì bộ nhớ nào vì không biết cách giải mã. Quá trình hướng dẫn Vault cách giải mã dữ liệu được gọi là unseal
Việc unseal phải diễn ra mỗi khi Vault khởi động. Nó có thể được thực hiện thông qua API và thông qua dòng lệnh. Để unseal Vault, phải có số lượng unseal key đạt ngưỡng đồng thuận. Ví dụ trong cấu hình trên, phải có 3/5 khóa unseal thì mới hủy "niêm phong" Vault được.
Mở "niêm phong" Vault:
Giá trị sealed trở thành false. Vault được mở niêm phong.
Xác thực với root key:
Là một người dùng root có thể niêm phong lại Vault bằng lệnh: vault operator seal.
Các máy cần quyền truy cập vào thông tin được lưu trong Vault rất có thể sẽ truy cập thông qua REST API của nó.
Ví dụ: nếu một máy đang sử dụng AppRole để xác thực, trước tiên, ứng dụng sẽ xác thực với Vault, ứng dụng này trả về Vault API token. Ứng dụng sẽ sử dụng token đó để liên lạc với vault trong tương lai.
Tạo cấu hình máy chủ: config.hcl
TLS bị tắt ở đây với mục đích ví dụ.
Bắt đầu phiên làm việc Vault mới:
Khởi chạy Vault bằng API:
Sử dụng khóa unseal ở trên, có thể hủy niêm phong Vault thông qua API HTTP
Gọi API Vault để xác thực trạng thái khởi tạo:
Giờ đây, bất kì phương thức xác thực có sẵn nào cũng có thể được bật và định cấu hình.
Bật phương thức xác thực AppRole bằng cách gọi API Vault
Tạo chính sách thông qua API Vault:
Bật công cụ bí mật KV v2 khi sử dụng API secret/
Lệnh dưới dây chỉ định rằng các mã token dược phát hành trong AppRole my-role phải được liên kết với my-policy
Phương thức xác thực AppRole yêu cầu một RoleID và SecretID làm đầu vào. RoleID tương tự như tên người dùng và SecretID có thể được coi là mật khẩu của RoleID
Lệnh dưới đây để lấy RoleID của role name my-role:
Tạo một SecretID mới:
Hai thông tin RoleID và SecretID có thể được cung cấp cho điểm cuối đăng nhập để tìm nạp token Vault mới.
