HashiCorp Vault là một công cụ quản lý bí mật giúp cung cấp quyền truy cập an toàn, tự động vào dữ liệu nhạy cảm. Vault đáp ứng các trường hợp sử dụng này bằng cách ghép các phương pháp xác thực (như mã thông báo ứng dụng) với các công cụ bí mật (như cặp khóa/giá trị đơn giản) bằng cách sử dụng các chính sách để kiểm soát cách cấp quyền truy cập. Trong hướng dẫn này, bạn sẽ cài đặt, cấu hình và truy cập Vault trong một ví dụ triển khai để minh họa các tính năng và API của Vault.

Hướng dẫn này sẽ sử dụng phiên bản mới nhất của Vault, là 1.1.0 tại thời điểm viết bài này.

Tại sao nên sử dụng Vault?

Một dịch vụ như Vault đòi hỏi nỗ lực vận hành để chạy an toàn và hiệu quả. Với sự phức tạp gia tăng khi sử dụng Vault như một phần của ứng dụng, theo cách nào nó tạo thêm giá trị?

Hãy xem xét một ứng dụng đơn giản phải sử dụng mã thông báo API hoặc giá trị bí mật khác. Làm thế nào để cung cấp thông tin xác thực nhạy cảm này cho ứng dụng khi chạy?

  • Việc cam kết bí mật cùng với phần còn lại của mã ứng dụng trong hệ thống kiểm soát phiên bản như vậy gitlà một biện pháp bảo mật kém vì nhiều lý do, bao gồm cả việc giá trị nhạy cảm được ghi lại dưới dạng văn bản thuần túy và không được bảo vệ theo bất kỳ cách nào.
  • Việc ghi lại bí mật trong một tệp được chuyển đến một ứng dụng đòi hỏi tệp đó phải được lưu trữ an toàn ngay từ đầu và được kiểm soát quyền truy cập chặt chẽ.
  • Rất khó để xoay vòng hoặc hạn chế quyền truy cập vào thông tin xác thực tĩnh nếu ứng dụng bị xâm phạm.

Vault giải quyết những vấn đề này và nhiều vấn đề khác theo nhiều cách, bao gồm:

  • Các dịch vụ và ứng dụng chạy mà không cần sự tương tác của người vận hành có thể xác thực với Vault bằng các giá trị có thể xoay vòng, thu hồi và kiểm soát quyền.
  • Một số công cụ bảo mật có thể tạo ra các bí mật tạm thời, được tạo động để đảm bảo thông tin xác thực sẽ hết hạn sau một khoảng thời gian.
  • Chính sách dành cho người dùng và tài khoản máy có thể được kiểm soát chặt chẽ đối với các loại quyền truy cập cụ thể vào các đường dẫn cụ thể.

Các khái niệm

Trước khi tiếp tục, bạn nên làm quen với các thuật ngữ và khái niệm quan trọng của Vault sẽ được sử dụng sau trong hướng dẫn này.

  • Mã thông báo là cơ chế cơ bản hỗ trợ quyền truy cập vào tài nguyên Vault. Cho dù người dùng xác thực với Vault bằng mã thông báo GitHub hay dịch vụ do ứng dụng điều khiển xác thực bằng AppRole RoleID và SecretID, thì tất cả các hình thức xác thực cuối cùng đều được chuẩn hóa thành mã thông báo . Mã thông báo thường có thời gian tồn tại ngắn (tức là hết hạn sau một khoảng thời gian hoặc thời gian tồn tại, hoặc ttl) và có một hoặc nhiều chính sách được đính kèm vào chúng.
  • Chính sách Vault chỉ định một số hành động nhất định có thể được thực hiện trên đường dẫn Vault . Các khả năng như khả năng đọc bí mật, ghi bí mật và xóa chúng đều là ví dụ về các hành động được xác định trong chính sách cho một đường dẫn cụ thể .
  • Đường dẫn trong Vault có dạng tương tự như đường dẫn hệ thống tệp Unix (như /etc) hoặc URL (như /blog/title). Người dùng và tài khoản máy tương tác với Vault qua các đường dẫn cụ thể để truy xuất bí mật, thay đổi cài đặt hoặc tương tác theo cách khác với dịch vụ Vault đang chạy. Tất cả quyền truy cập Vault đều được thực hiện qua giao diện REST, vì vậy các đường dẫn này cuối cùng sẽ có dạng URL HTTP. Trong khi một số đường dẫn tương tác với chính dịch vụ Vault để quản lý các tài nguyên như chính sách hoặc cài đặt, nhiều đường dẫn đóng vai trò là điểm cuối để xác thực với Vault hoặc tương tác với công cụ bí mật .
  • Công cụ bí mật là một backend được sử dụng trong Vault để cung cấp bí mật cho người dùng Vault. Ví dụ đơn giản nhất về công cụ bí mật là backend khóa/giá trị , chỉ trả về các giá trị văn bản thuần túy có thể được lưu trữ tại các đường dẫn cụ thể (các bí mật này vẫn được mã hóa trên backend). Các ví dụ khác về backend bí mật bao gồm backend PKI , có thể tạo và quản lý chứng chỉ TLS, và backend TOTP , có thể tạo mật khẩu một lần tạm thời cho các trang web yêu cầu xác thực đa yếu tố (bao gồm cả Linode Manager).

