So sánh secrets manager self-hosted trên một VPS

Secrets manager tự host làm được gì mà password manager không làm được

Self-hosted secrets manager cung cấp credential cho các process. Password manager cung cấp credential cho con người. Mọi khác biệt khác đều bắt nguồn từ điểm này. Password manager được mở khóa bởi một người đang có mặt và chú ý. Secrets manager phải cung cấp mật khẩu database cho application vào lúc 03:00, khi không có ai thức.

Các kiểu lỗi khác nhau theo cách rất quan trọng. Password manager bị khóa chỉ gây bất tiện: bạn nhập lại master password. Secrets manager bị seal gây outage: mọi service restart trong lúc nó bị seal sẽ khởi động mà không có credential và tiếp tục down. Chạy Vaultwarden làm password manager riêng giải quyết tốt vấn đề của con người. Nó không giải quyết vấn đề của máy và vốn không được thiết kế cho việc đó. Nếu bạn chạy Vaultwarden cùng với hệ thống này, phần đáng hardening là admin token và file backup của nó, không phải nội dung vault mà client đã mã hóa; hardening Vaultwarden bao quát cả hai phần này.

Các lựa chọn thực tế cho một server được chia thành 2 nhóm. OpenBao và Infisical là các service: một API, một database, TLS (transport layer security), bước đăng nhập và một process mà bạn phải duy trì hoạt động. SOPS với age, systemd credentials và Docker secrets là các file: được mã hóa khi lưu trữ, được giải mã bởi một thành phần đã chạy sẵn và không có thành phần bổ sung nào cần monitor.

Đây là câu trả lời thẳng ngay từ đầu. Với một máy duy nhất có 1 hoặc 2 người dùng, các lựa chọn dựa trên file thường phù hợp hơn. Một OpenBao mà không ai unseal đúng cách và không ai rotate secret sẽ tệ hơn một env file có mode 600, vì nó thêm một thành phần dễ hỏng và một bản backup mà bạn có thể cấu hình sai, nhưng không mang lại khả năng rotation nào mà trước đó bạn chưa tự thực hiện.

File env mode 600 có đủ an toàn không?

Thường là có. Mối đe dọa mà nó ngăn chặn là một user khác trên máy đọc được database password của bạn. Unix file permissions xử lý việc đó trước khi network hoạt động.

sudo install -d -m 750 -o root -g myapp /etc/myapp
sudo install -m 640 -o root -g myapp /dev/null /etc/myapp/env
sudoedit /etc/myapp/env

Kiểm tra từ cả hai phía:

sudo -u myapp cat /etc/myapp/env
sudo -u nobody cat /etc/myapp/env

Lệnh đầu in nội dung file. Lệnh thứ hai in cat: /etc/myapp/env: Permission denied vì nobody không thuộc group myapp và file không có world bits. Đó là toàn bộ security model, và nó có hiệu lực thực tế.

Rò rỉ xảy ra ở bước tiếp theo. Một systemd unit có EnvironmentFile= sẽ sao chép các giá trị đó vào process environment, và process environment có thể được đọc.

[Service]
User=myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/usr/local/bin/myapp

sudo cat /proc/$(pgrep -n myapp)/environ | tr '\0' '\n'

Lệnh đó in các secret ở dạng plaintext vì /proc/<pid>/environ có thể được root và user chạy process đọc. Crash reporter gắn environment vào report cũng thấy được các giá trị tương tự. Bất kỳ tool nào chạy dưới cùng account cũng vậy. Vì thế, đưa secret ra khỏi AI agent bắt đầu bằng việc đưa chúng ra khỏi environment. Kết hợp file với một service user có quyền thấp riêng để “user chạy process” không phải là root.

SOPS với age: mã hóa secret để commit lên git

SOPS (secrets operations) mã hóa các giá trị trong file YAML hoặc JSON và giữ nguyên các key ở dạng văn bản thuần. age là một công cụ mã hóa nhỏ gọn cung cấp cho bạn một cặp khóa mà không cần đến key server. Kết hợp lại, chúng cho phép bạn commit secrets.enc.yaml cùng với code của mình, và git diff vẫn cho bạn biết cài đặt nào đã thay đổi mà không tiết lộ nội dung thay đổi cho người đọc.

age đã có sẵn trong Ubuntu 24.04. SOPS thì chưa, vì vậy hãy lấy .deb từ trang release. Phiên bản 3.13.3 là bản hiện hành tính đến tháng 10 năm 2026.

