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
git
là 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
vault
tệ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
- 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 .
- 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/hosts
là 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/hosts
tệp trước khi tiếp tục. - 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 tls
nhó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 gpg
lệnh.
Ghi chú: Nếu bạn nhận được lỗi cho biết dirmngr
phần mềm bị thiếu hoặc không thể truy cập, hãy cài đặt dirmngr
bằ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 <security@hashicorp.com>" [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 .zip
tổ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*SHA256SUMS
tệ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 unzip
này bị thiếu trong hệ thống, hãy cài đặt unzip
gói và thử lại.
2.Di chuyển vault
tệ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 vault
tệ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 vault
hiệ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 vault
sẽ chạy khi dịch vụ được khởi động.
sudo useradd --system -d /etc/vault.d -s /bin/nologin vault
2.Thêm vault
người dùng vào tls
nhó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 vault
vớ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 service
tệp systemd để kiểm soát cách chạy vault
liê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
- 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.com
bằ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"
}
- 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 vault
thực thi để kiểm tra trạng thái của dịch vụ. Đặt VAULT_ADDR
biến môi trường thành https://example.com:8200
, thay thế example.com
bằng tên miền của riêng bạn:
export VAULT_ADDR=https://example.com:8200
4.vault
lệ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 status
lệ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 root
khoả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 vault
dị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 vault
hoặc khởi động lại máy chủ.
1.Sau khi VAULT_ADDR
thiế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 unseal
lạ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 false
dò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_TOKEN
mô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 vault
sẽ 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 lookup
phụ để 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 enable
lệ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 put
lệ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=json
cờ để đọ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 write
phụ. 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 vault
các lệnh mới trỏ đến phiên bản cục bộ của Vault, thay thế example.com
bằng tên miền của bạn.
export VAULT_ADDR=https://example.com:8200
5.Đặt VAULT_TOKEN
biến môi trường thành mã thông báo mới vừa được tạo bởi token create
lệ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/myservice
con đườ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ử list
tấ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 auth
phụ. 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_TOKEN
biế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-application
tạo ra các mã thông báo có hiệu lực trong 10 phút sẽ có read-myservice
chí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 write
thao 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_ADDR
biế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_TOKEN
biế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/login
hoạ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.
- Tổng quan về tài liệu Vault
- Kiến trúc tham chiếu Vault và các phương pháp hay nhất
- Động cơ bí mật của Vault
- Phương pháp xác thực Vault
Nguồn: https://www.linode.com/docs/guides/use-hashicorp-vault-for-secret-management/