Cài đặt

Hướng dẫn này sẽ thiết lập Vault trong cấu hình hệ thống tập tin cục bộ đơn giản. Các bước được liệt kê ở đây áp dụng như nhau cho bất kỳ bản phân phối nào.

Các bước cài đặt này sẽ:

  • Mua chứng chỉ TLS để đảm bảo mọi giao tiếp giữa Vault và máy khách đều được mã hóa.
  • Cấu hình Vault để lưu trữ hệ thống tập tin cục bộ.
  • Cài đặt vaulttệp nhị phân và thiết lập hệ điều hành để vận hành Vault như một dịch vụ.

Ghi chú: Cấu hình được nêu trong hướng dẫn này phù hợp với các triển khai nhỏ. Trong các tình huống yêu cầu các dịch vụ có khả năng sẵn sàng cao hoặc chịu lỗi, hãy cân nhắc chạy nhiều hơn một phiên bản Vault với một backend lưu trữ có khả năng sẵn sàng cao như Consul .

Trước khi bạn bắt đầu

  1. Nếu bạn chưa thực hiện, hãy tạo một tài khoản Linode và Compute Instance. Xem hướng dẫn Bắt đầu với Linode và Tạo Compute Instance của chúng tôi .
  2. Làm theo hướng dẫn Thiết lập và Bảo mật Phiên bản Compute của chúng tôi để cập nhật hệ thống của bạn. Bạn cũng có thể muốn đặt múi giờ, cấu hình tên máy chủ, tạo tài khoản người dùng giới hạn và tăng cường quyền truy cập SSH.Ghi chúViệc thiết lập tên máy chủ đầy đủ chính xác /etc/hostslà rất quan trọng trong hướng dẫn này để chấm dứt TLS trên Vault đúng cách. Tên miền đủ điều kiện và tên máy chủ ngắn của Linode của bạn phải có trong /etc/hoststệp trước khi tiếp tục.
  3. Thực hiện theo Hướng dẫn UFW của chúng tôi để cài đặt và cấu hình tường lửa trên hệ thống chạy Ubuntu hoặc Debian của bạn hoặc Hướng dẫn FirewallD của chúng tôi cho hệ thống chạy rpm hoặc CentOS. Hãy cân nhắc xem lại các khuyến nghị về Production Hardening của Vault nếu điều này sẽ được sử dụng trong môi trường sản xuất.

Ghi chú: Khi cấu hình tường lửa, hãy nhớ rằng Vault lắng nghe trên cổng 8200 theo mặc định và Let’s Encrypt sử dụng cổng 80 (HTTP) và 443 (HTTPS).

Nhận chứng chỉ TLS

1.Thực hiện theo các bước trong hướng dẫn Bảo mật lưu lượng HTTP với Certbot của chúng tôi để có được chứng chỉ TLS.

2.Thêm nhóm hệ thống để cấp quyền truy cập đọc hạn chế vào các tệp TLS do Certbot tạo ra.

sudo groupadd tls

3.Thay đổi quyền sở hữu nhóm của các tệp chứng chỉ trong thư mục Let’s Encrypt thành tls.

sudo chgrp -R tls /etc/letsencrypt/{archive,live}

4.Cấp cho các thành viên trong tlsnhóm quyền đọc các thư mục và tệp cần thiết.

sudo chmod g+rx /etc/letsencrypt/{archive,live}
sudo find /etc/letsencrypt/archive -name 'privkey*' -exec chmod g+r {} ';'

Tải xuống các tập tin Vault

1.Tải xuống phiên bản nhị phân phát hành cho Vault.

wget https://releases.hashicorp.com/vault/1.1.0/vault_1.1.0_linux_amd64.zip

2.Tải xuống tệp kiểm tra để xác minh rằng tệp zip không bị hỏng.

wget https://releases.hashicorp.com/vault/1.1.0/vault_1.1.0_SHA256SUMS