sudo apt update && sudo apt install -y age
curl -LO https://github.com/getsops/sops/releases/download/v3.13.3/sops_3.13.3_amd64.deb
sudo apt install -y ./sops_3.13.3_amd64.deb
sops --version

Tạo một cặp khóa. age-keygen ghi khóa riêng vào file và in khóa công khai ra màn hình, bạn sẽ thấy một dòng bắt đầu bằng Public key: age1....

mkdir -p ~/.config/sops/age
age-keygen -o ~/.config/sops/age/keys.txt
chmod 600 ~/.config/sops/age/keys.txt
age-keygen -y ~/.config/sops/age/keys.txt

Đặt khóa công khai vào .sops.yaml tại thư mục gốc của repository, để bạn không bao giờ phải nhớ nhập recipient trên dòng lệnh.

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c

sops encrypt secrets.yaml > secrets.enc.yaml
sops decrypt secrets.enc.yaml

Một rule không có path_regex sẽ khớp với mọi thứ, đây là điều bạn cần lúc ban đầu. Nếu sau này bạn thêm một rule, hãy viết nó để khớp với file bạn truyền vào sops, vì các rule được kiểm tra dựa trên đường dẫn đầu vào chứ không phải file bạn chuyển hướng đầu ra vào.

Khi chạy, hãy truyền các giá trị cho một tiến trình duy nhất và không gì khác:

sops exec-env secrets.enc.yaml './myapp'

sops exec-env giải mã trong bộ nhớ và thiết lập các giá trị trong môi trường của tiến trình con, vì vậy không có văn bản thuần nào được ghi xuống đĩa. Lưu ý về môi trường từ phần trước vẫn áp dụng cho tiến trình con đó.

Có hai vấn đề thường gây khó khăn. Lỗi Failed to get the data key required to decrypt the SOPS file khi chạy dưới systemd hầu như luôn có nghĩa là SOPS đã tìm sai thư mục home, vì một unit không kế thừa HOME của bạn. Hãy thiết lập đường dẫn một cách tường minh bằng Environment=SOPS_AGE_KEY_FILE=/etc/sops/age.txt trong unit. Ngoài ra, việc chỉnh sửa .sops.yaml không tự động mã hóa lại những gì đã tồn tại: việc thêm khóa công khai của đồng nghiệp chỉ ảnh hưởng đến các file mới, vì vậy hãy chạy sops updatekeys secrets.enc.yaml trên từng file hiện có. Nếu cấu hình của bạn đã chạy qua Ansible, mã hóa các giá trị tương tự bằng Ansible Vault cũng đạt được kết quả tương tự mà không cần thêm công cụ thứ hai.

systemd credentials: các secret không bao giờ đi vào environment

Ubuntu 24.04 đi kèm với systemd 255, vì vậy bạn không cần cài đặt thêm. systemd-creds mã hóa một secret trên host, và systemd sẽ giải mã nó vào một thư mục riêng tư mà chỉ service đó mới có quyền đọc.

sudo systemd-creds setup
sudo install -d -m 700 /etc/myapp
echo -n 'hunter2' | sudo systemd-creds encrypt --name=db_password - /etc/myapp/db_password.cred

[Service]
User=myapp
LoadCredentialEncrypted=db_password:/etc/myapp/db_password.cred
ExecStart=/usr/local/bin/myapp

Service đọc giá trị từ một file có tên db_password nằm trong thư mục được chỉ định bởi $CREDENTIALS_DIRECTORY. Giá trị này không nằm trong environment, nên /proc/<pid>/environ sẽ không hiển thị thông tin gì hữu ích, và plaintext không bao giờ lưu trên root filesystem.

Hãy xác minh file đã được giải mã thành công trước khi trỏ unit vào nó:

sudo systemd-creds decrypt /etc/myapp/db_password.cred -

Bạn cần biết key nào đã mã hóa nó, vì điều này quyết định liệu bản backup của bạn có dùng được hay không. Mặc định --with-key=auto sử dụng chip TPM2 (trusted platform module version 2) nếu tìm thấy và không chạy trong container, hoặc sử dụng host key nếu /var/lib/systemd/ nằm trên phương tiện lưu trữ bền vững. Trên một máy áp dụng cả hai, credential sẽ bị ràng buộc với cả hai, và cả hai phải hiện diện để giải mã. Hầu hết các VPS không có TPM2.