3.Tải xuống tệp chữ ký tổng kiểm tra để xác minh rằng tệp tổng kiểm tra không bị giả mạo.

wget https://releases.hashicorp.com/vault/1.1.0/vault_1.1.0_SHA256SUMS.sig

Xác minh Tải xuống

1.Nhập khóa GPG của HashiCorp Security (được liệt kê trên trang HashiCorp Security trong mục Truyền thông an toàn ):

gpg --recv-keys 51852D87348FFC4C

Đầu ra sẽ hiển thị khóa đã được nhập:

gpg: /home/user/.gnupg/trustdb.gpg: trustdb created
gpg: key 51852D87348FFC4C: public key "HashiCorp Security <security@hashicorp.com>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

Ghi chú: Nếu xảy ra lỗi với thông báo lỗi keyserver receive failed: Syntax error in URI, chỉ cần thử chạy lại gpglệnh.

Ghi chú: Nếu bạn nhận được lỗi cho biết dirmngrphần mềm bị thiếu hoặc không thể truy cập, hãy cài đặt dirmngrbằng trình quản lý gói và chạy lại lệnh GPG.

2.Xác minh chữ ký GPG của tệp tổng kiểm tra:

gpg --verify vault*.sig vault*SHA256SUMS

Đầu ra sẽ chứa Good signature from "HashiCorp Security <security@hashicorp.com>"thông báo xác nhận:

gpg: Signature made Mon 18 Mar 2019 01:44:51 PM MDT
gpg:                using RSA key 91A6E7F85D05C65630BEF18951852D87348FFC4C
gpg: Good signature from "HashiCorp Security &lt;security@hashicorp.com&gt;" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 91A6 E7F8 5D05 C656 30BE  F189 5185 2D87 348F FC4C

3.Xác minh rằng dấu vân tay đầu ra trùng khớp với dấu vân tay được liệt kê trong phần Truyền thông bảo mật của trang Bảo mật HashiCorp .

4.Xác minh .ziptổng kiểm tra của kho lưu trữ:

sha256sum -c vault*SHA256SUMS 2>&1 | grep OK

Đầu ra sẽ hiển thị tên tệp như được chỉ định trong vault*SHA256SUMStệp:

vault_1.1.0_linux_amd64.zip: OK

Cài đặt Vault Executable

1.Giải nén tệp thực thi Vault vào thư mục cục bộ.

unzip vault_*_linux_amd64.zip

Ghi chú: Nếu bạn nhận được lỗi cho biết gói unzipnày bị thiếu trong hệ thống, hãy cài đặt unzipgói và thử lại.

2.Di chuyển vaulttệp thực thi vào một vị trí trên toàn hệ thống.

sudo mv vault /usr/local/bin

3.Đặt lại quyền sở hữu và quyền trên tệp thực thi.

sudo chown root:root /usr/local/bin/vault
sudo chmod 755 /usr/local/bin/vault

4.Thiết lập khả năng thực thi trên vaulttệp nhị phân. Điều này sẽ cấp cho Vault quyền khóa bộ nhớ, đây là cách thực hành tốt nhất để chạy Vault một cách an toàn (xem tài liệu Vault để biết thêm thông tin).

sudo setcap cap_ipc_lock=+ep /usr/local/bin/vault

5.Xác minh rằng vaulthiện tại nó đã có sẵn trong shell cục bộ.

vault --version

Đầu ra của lệnh này sẽ trả về kết quả như sau.

Vault v1.1.0 ('36aa8c8dd1936e10ebd7a4c1d412ae0e6f7900bd')

Cấu hình System Vault

1.Tạo người dùng hệ thống vaultsẽ chạy khi dịch vụ được khởi động.

sudo useradd --system -d /etc/vault.d -s /bin/nologin vault

2.Thêm vaultngười dùng vào tlsnhóm đã tạo trước đó, điều này sẽ cấp cho người dùng khả năng đọc chứng chỉ Let’s Encrypt.

sudo gpasswd -a vault tls

3.Tạo thư mục dữ liệu và thư mục cấu hình vaultvới quyền hạn hạn chế.

sudo install -o vault -g vault -m 750 -d /var/lib/vault
sudo install -o vault -g vault -m 750 -d /etc/vault.d

4.Tạo một servicetệp systemd để kiểm soát cách chạy vaultliên tục như một daemon hệ thống.

[Unit]
Description="a tool for managing secrets"
Documentation=https://www.vaultproject.io/docs/
Requires=network-online.target
After=network-online.target
ConditionFileNotEmpty=/etc/vault.d/vault.hcl

[Service]
User=vault
Group=vault
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
SecureBits=keep-caps
AmbientCapabilities=CAP_IPC_LOCK
Capabilities=CAP_IPC_LOCK+ep
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
NoNewPrivileges=yes
ExecStart=/usr/local/bin/vault server -config=/etc/vault.d/vault.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
StartLimitIntervalSec=60
StartLimitBurst=3
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
  1. Các tùy chọn dịch vụ systemd này xác định một số thiết lập quan trọng để đảm bảo Vault chạy an toàn và đáng tin cậy. Xem lại tài liệu Vault để biết giải thích đầy đủ về những gì các tùy chọn này đạt được.

Cấu hình

Cấu hình Vault

1.Tạo tệp cấu hình cho Vault với nội dung sau, thay thế example.combằng tên miền được sử dụng trong chứng chỉ Let’s Encrypt của bạn.

listener "tcp" {
  address = "0.0.0.0:8200"
  tls_cert_file = "/etc/letsencrypt/live/example.com/fullchain.pem"
  tls_key_file = "/etc/letsencrypt/live/example.com/privkey.pem"
}

storage "file" {
  path = "/var/lib/vault"
}
  1. Cấu hình này sẽ sử dụng chứng chỉ Let’s Encrypt được tạo trong các bước trước để chấm dứt TLS cho dịch vụ Vault. Điều này đảm bảo rằng các bí mật sẽ không bao giờ được truyền dưới dạng văn bản thuần túy. Lưu trữ thực tế cho Vault sẽ nằm trên hệ thống tệp cục bộ tại /var/lib/vault.

Chạy dịch vụ Vault

1.Vault hiện đã sẵn sàng để chạy. Bắt đầu dịch vụ bằng cách sử dụng systemctl.

sudo systemctl start vault

2.Nếu muốn, hãy bật dịch vụ này để Vault khởi động cùng lúc với thời điểm khởi động hệ thống.

sudo systemctl enable vault

3.Xác nhận Vault đang hoạt động bằng cách sử dụng tệp vaultthực thi để kiểm tra trạng thái của dịch vụ. Đặt VAULT_ADDRbiến môi trường thành https://example.com:8200, thay thế example.combằng tên miền của riêng bạn:

export VAULT_ADDR=https://example.com:8200

4.vaultlệnh bây giờ sẽ được gửi đến phiên bản Vault cục bộ của bạn. Để xác nhận điều này, hãy chạy vault statuslệnh:

vault status

Lệnh này sẽ trả về kết quả tương tự như sau:

Key                Value
---                -----
Seal Type          shamir
Initialized        false
Sealed             true
Total Shares       0
Threshold          0
Unseal Progress    0/0
Unseal Nonce       n/a
Version            n/a
HA Enabled         false

Phần còn lại của hướng dẫn này giả định rằng biến môi trường VAULT_ADDRđược đặt thành giá trị này để đảm bảo các yêu cầu được gửi đến đúng máy chủ Vault.

Khởi tạo Vault

Ở giai đoạn này, Vault đã được cài đặt và chạy, nhưng chưa được khởi tạo . Các bước sau sẽ khởi tạo backend Vault, thiết lập khóa mở khóa và trả về mã thông báo gốc ban đầu. Khởi tạo chỉ diễn ra một lần cho một lần triển khai Vault.

Có hai tùy chọn có thể cấu hình để lựa chọn khi thực hiện bước khởi tạo. Giá trị đầu tiên là số lượng chia sẻ khóa, điều khiển tổng số khóa mở niêm phong mà Vault sẽ tạo ra. Giá trị thứ hai là ngưỡng khóa, điều khiển số lượng chia sẻ khóa mở niêm phong này được yêu cầu trước khi Vault tự mở niêm phong thành công. Việc mở niêm phong được yêu cầu bất cứ khi nào Vault được khởi động lại hoặc đưa trực tuyến theo cách khác sau khi ở trạng thái ngoại tuyến trước đó.

Để minh họa cho khái niệm này, hãy xem xét một máy chủ an toàn trong một trung tâm dữ liệu. Vì cơ sở dữ liệu Vault chỉ được giải mã trong bộ nhớ, việc đánh cắp hoặc đưa máy chủ ngoại tuyến vì bất kỳ lý do nào sẽ để lại bản sao duy nhất của cơ sở dữ liệu Vault trên hệ thống tệp ở dạng được mã hóa hoặc “được niêm phong”.

Khi khởi động lại máy chủ, chia sẻ khóa là 3 và ngưỡng khóa là 2 nghĩa là có 3 khóa tồn tại, nhưng ít nhất phải cung cấp 2 khóa khi khởi động để Vault có thể lấy được khóa giải mã và tải cơ sở dữ liệu vào bộ nhớ để truy cập một lần nữa.