systemd-analyze has-tpm2

no nghĩa là chỉ host key được sử dụng. Key đó nằm tại /var/lib/systemd/credential.secret, chỉ root mới có quyền đọc. Nếu bạn restore db_password.cred sang một VPS mới mà không có file đó, sẽ không có gì giải mã được. Hãy copy credential.secret vào cùng bản backup, hoặc giữ bản plaintext ở nơi bạn có thể truy cập. Nếu nó in ra yes, credential đó cũng bị ràng buộc với chip của máy đó, nên nó sẽ không giải mã được ở bất kỳ đâu khác ngay cả khi có credential.secret, và chỉ có bản plaintext mới giúp được bạn.

Docker secrets: các file trong /run/secrets

Compose đọc một file từ host rồi mount file đó vào container tại /run/secrets/<name>.

services:
  app:
    image: myapp:latest
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
secrets:
  db_password:
    file: ./db_password.txt

docker compose exec app cat /run/secrets/db_password
docker compose exec app env | grep -i password

Lệnh đầu tiên in secret. Lệnh thứ hai chỉ in DB_PASSWORD_FILE=/run/secrets/db_password. Đây mới là điểm quan trọng: giá trị không bao giờ nằm trong environment của container, nên không xuất hiện trong output của docker inspect. Nhiều image chính thức đã được thiết kế để dùng cách này. Image Postgres cũng đọc POSTGRES_PASSWORD_FILE đúng theo cách đó.

Cần hiểu rõ cơ chế này. Ngoài Swarm mode, không có lớp nào mã hóa dữ liệu: ./db_password.txt là một file plaintext trên host, và chỉ được bảo vệ bằng mode cùng owner của file. Tự đặt cả hai thuộc tính này, vì Compose vẫn mount một file cho phép mọi người đọc mà không cảnh báo. Xem hướng dẫn về env file và secret trong Compose để biết đầy đủ hơn về các đánh đổi so với cách viết tắt env_file.

Chi phí vận hành thực tế của OpenBao và Vault

OpenBao là bản fork của HashiCorp Vault thuộc Linux Foundation, được khởi tạo sau khi HashiCorp thay đổi giấy phép của Vault sang Business Source License vào năm 2023. OpenBao vẫn duy trì giấy phép MPL 2.0 (Mozilla Public License). Bản release 2.7.1 là phiên bản hiện hành tính đến tháng 10 năm 2026. Hầu hết các nội dung dưới đây cũng áp dụng cho Vault, vì bản fork này giữ nguyên bề mặt lệnh.

docker pull docker.io/openbao/openbao

Các gói Debian và Ubuntu có sẵn trên trang tải xuống của OpenBao nếu bạn muốn apt quản lý việc nâng cấp. Máy chủ cần một file cấu hình chứa listener và storage backend:

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/path/to/full-chain.pem"
  tls_key_file  = "/path/to/private-key.pem"
}

storage "raft" {
  path = "/path/to/raft/data"
  node_id = "raft_node_1"
}

Sau đó khởi động nó một lần:

bao operator init

Theo mặc định, nó chia root key thành 5 phần và yêu cầu 3 trong số đó để unseal, đây là các flag -key-shares và -key-threshold. Nó in các phần chia sẻ và root token ban đầu ra một lần duy nhất và không bao giờ hiển thị lại.

Bây giờ là phần mà hầu hết các bài so sánh đều bỏ qua. Một máy chủ đã khởi động lại là một máy chủ đã bị sealed. OpenBao chỉ giữ root key trong bộ nhớ, vì vậy sau khi khởi động lại, nó không thể giải mã bộ nhớ của chính mình cho đến khi có người cung cấp đủ số lượng phần chia sẻ theo ngưỡng. Do đó, một bản cập nhật kernel hoặc tiến trình bị kill do thiếu bộ nhớ (OOM) sẽ dẫn đến việc máy chủ bị sealed và các ứng dụng không thể đăng nhập.

Trên một VPS cá nhân, việc chia sẻ Shamir không bảo vệ được gì, vì cả năm phần đều nằm trong cùng một trình quản lý mật khẩu của cùng một người. Auto unseal chuyển key sang một thiết bị hoặc dịch vụ tin cậy; trên cloud lớn, điều này có nghĩa là một dịch vụ quản lý key, còn trên VPS của bạn, nó thường có nghĩa là một file key nằm trên cùng ổ đĩa với dữ liệu mà nó bảo vệ. Đó là sự sụt giảm bảo mật thực sự, để đổi lấy một máy chủ có thể tự khởi động lại sau khi reboot. Hãy thực hiện sự đánh đổi này một cách có ý thức và ghi lại phương án bạn đã chọn.