Số lượng chia sẻ khóa đảm bảo rằng nhiều khóa có thể tồn tại ở các vị trí khác nhau cho một mức độ chịu lỗi và mục đích sao lưu. Số lượng ngưỡng khóa đảm bảo rằng việc xâm phạm một khóa mở niêm phong riêng lẻ là không đủ để giải mã dữ liệu Vault.

1.Chọn một giá trị cho số lượng chia sẻ khóa và ngưỡng khóa. Tình huống của bạn có thể khác nhau, nhưng ví dụ, hãy xem xét một nhóm gồm ba người phụ trách vận hành Vault. Chia sẻ khóa là 3 đảm bảo rằng mỗi thành viên nắm giữ một khóa mở khóa. Ngưỡng khóa là 2 có nghĩa là không một người vận hành nào có thể làm mất khóa của họ và xâm phạm hệ thống hoặc đánh cắp cơ sở dữ liệu Vault mà không phối hợp với người vận hành khác.

2.Sử dụng các giá trị đã chọn này, thực hiện lệnh khởi tạo. Hãy chuẩn bị lưu đầu ra được trả về từ lệnh sau, vì nó chỉ có thể xem được một lần .

vault operator init -key-shares=3 -key-threshold=2

Lệnh này sẽ trả về kết quả tương tự như sau:

Unseal Key 1: BaR6GUWRY8hIeNyuzAn7FTa82DiIldgvEZhOKhVsl0X5
Unseal Key 2: jzh7lji1NX9TsNVGycUudSIy/X4lczJgsCpRfm3m8Q03
Unseal Key 3: JfdH8LqEyc4B+xLMBX6/LT9o8G/6isC2ZFfz+iNMIW/0

Initial Root Token: s.YijNa8lqSDeho1tJBtY02983

Vault initialized with 3 key shares and a key threshold of 2. Please securely
distribute the key shares printed above. When the Vault is re-sealed,
restarted, or stopped, you must supply at least 2 of these keys to unseal it
before it can start servicing requests.

Vault does not store the generated master key. Without at least 2 key to
reconstruct the master key, Vault will remain permanently sealed!

It is possible to generate new unseal keys, provided you have a quorum of
existing unseal keys shares. See "vault operator rekey" for more information.

3.Trong kịch bản sản xuất, các khóa mở niêm phong này phải được lưu trữ ở các vị trí riêng biệt. Ví dụ, lưu trữ một khóa trong trình quản lý mật khẩu như LastPass, mã hóa khóa bằng gpg và lưu trữ khóa khác ngoại tuyến trên khóa USB. Làm như vậy đảm bảo rằng việc xâm phạm một vị trí lưu trữ là không đủ để khôi phục số lượng khóa mở niêm phong cần thiết để giải mã cơ sở dữ liệu Vault.

4.Tương Initial Root Tokenđương với tài khoản “root” hoặc siêu người dùng cho Vault API. Ghi lại và bảo vệ mã thông báo này theo cách tương tự. Giống như tài rootkhoản trên hệ thống Unix, mã thông báo này nên được sử dụng để tạo các tài khoản ít đặc quyền hơn để sử dụng cho các tương tác hàng ngày với Vault và mã thông báo gốc nên được sử dụng không thường xuyên do các đặc quyền rộng rãi của nó.

Mở khóa két sắt

Sau khi khởi tạo, Vault sẽ được niêm

mở niêm phong sau đây phải được thực hiện bất kỳ lúc nào vaultdịch vụ được đưa xuống và sau đó được đưa lên lại, chẳng hạn như khi thực hiện systemctl restart vaulthoặc khởi động lại máy chủ.

1.Sau khi VAULT_ADDRthiết lập đúng, hãy thực hiện lệnh mở khóa.

vault operator unseal

Một lời nhắc sẽ xuất hiện:

Unseal Key (will be hidden):

2.Dán hoặc nhập một khóa mở khóa và nhấn Enter . Lệnh sẽ kết thúc với đầu ra tương tự như sau:

Unseal Key (will be hidden):
Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       3
Threshold          2
Unseal Progress    1/2
Unseal Nonce       0124ce2a-6229-fac1-0e3f-da3e97e00583
Version            1.1.0
HA Enabled         false

Lưu ý rằng đầu ra cho biết một trong hai khóa mở khóa bắt buộc đã được cung cấp.

3.Thực hiện unseallại lệnh.

vault operator unseal

4.Nhập khóa mở khóa khác khi lời nhắc xuất hiện.

Unseal Key (will be hidden):

5.Kết quả đầu ra sẽ chỉ ra rằng Vault hiện đã được mở niêm phong (chú ý Sealed falsedòng này).

Unseal Key (will be hidden):
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    3
Threshold       2
Version         1.1.0
Cluster Name    vault-cluster-a397153e
Cluster ID      a065557e-3ee8-9d26-4d90-b90c8d69fa5d
HA Enabled      false

Vault hiện đã hoạt động.

Sử dụng Vault

Xác thực mã thông báo

Khi tương tác với Vault qua REST API, Vault xác định và xác thực hầu hết các yêu cầu bằng sự hiện diện của mã thông báo. Mặc dù mã thông báo gốc ban đầu có thể được sử dụng ngay bây giờ, phần Chính sách của hướng dẫn này sẽ giải thích cách cung cấp các mã thông báo bổ sung.

1.Đặt biến VAULT_TOKENmôi trường thành giá trị của mã thông báo gốc đã lấy trước đó. Mã thông báo này là cơ chế xác thực mà lệnh vaultsẽ dựa vào để tương tác trong tương lai với Vault. Mã thông báo gốc thực tế sẽ khác trong môi trường của bạn.

export VAULT_TOKEN=s.YijNa8lqSDeho1tJBtY02983

2.Sử dụng lệnh token lookupphụ để xác nhận rằng mã thông báo hợp lệ và có các quyền mong đợi.

vault token lookup

3.Đầu ra của lệnh này sẽ bao gồm những thông tin sau:

policies            [root]

Phần cuối bí mật của KV

Backend Vault là cơ chế cốt lõi mà Vault sử dụng để cho phép người dùng đọc và ghi các giá trị bí mật. Backend đơn giản nhất để minh họa chức năng này là backend KV . Backend này cho phép khách hàng ghi các cặp khóa/giá trị (chẳng hạn như mysecret=apikey) có thể đọc sau.

1.Kích hoạt chức năng bí mật bằng cách sử dụng enablelệnh phụ Vault.

vault secrets enable -version=2 kv

2.Viết giá trị ví dụ vào chương trình phụ trợ KV bằng kv putlệnh phụ Vault.

vault kv put kv/myservice api_token=secretvalue

Lệnh này sẽ trả về kết quả tương tự như sau:

Key              Value
---              -----
created_time     2019-03-31T04:35:38.631167678Z
deletion_time    n/a
destroyed        false
version          1

3.Đọc giá trị này từ kv/myserviceđường dẫn.

vault kv get kv/myservice

Lệnh này sẽ trả về kết quả tương tự như sau:

====== Metadata ======
Key              Value
---              -----
created_time     2019-03-31T04:35:38.631167678Z
deletion_time    n/a
destroyed        false
version          1

====== Data ======
Key          Value
---          -----
api_token    secretvalue

4.Nhiều tiện ích và tập lệnh phù hợp hơn để xử lý đầu ra json. Sử dụng -format=jsoncờ để đọc thêm một lần nữa, với kết quả trả về dưới dạng JSON.

vault kv get -format=json kv/myservice
{
  "request_id": "2734ea81-6f39-c017-4c73-2719b2018b65",
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
"data": {
  "api_token": "secretvalue"
},
"metadata": {
  "created_time": "2019-03-31T04:35:38.631167678Z",
  "deletion_time": "",
  "destroyed": false,
  "version": 1
}
  },
  "warnings": null
}

Chính sách

Cho đến thời điểm này, chúng tôi đã thực hiện các lệnh gọi API đến Vault bằng mã thông báo gốc. Các thông lệ sản xuất tốt nhất chỉ ra rằng mã thông báo này hiếm khi được sử dụng và hầu hết các hoạt động nên được thực hiện bằng các mã thông báo ít đặc quyền hơn được liên kết với các chính sách được kiểm soát.

Chính sách được xác định bằng cách chỉ định một đường dẫn cụ thể và tập hợp các khả năng mà người dùng được phép trên đường dẫn đó. Trong các lệnh trước đây của chúng tôi, đường dẫn là kv/myservice, vì vậy chúng tôi có thể tạo chính sách để chỉ đọc bí mật này và không thực hiện bất kỳ thao tác nào khác, bao gồm đọc hoặc liệt kê bí mật. Khi không có chính sách nào tồn tại cho một đường dẫn cụ thể, Vault sẽ từ chối các thao tác theo mặc định.

Trong trường hợp của KV backend, Vault phân biệt các hoạt động trên dữ liệu được lưu trữ, là các giá trị được lưu trữ thực tế, và siêu dữ liệu, bao gồm thông tin như lịch sử phiên bản. Trong ví dụ này, chúng tôi sẽ tạo chính sách để kiểm soát quyền truy cập vào dữ liệu khóa/giá trị.