Infisical: giao diện UI, cơ sở dữ liệu và master key do bạn nắm giữ

Infisical là một nền tảng quản lý secret với giao diện web, hỗ trợ dự án, môi trường và phân quyền truy cập theo người dùng. Việc tự host bằng Compose rất ngắn gọn:

curl -o docker-compose.prod.yml https://raw.githubusercontent.com/Infisical/infisical/main/docker-compose.prod.yml
curl -o .env https://raw.githubusercontent.com/Infisical/infisical/main/.env.example
docker compose -f docker-compose.prod.yml up -d

Hãy chỉnh sửa .env trước khi chạy lệnh cuối cùng. Hai giá trị phải do bạn tự đặt và một trong số đó không bao giờ được thay đổi thủ công sau này:

openssl rand -hex 16
openssl rand -base64 32

Giá trị đầu tiên là ENCRYPTION_KEY, một chuỗi hex 16 byte. Đây là key dùng để mã hóa các secret bên trong PostgreSQL, vì vậy nếu làm mất nó, bản backup cơ sở dữ liệu hoàn hảo cũng chỉ là một đống ciphertext vô dụng. Việc thay thế bằng một giá trị khác trên instance đang chạy sẽ khiến các secret hiện tại không thể giải mã được. Để xoay vòng key, hãy làm theo quy trình được tài liệu hóa của Infisical: console của server sẽ tạo key mới, và key cũ vẫn có hiệu lực cho đến khi mọi instance đã chuyển đổi xong và bạn gỡ bỏ nó. Giá trị thứ hai là AUTH_SECRET, một chuỗi base64 32 byte dùng cho session. SITE_URL phải là URL tuyệt đối mà bạn thực sự truy cập, bao gồm cả giao thức, nếu không quá trình redirect khi đăng nhập sẽ bị lỗi.

Infisical phù hợp hơn OpenBao khi nhu cầu thực tế của bạn là con người: một giao diện web cho nhóm nhỏ và sự phân tách giữa các môi trường, thay vì các credential cơ sở dữ liệu tự hết hạn. Bạn sẽ cần duy trì PostgreSQL, Redis và chứng chỉ TLS, tất cả những thứ này giờ đây nằm trong trách nhiệm patch và backup của bạn.

Điều gì xảy ra khi dịch vụ secrets ngừng hoạt động và ứng dụng của bạn khởi động lại

Câu hỏi này quyết định liệu một dịch vụ secrets có nên nằm trên một máy chủ đơn lẻ hay không. Các file có thể đọc được trước khi mạng khởi động. Một dịch vụ thì không.

Khởi động lại máy chủ và ứng dụng của bạn cùng với OpenBao sẽ bắt đầu tại cùng một thời điểm. Ứng dụng yêu cầu mật khẩu cơ sở dữ liệu, OpenBao vẫn đang bị khóa (sealed), và yêu cầu thất bại. Nếu unit thiết lập Restart=, systemd sẽ khởi động lại ứng dụng cho đến khi có người nhập các share để mở khóa (unseal) hoặc giới hạn tốc độ khởi động do StartLimitIntervalSec= và StartLimitBurst= thiết lập cắt ngang và để nó ở trạng thái thất bại. Nếu không có Restart=, với giá trị mặc định là no, nó đơn giản là sẽ ngừng hoạt động. Không có gì bị hỏng. Nhưng cũng không có gì hoạt động.

Có hai cách trung thực để xử lý vấn đề này. Sắp xếp thứ tự các unit và để ứng dụng thử lại: After= dịch vụ secrets, cộng với Restart=on-failure, một RestartSec= đủ dài để bạn không gửi yêu cầu dồn dập tới API, và một giới hạn tốc độ khởi động không bỏ cuộc trước khi ai đó có thể mở khóa. Hoặc lấy secret tại thời điểm deploy thay vì lúc khởi động: render secret vào một file có mode 600 hoặc một systemd credential, để hệ thống đang chạy phụ thuộc vào một file thay vì một API.

Hết hạn token cũng là vấn đề tương tự trên một đồng hồ chậm hơn. Các token và lease của OpenBao có thời gian tồn tại (TTL), vì vậy một tiến trình chạy dài mà không bao giờ gia hạn sẽ mất quyền truy cập vào một thời điểm không liên quan đến bất kỳ lần deploy nào. Lỗi đó gây khó hiểu chính xác vì không có gì thay đổi trong ngày hôm đó.

Sao lưu chính kho lưu trữ

Mọi tùy chọn ở đây đều có một key, và bản sao lưu không có key đó là vô giá trị. Hãy ghi lại vị trí lưu trữ key của bạn.

Đối với file env, bản thân file đó là bí mật, nên bản sao lưu phải được mã hóa. Đối với SOPS, file đã mã hóa có thể để ở bất cứ đâu công khai, nhưng private key age tại ~/.config/sops/age/keys.txt là thứ bạn tuyệt đối không được làm mất. Đối với systemd credentials, hãy sao lưu /var/lib/systemd/credential.secret cùng với các file .cred. Đối với Infisical, hãy thực hiện một bản dump PostgreSQL và lưu trữ ENCRYPTION_KEY ở một nơi tách biệt. Sau khi xoay vòng key, hãy giữ lại key cũ cùng với bất kỳ bản dump nào được tạo trước đó, vì việc khôi phục bản dump đó cần dùng key cũ.

OpenBao với raft storage tự thực hiện snapshot của chính nó:

bao operator raft snapshot save backup.snap
bao operator raft snapshot restore backup.snap

Snapshot chứa kho lưu trữ đã mã hóa của bạn, vì vậy việc khôi phục nó vào một server mới vẫn cần các unseal share từ bao operator init. Một tác vụ chạy hàng đêm để copy các snapshot vào object storage trong khi các share không được lưu trữ ở đâu cả thì bản sao lưu đó không có giá trị gì. Hãy thử nghiệm việc khôi phục trên một VPS dùng một lần trước khi bạn phụ thuộc vào nó.

Ghi log kiểm toán: ai đã đọc secret nào

File không cung cấp dấu vết kiểm toán. Chế độ (mode) và chủ sở hữu (owner) chỉ cho biết ai có thể đọc secret, chứ không cho biết ai đã thực sự đọc. auditd với một watch trên đường dẫn là giải pháp thay thế gần nhất, nhưng nó chỉ báo cáo rằng file đã được mở, chứ không cho biết giá trị nào đã được sử dụng.

OpenBao ghi log mọi request vào một thiết bị kiểm toán mà bạn kích hoạt rõ ràng. Kể từ bản 2.3.2, việc tạo thiết bị thông qua API, vốn là điều bao audit enable thực hiện, chỉ hoạt động khi cấu hình server thiết lập unsafe_allow_api_audit_creation = true, và tùy chọn này mặc định bị tắt. Hãy khai báo thiết bị trong cấu hình server, đặt cạnh phần listener. OpenBao sẽ kích hoạt nó khi khởi động lại hoặc khi thực hiện SIGHUP:

audit "file" "local" {
  description = "Local audit log"
  options {
    file_path = "/var/log/openbao_audit.log"
  }
}

Có hai sự thật về log này làm thay đổi cách bạn vận hành server. Hầu hết các chuỗi trong request và response đều được hash bằng HMAC-SHA256 kèm theo salt, vì vậy bạn có thể đối chiếu một giá trị mà bạn đã biết với log mà không cần bản thân log đó chứa plaintext. Các số nguyên và giá trị boolean được ghi ở dạng rõ (cleartext), vì vậy một secret dạng số sẽ không được bảo vệ bởi cơ chế hash này.

Tiếp theo là bẫy vận hành: OpenBao sẽ không phản hồi các request khi không có thiết bị kiểm toán nào được kích hoạt để ghi lại chúng, và một thiết bị bị lỗi theo kiểu chặn (blocking) sẽ khiến các request bị treo cho đến khi có người khắc phục. Một ổ đĩa đầy tại /var/log sẽ làm sập API secret của bạn theo thiết kế. Hãy cấp cho log kiểm toán không gian lưu trữ riêng và thiết lập quy tắc logrotate ngay từ ngày đầu tiên, đừng đợi đến khi xảy ra sự cố mới làm.

Bạn nên chạy trình quản lý secrets tự host nào?

Hãy đếm số lượng máy chủ và số lượng người dùng, sau đó đưa ra lựa chọn.