1.Tạo tệp chính sách Vault sau.

path "kv/data/myservice" {
  capabilities = ["read"]
}

Chính sách đơn giản này sẽ cho phép bất kỳ mã thông báo nào được liên kết với nó đọc được bí mật được lưu trữ tại đường dẫn bí mật KV kv/myservice.

2.Tải chính sách này vào Vault bằng lệnh policy writephụ. Lệnh sau đây đặt tên cho chính sách đã đề cập ở trên read-myservice.

vault policy write read-myservice policy.hcl

3.Để minh họa việc sử dụng chính sách này, hãy tạo một mã thông báo mới có liên quan đến chính sách mới này.

vault token create -policy=read-myservice

Lệnh này sẽ trả về kết quả tương tự như sau.

Key                  Value
---                  -----
token                s.YdpJWRRaEIgdOW4y72sSVygy
token_accessor       07akQfzg0TDjj3YoZSGMPkHA
token_duration       768h
token_renewable      true
token_policies       ["default" "read-myservice"]
identity_policies    []
policies             ["default" "read-myservice"]

4.Mở một cửa sổ hoặc tab terminal khác và đăng nhập vào cùng máy chủ mà Vault đang chạy. Đặt VAULT_ADDRđể đảm bảo rằng vaultcác lệnh mới trỏ đến phiên bản cục bộ của Vault, thay thế example.combằng tên miền của bạn.

export VAULT_ADDR=https://example.com:8200

5.Đặt VAULT_TOKENbiến môi trường thành mã thông báo mới vừa được tạo bởi token createlệnh. Hãy nhớ rằng mã thông báo thực tế của bạn sẽ khác với mã thông báo trong ví dụ này.

export VAULT_TOKEN=s.YdpJWRRaEIgdOW4y72sSVygy

6.Bây giờ hãy thử đọc bí mật của chúng ta trong Vault tại kv/myservicecon đường này.

vault kv get kv/myservice

Vault sẽ trả về dữ liệu khóa/giá trị.

====== Metadata ======
Key              Value
---              -----
created_time     2019-03-31T04:35:38.631167678Z
deletion_time    n/a
destroyed        false
version          1

====== Data ======
Key          Value
---          -----
api_token    secretvalue

7.Để minh họa các hoạt động bị cấm, hãy thử listtất cả các bí mật trong phần phụ trợ KV.

vault kv list kv/

Vault nên từ chối yêu cầu này.

Error listing kv/metadata: Error making API request.

URL: GET https://example.com:8200/v1/kv/metadata?list=true
Code: 403. Errors:

* 1 error occurred:
        * permission denied

8.Ngược lại, hãy thử thực hiện thao tác tương tự trong cửa sổ thiết bị đầu cuối trước đó đã được cấu hình bằng mã thông báo gốc.

vault kv list kv/
Keys
----
myservice

Mã thông báo gốc phải có đủ quyền để trả về danh sách tất cả các khóa bí mật theo kv/đường dẫn.

Phương pháp xác thực

Trên thực tế, khi các dịch vụ yêu cầu giá trị bí mật được triển khai, không nên phân phối mã thông báo như một phần của quá trình triển khai hoặc quản lý cấu hình. Thay vào đó, các dịch vụ nên tự xác thực với Vault để có được mã thông báo có thời hạn sử dụng hạn chế. Điều này đảm bảo rằng thông tin xác thực cuối cùng sẽ hết hạn và không thể sử dụng lại nếu chúng bị rò rỉ hoặc tiết lộ.

Vault hỗ trợ nhiều loại phương pháp xác thực. Ví dụ, phương pháp xác thực Kubernetes có thể truy xuất mã thông báo cho từng pod. Là một ví dụ minh họa đơn giản, các bước sau đây sẽ trình bày cách sử dụng phương pháp AppRole .

Phương pháp xác thực AppRole hoạt động bằng cách yêu cầu khách hàng cung cấp hai thông tin: AppRole RoleID và SecretID. Phương pháp tiếp cận khuyến nghị để sử dụng phương pháp này là lưu trữ hai thông tin này ở các vị trí riêng biệt, vì chỉ một thông tin là không đủ để xác thực với Vault, nhưng khi kết hợp lại, chúng cho phép khách hàng truy xuất mã thông báo Vault hợp lệ. Ví dụ, trong dịch vụ sản xuất, RoleID có thể có trong tệp cấu hình của dịch vụ, trong khi SecretID có thể được cung cấp dưới dạng biến môi trường.