1. Một máy, một người: dùng một file env thuộc sở hữu của root mà chỉ group của service mới có quyền đọc (mode 640, như trên), hoặc file mode 600 để systemd tự đọc cho service thông qua EnvironmentFile=. Hãy thêm systemd credentials khi bạn muốn lấy giá trị ra khỏi môi trường của tiến trình.
2. Một máy, từ hai đến năm người, cấu hình đã có sẵn trong git: dùng SOPS với age. Mỗi người nhận một cặp khóa, và .sops.yaml liệt kê mọi public key được phép giải mã.
3. Nhiều máy, một kho lưu trữ cấu hình, không cần credential có thời hạn: vẫn dùng SOPS với age, với mỗi host một khóa nhận, để nếu khóa host bị đánh cắp thì chỉ giải mã được file của host đó.
4. Nhiều máy và nhiều nhóm thực sự cần credential cơ sở dữ liệu có thời hạn, kèm theo nhật ký kiểm toán để theo dõi: dùng OpenBao, và dành ra một giờ mỗi tháng cho nhân viên vận hành để thực hiện các bài tập mở khóa (unseal) và khôi phục.

Quy tắc cốt lõi cho cả bốn trường hợp đều giống nhau. Hãy chạy công cụ nhỏ nhất đáp ứng được yêu cầu mà bạn có thể nêu rõ, vì một trình quản lý secrets bị sập cũng không khác gì một trình quản lý secrets trống rỗng.

FAQ

Có đáng để tự host một secrets manager cho một VPS duy nhất không?

Thường là không, nếu bạn đang nói đến các dịch vụ như OpenBao hoặc Infisical. Trên một máy chủ với một hoặc hai người dùng, một file env với quyền 600 hoặc tính năng encrypted credential của systemd cung cấp mức bảo vệ tương đương trước các người dùng cục bộ khác, mà không cần bước unseal hay phải vá lỗi cho thêm một dịch vụ nữa. Một dịch vụ quản lý secrets chỉ thực sự hiệu quả khi bạn có nhiều máy chủ, nhiều người dùng, hoặc có nhu cầu thực tế về các thông tin xác thực tự hết hạn mà không cần ai phải xoay vòng thủ công.

Sự khác biệt giữa trình quản lý mật khẩu và trình quản lý secrets là gì?

Trình quản lý mật khẩu lưu trữ thông tin xác thực mà con người nhập vào, và người dùng sẽ mở khóa khi họ đang thao tác. Trình quản lý secrets cung cấp thông tin xác thực cho các tiến trình, vì vậy nó phải hoạt động vào lúc 03:00 sáng mà không có ai giám sát. Hệ quả là điểm khác biệt chính: khi trình quản lý mật khẩu bị khóa, bạn phải nhập lại mật khẩu chủ, còn khi trình quản lý secrets bị sealed, nó sẽ làm dừng mọi dịch vụ khởi động lại trong khi nó đang ở trạng thái bị khóa.

Chuyện gì xảy ra với các ứng dụng của tôi nếu OpenBao bị sealed sau khi reboot?

Chúng không thể lấy được secrets và sẽ không khởi động được. Nếu các unit của chúng thiết lập Restart=, systemd sẽ thử lại cho đến khi có người cung cấp đủ ngưỡng unseal (mặc định là 3 trong số 5 share), hoặc cho đến khi giới hạn tốc độ khởi động unit ngăn việc thử lại. OpenBao chỉ giữ root key trong bộ nhớ, nên mỗi lần khởi động lại nó sẽ bị sealed. Bạn hãy bật tính năng auto unseal (chấp nhận rằng trên một VPS đơn lẻ, unseal key sẽ nằm trên cùng ổ đĩa với dữ liệu) hoặc render secrets ra file tại thời điểm deploy để việc khởi động không bao giờ phụ thuộc vào API.

Tôi có thể commit các file đã mã hóa bằng SOPS lên repository công khai không?

Các giá trị đã được mã hóa nên chúng an toàn trước bất kỳ ai không có private key của age. Các key không được mã hóa: người đọc có thể thấy bạn đang giữ STRIPE_SECRET_KEY và SMTP_PASSWORD, cũng như tần suất thay đổi của từng cái. Metadata đó là chấp nhận được với hầu hết các dự án và không chấp nhận được với một số ít trường hợp. Hãy giữ private key của age bên ngoài repository và chạy sops updatekeys trên mọi file hiện có bất cứ khi nào bạn thêm hoặc xóa người nhận.