1.Bật phương thức xác thực AppRole bằng lệnh authphụ. Nhớ thực hiện các bước này trong cửa sổ terminal với mã thông báo gốc được lưu trữ trong VAULT_TOKENbiến môi trường, nếu không lệnh Vault sẽ không thành công.

vault auth enable approle

2.Tạo một vai trò được đặt tên. Điều này sẽ định nghĩa một vai trò có thể được sử dụng để “đăng nhập” vào Vault và lấy mã thông báo có chính sách liên kết với nó. Lệnh sau đây tạo một vai trò được đặt tên named my-applicationtạo ra các mã thông báo có hiệu lực trong 10 phút sẽ có read-myservicechính sách liên kết với chúng.

vault write auth/approle/role/my-application \
    token_ttl=10m \
    policies=read-myservice

3.Truy xuất RoleID của vai trò được đặt tên, xác định duy nhất AppRole. Lưu ý giá trị này để sử dụng sau.

vault read auth/approle/role/my-application/role-id
Key        Value
---        -----
role_id    147cd412-d1c2-4d2c-c57e-d660da0b1fa8

Trong trường hợp ví dụ này, RoleID là 147cd412-d1c2-4d2c-c57e-d660da0b1fa8. Lưu ý rằng giá trị của bạn sẽ khác.

4.Cuối cùng, hãy đọc secret-id của vai trò được đặt tên và lưu giá trị này để sử dụng sau.

vault write -f auth/approle/role/my-application/secret-id
Key                   Value
---                   -----
secret_id             2225c0c3-9b9f-9a9c-a0a5-10bf06df7b25
secret_id_accessor    30cbef6a-8834-94fe-6cf3-cf2e4598dd6a

Trong ví dụ đầu ra này, SecretID là 2225c0c3-9b9f-9a9c-a0a5-10bf06df7b25.

5.Sử dụng các giá trị này để tạo mã thông báo sử dụng hạn chế bằng cách thực hiện writethao tác với API AppRole. Thay thế các giá trị RoleID và SecretID tại đây bằng giá trị của riêng bạn.

vault write auth/approle/login \
    role_id=147cd412-d1c2-4d2c-c57e-d660da0b1fa8 \
    secret_id=2225c0c3-9b9f-9a9c-a0a5-10bf06df7b25

Đầu ra kết quả sẽ bao gồm một mã thông báo mới, trong trường hợp ví dụ này làs.coRl4UR6YL1sqw1jXhJbuZfq

Key                     Value
---                     -----
token                   s.3uu4vwFO8D1mG5S76IG04mck
token_accessor          fi3aW4W9kZNB3FAC20HRXeoT
token_duration          10m
token_renewable         true
token_policies          ["default" "read-myservice"]
identity_policies       []
policies                ["default" "read-myservice"]
token_meta_role_name    my-application

6.Mở thêm một tab hoặc cửa sổ thiết bị đầu cuối và đăng nhập vào máy chủ từ xa đang chạy Vault.

7.Một lần nữa, hãy đặt VAULT_ADDRbiến môi trường thành giá trị chính xác để giao tiếp với phiên bản Vault cục bộ của bạn.

export VAULT_ADDR=https://example.com:8200

8.Đặt VAULT_TOKENbiến môi trường thành mã thông báo mới được tạo này. Từ đầu ra ví dụ trước, đây sẽ là kết quả sau (lưu ý rằng mã thông báo của bạn sẽ khác).

export VAULT_TOKEN=s.3uu4vwFO8D1mG5S76IG04mck9.

9.Đọc đường dẫn KV mà mã thông báo này có thể truy cập.

vault kv get kv/myservice

Ví dụ này phải dễ đọc và dễ hiểu.

10.Nếu bạn đọc giá trị này bằng mã thông báo Vault này sau hơn 10 phút, mã thông báo sẽ hết hạn và mọi hoạt động đọc bằng mã thông báo sẽ bị từ chối. Thực hiện một vault write auth/approle/loginhoạt động khác (chi tiết trong bước 5) có thể tạo mã thông báo mới để sử dụng.

Thông tin thêm

Bạn có thể muốn tham khảo các nguồn sau để biết thêm thông tin về chủ đề này. Mặc dù chúng tôi cung cấp với hy vọng rằng chúng sẽ hữu ích, nhưng xin lưu ý rằng chúng tôi không thể đảm bảo tính chính xác hoặc tính kịp thời của các tài liệu được lưu trữ bên ngoài.

Nguồn: https://www.linode.com/docs/guides/use-hashicorp-vault-for-secret-management/