बेहतरीन self-hosted secrets manager कैसे चुनें

सेल्फ-होस्टेड सीक्रेट्स मैनेजर वह क्या करता है जो पासवर्ड मैनेजर नहीं करता

एक सेल्फ-होस्टेड सीक्रेट्स मैनेजर प्रोसेस (processes) को क्रेडेंशियल्स प्रदान करता है। एक पासवर्ड मैनेजर लोगों को क्रेडेंशियल्स प्रदान करता है। बाकी सब कुछ इसी एक अंतर से तय होता है। एक पासवर्ड मैनेजर को वह इंसान अनलॉक करता है जो वहां मौजूद है और ध्यान दे रहा है। एक सीक्रेट्स मैनेजर को आपके एप्लिकेशन को रात के 03:00 बजे डेटाबेस पासवर्ड देना होता है जब कोई भी जाग नहीं रहा होता।

इसके फेलियर मोड (failure modes) उस तरह से अलग हैं जो मायने रखते हैं। एक लॉक हुआ पासवर्ड मैनेजर केवल एक असुविधा है: आप मास्टर पासवर्ड दोबारा टाइप करते हैं। एक सील हुआ सीक्रेट्स मैनेजर एक आउटेज (outage) है: हर वह सर्विस जो सील होने के दौरान रीस्टार्ट होती है, वह बिना क्रेडेंशियल्स के शुरू होती है और डाउन रहती है। अपने खुद के पासवर्ड मैनेजर के रूप में Vaultwarden चलाना मानवीय समस्या को अच्छी तरह हल करता है। यह मशीन की समस्या को हल नहीं करता है, और इसे कभी इसके लिए बनाया भी नहीं गया था।

एक सर्वर के लिए व्यावहारिक विकल्प दो समूहों में आते हैं। OpenBao और Infisical सेवाएं हैं: एक API, एक डेटाबेस, TLS (ट्रांसपोर्ट लेयर सिक्योरिटी), एक लॉगिन चरण, और एक ऐसी प्रोसेस जिसे अब आपको जीवित रखना होगा। age के साथ SOPS, systemd क्रेडेंशियल्स और Docker सीक्रेट्स फाइलें हैं: जो डिस्क पर एन्क्रिप्टेड रहती हैं, पहले से चल रही किसी चीज द्वारा डिक्रिप्ट की जाती हैं, और इसमें मॉनिटर करने के लिए कुछ भी अतिरिक्त नहीं होता है।

यहाँ स्पष्ट उत्तर दिया गया है। एक या दो लोगों वाले सिंगल बॉक्स के लिए, फाइल-आधारित विकल्प आमतौर पर सही होते हैं। एक OpenBao जिसे कोई ठीक से अनसील नहीं करता और कोई रोटेट नहीं करता, वह mode 600 वाली env फाइल से भी बदतर है, क्योंकि यह एक मूविंग पार्ट और एक बैकअप जोड़ता है जिसे आप गलत तरीके से मैनेज करेंगे, और यह आपको ऐसी कोई रोटेशन सुविधा नहीं देता जो आप पहले से ही मैन्युअल रूप से नहीं कर रहे थे।

क्या 600 मोड वाली env फाइल पर्याप्त है?

अक्सर, हाँ। यह जिस खतरे से बचाव करती है, वह है सर्वर पर मौजूद किसी अन्य उपयोगकर्ता द्वारा आपके डेटाबेस पासवर्ड को पढ़ लेना। Unix फाइल अनुमतियाँ (permissions) ऐसा करती हैं, और वे नेटवर्क चालू होने से पहले ही प्रभावी हो जाती हैं।

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

इसे दोनों तरफ से जाँचें:

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

पहला कमांड फाइल को प्रिंट करता है। दूसरा कमांड cat: /etc/myapp/env: Permission denied प्रिंट करता है, क्योंकि nobody, myapp समूह में नहीं है और फाइल में कोई वर्ल्ड-रीडेबल बिट्स नहीं हैं। यही पूरा सुरक्षा मॉडल है, और यह एक वास्तविक सुरक्षा मॉडल है।

लीक तब होता है जब इसके बाद की प्रक्रिया होती है। EnvironmentFile= वाली एक systemd यूनिट उन मानों (values) को प्रोसेस एनवायरनमेंट में कॉपी कर देती है, और प्रोसेस एनवायरनमेंट पठनीय (readable) होता है।

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

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

यह आपके सीक्रेट्स को प्लेनटेक्स्ट में प्रिंट करता है, क्योंकि /proc/<pid>/environ को root और उस उपयोगकर्ता द्वारा पढ़ा जा सकता है जिसके तहत प्रोसेस चल रही है। एक क्रैश रिपोर्टर जो रिपोर्ट के साथ एनवायरनमेंट को अटैच करता है, उसे भी यही दिखाई देता है। उसी अकाउंट के तहत चलने वाला कोई भी टूल भी ऐसा ही करता है, इसीलिए AI agents से सीक्रेट्स को दूर रखना एनवायरनमेंट से उन्हें हटाने से शुरू होता है। फाइल को एक समर्पित कम विशेषाधिकार वाले सर्विस यूजर के साथ जोड़ें ताकि "वह उपयोगकर्ता जिसके तहत प्रोसेस चल रही है" root न हो।

age के साथ SOPS: एन्क्रिप्टेड सीक्रेट्स जिन्हें आप git में कमिट कर सकते हैं

SOPS (secrets operations) YAML या JSON फ़ाइल में मौजूद values को एन्क्रिप्ट करता है और keys को cleartext में छोड़ देता है। age एक छोटा एन्क्रिप्शन टूल है जो आपको एक key pair देता है और इसके लिए किसी key server की आवश्यकता नहीं होती। साथ में, ये आपको अपने कोड के साथ secrets.enc.yaml कमिट करने की सुविधा देते हैं, और git diff अभी भी आपको यह बताता है कि कौन सी सेटिंग बदली है, बिना यह बताए कि वह किस मान (value) में बदली है।

age, Ubuntu 24.04 में पैकेज्ड है। SOPS नहीं है, इसलिए release page से .deb लें। अगस्त 2026 तक version 3.13.3 वर्तमान था।

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

एक key pair जनरेट करें। age-keygen private key को फ़ाइल में लिखता है और public key को प्रिंट करता है, इसलिए आपको 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

public key को रिपॉजिटरी के रूट में .sops.yaml में रखें, ताकि आपको कमांड लाइन पर recipient को याद रखने की आवश्यकता न पड़े।

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c

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

बिना path_regex वाला नियम हर चीज़ से मेल खाता है, जो कि शुरुआत में आप चाहते हैं। यदि आप बाद में कोई नियम जोड़ते हैं, तो उसे उस फ़ाइल से मेल खाने के लिए लिखें जिसे आप sops में पास करते हैं, क्योंकि नियमों की जाँच input path के आधार पर की जाती है, न कि उस फ़ाइल के आधार पर जिसमें आप output को रीडायरेक्ट करते हैं।

रनटाइम पर, values को केवल एक प्रोसेस को दें और किसी अन्य को नहीं:

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

sops exec-env मेमोरी में डिक्रिप्ट करता है और child process environment में values सेट करता है, इसलिए डिस्क पर कोई भी plaintext नहीं लिखा जाता है। पिछले सेक्शन की environment संबंधी चेतावनी अभी भी उस child पर लागू होती है।

यहाँ दो चीजें लोगों को परेशान करती हैं। systemd के अंतर्गत Failed to get the data key required to decrypt the SOPS file त्रुटि का मतलब लगभग हमेशा यह होता है कि SOPS ने गलत home directory में देखा है, क्योंकि एक unit आपके HOME को इनहेरिट नहीं करती है। unit में Environment=SOPS_AGE_KEY_FILE=/etc/sops/age.txt के साथ path को स्पष्ट रूप से सेट करें। इसके अलावा, .sops.yaml को एडिट करने से पहले से मौजूद कोई भी चीज़ फिर से एन्क्रिप्ट नहीं होती है: किसी सहकर्मी की public key जोड़ने से केवल नई फ़ाइलें प्रभावित होती हैं, इसलिए प्रत्येक मौजूदा फ़ाइल पर sops updatekeys secrets.enc.yaml चलाएं। यदि आपका कॉन्फ़िगरेशन पहले से ही Ansible के माध्यम से चलता है, तो Ansible Vault के साथ उन्हीं values को एन्क्रिप्ट करना दूसरे टूल के बिना उसी परिणाम तक पहुँचता है।

systemd credentials: secrets जो environment तक कभी नहीं पहुँचते

Ubuntu 24.04 में systemd 255 शामिल है, इसलिए इसके लिए किसी अलग install की आवश्यकता नहीं है। systemd-creds host पर एक secret को encrypt करता है, और systemd उसे एक private directory में decrypt करता है जिसे केवल वही एक service पढ़ सकती है।

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 $CREDENTIALS_DIRECTORY द्वारा नामित directory के अंदर db_password नामक file से मान (value) पढ़ती है। यह मान environment में नहीं होता है, इसलिए /proc/<pid>/environ कुछ भी उपयोगी नहीं दिखाता है, और plaintext कभी भी root filesystem पर नहीं पहुँचता है।

यह सुनिश्चित करें कि file unit को उस पर point करने से पहले decrypt हो जाती है:

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

यह जानें कि किस key ने इसे encrypt किया है, क्योंकि यह तय करता है कि आपका backup किसी काम का है या नहीं। डिफ़ॉल्ट --with-key=auto TPM2 (trusted platform module version 2) chip का उपयोग करता है जब वह मौजूद और उपयोग योग्य हो, अन्यथा यह host key का उपयोग करता है। अधिकांश VPS instances में TPM2 नहीं होता है।

systemd-analyze has-tpm2

no का अर्थ है कि host key का उपयोग किया गया था, और वह key /var/lib/systemd/credential.secret में रहती है, जिसे केवल root ही पढ़ सकता है। db_password.cred को उस file के बिना एक नए VPS पर restore करें और कुछ भी कभी decrypt नहीं होगा। credential.secret को उसी backup में copy करें, या plaintext को कहीं ऐसी जगह रखें जहाँ आप अभी भी पहुँच सकें।

Docker secrets: /run/secrets के अंतर्गत फाइलें

Compose होस्ट से एक फाइल पढ़ता है और उसे कंटेनर में /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

पहला कमांड secret को प्रिंट करता है। दूसरा केवल DB_PASSWORD_FILE=/run/secrets/db_password को प्रिंट करता है, जो कि मुख्य बात है: मान (value) कभी भी कंटेनर environment में नहीं होता है, इसलिए यह docker inspect आउटपुट में दिखाई नहीं देता है। कई official images पहले से ही इस प्रारूप की अपेक्षा करती हैं, और Postgres image POSTGRES_PASSWORD_FILE को बिल्कुल इसी तरह पढ़ती है।

स्पष्ट रहें कि यह क्या है। Swarm mode के बाहर किसी भी स्तर पर कोई encryption नहीं होता है: ./db_password.txt होस्ट पर एक plaintext फाइल है, और इसकी एकमात्र सुरक्षा इसका mode और इसका owner है। दोनों को आप स्वयं सेट करें, क्योंकि Compose बिना किसी चेतावनी के world-readable फाइल को भी खुशी-खुशी माउंट कर देगा। सादे env_file शॉर्टकट के मुकाबले इसके tradeoffs के बारे में अधिक जानकारी Compose env फाइलों और secrets के लिए गाइड में उपलब्ध है।

OpenBao और Vault को चलाने की वास्तविक लागत

OpenBao, HashiCorp Vault का Linux Foundation फोर्क है। इसे 2023 में HashiCorp द्वारा Vault को Business Source License के अंतर्गत पुनः लाइसेंस करने के बाद शुरू किया गया था। OpenBao, MPL 2.0 (Mozilla Public License) के अंतर्गत आता है। अगस्त 2026 तक Release 2.6.2 वर्तमान संस्करण था। नीचे दी गई लगभग सभी बातें Vault पर भी लागू होती हैं, क्योंकि फोर्क ने समान कमांड सरफेस को बरकरार रखा है।

docker pull docker.io/openbao/openbao

यदि आप चाहते हैं कि apt अपग्रेड्स को मैनेज करे, तो Debian और Ubuntu पैकेज OpenBao डाउनलोड पेज पर उपलब्ध हैं। सर्वर को एक ऐसी कॉन्फ़िगरेशन फ़ाइल की आवश्यकता होती है जिसमें एक लिसनर और एक स्टोरेज बैकएंड हो:

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"
}

इसके बाद इसे एक बार स्टार्ट करें:

bao operator init

डिफ़ॉल्ट रूप से, यह रूट की (root key) को 5 हिस्सों में विभाजित करता है और अनसील (unseal) करने के लिए उनमें से 3 की आवश्यकता होती है, जो -key-shares और -key-threshold फ्लैग्स हैं। यह इन हिस्सों और शुरुआती रूट टोकन को केवल एक बार प्रिंट करता है और दोबारा कभी नहीं दिखाता।

अब वह हिस्सा जिसे अधिकांश तुलनाओं में छोड़ दिया जाता है। रीस्टार्ट हुआ सर्वर एक सील्ड (sealed) सर्वर होता है। OpenBao रूट की को केवल मेमोरी में रखता है, इसलिए रीस्टार्ट के बाद यह तब तक अपने स्टोरेज को डिक्रिप्ट नहीं कर सकता जब तक कोई व्यक्ति आवश्यक संख्या में हिस्से (shares) प्रदान न करे। इसलिए, कर्नेल अपडेट या आउट ऑफ मेमोरी (OOM) किल के परिणामस्वरूप सर्वर सील्ड हो जाता है और एप्लिकेशन लॉग इन नहीं कर पाते।

एक व्यक्ति के VPS पर, Shamir स्प्लिट किसी चीज की सुरक्षा नहीं करता, क्योंकि सभी पांचों हिस्से एक ही व्यक्ति के पासवर्ड मैनेजर में होते हैं। ऑटो अनसील (Auto unseal) की को किसी विश्वसनीय डिवाइस या सर्विस पर ले जाता है। बड़े क्लाउड पर इसका अर्थ एक मैनेज्ड की सर्विस होता है, और आपके VPS पर इसका आमतौर पर अर्थ एक ऐसी की फ़ाइल है जो उसी डिस्क पर स्थित है जिसे वह सुरक्षित करती है। यह सुरक्षा में वास्तविक कमी है, जिसे एक ऐसे सर्वर के बदले स्वीकार किया जाता है जो रीबूट के बाद अपने आप वापस आ जाता है। इस समझौते को समझदारी से करें और नोट कर लें कि आपने कौन सा विकल्प चुना है।

Infisical: एक UI, एक डेटाबेस, और एक मास्टर की जो आपके पास रहती है

Infisical एक secrets प्लेटफॉर्म है जिसमें वेब इंटरफेस, प्रोजेक्ट्स, एनवायरनमेंट और प्रति-उपयोगकर्ता एक्सेस कंट्रोल की सुविधा है। इसे Compose के साथ self-host करना बहुत सरल है:

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

अंतिम कमांड चलाने से पहले .env को एडिट करें। दो मान (values) आपके स्वयं के होने चाहिए, और उनमें से एक को बाद में कभी नहीं बदला जाना चाहिए:

openssl rand -hex 16
openssl rand -base64 32

पहला ENCRYPTION_KEY है, जो 16 बाइट की एक hex स्ट्रिंग है। यह वह की (key) है जिससे आपके secrets PostgreSQL के अंदर एन्क्रिप्ट होते हैं, इसलिए इसे खोने का मतलब है कि आपका डेटाबेस बैकअप केवल ciphertext का ढेर बनकर रह जाएगा, और चल रहे इंस्टेंस पर इसे बदलने से मौजूदा secrets डिक्रिप्ट नहीं हो पाएंगे। दूसरा AUTH_SECRET है, जो सेशन के लिए इस्तेमाल होने वाली 32 बाइट की base64 स्ट्रिंग है। SITE_URL वह पूर्ण URL होना चाहिए जिसे आप वास्तव में एक्सेस करेंगे, जिसमें प्रोटोकॉल भी शामिल हो, अन्यथा लॉगिन रीडायरेक्ट काम नहीं करेगा।

Infisical तब OpenBao से बेहतर विकल्प है जब आपको वास्तव में लोगों के प्रबंधन की आवश्यकता हो: एक छोटी टीम के लिए वेब इंटरफेस और एनवायरनमेंट के बीच अलगाव, न कि ऐसे डेटाबेस क्रेडेंशियल्स जो अपने आप एक्सपायर हो जाते हैं। इसके लिए आपको PostgreSQL, Redis और एक TLS सर्टिफिकेट की आवश्यकता होती है, जिन्हें अब आपको स्वयं पैच और बैकअप करना होगा।

जब secrets service बंद हो और आपका app restart हो तो क्या होता है

यह प्रश्न तय करता है कि क्या secrets service को एक ही सर्वर पर होना चाहिए। नेटवर्क शुरू होने से पहले फाइलें पढ़ी जा सकती हैं, लेकिन एक service नहीं।

सर्वर को reboot करें, आपका application और OpenBao एक ही समय पर शुरू होते हैं। application अपने database password के लिए अनुरोध करता है, OpenBao अभी भी sealed है, अनुरोध विफल हो जाता है, और systemd application को तब तक loop में restart करता रहता है जब तक कोई व्यक्ति unseal shares दर्ज न कर दे। कुछ भी टूटा नहीं है, लेकिन कुछ भी चल भी नहीं रहा है।

इसे संभालने के दो ईमानदार तरीके हैं। units को क्रमबद्ध करें और application को retry करने दें: After= secrets service, साथ ही Restart=on-failure और एक RestartSec= जो इतना लंबा हो कि आप API पर लगातार दबाव न डालें। या फिर boot के समय के बजाय deploy के समय secret प्राप्त करें: secret को mode 600 वाली फाइल या systemd credential में रेंडर करें, ताकि चलता हुआ सिस्टम API के बजाय एक फाइल पर निर्भर रहे।

Token की समाप्ति धीमी गति वाली घड़ी पर एक समान समस्या है। OpenBao tokens और leases की एक निश्चित समय सीमा (time to live) होती है, इसलिए एक लंबे समय तक चलने वाली प्रक्रिया जो कभी renew नहीं होती, वह किसी भी deploy से असंबंधित समय पर access खो देती है। वह विफलता विशेष रूप से भ्रमित करने वाली होती है क्योंकि उस दिन कुछ भी बदला नहीं होता है।

स्टोर का बैकअप लेना

यहाँ दिए गए प्रत्येक विकल्प के लिए एक key आवश्यक है, और उस key के बिना बैकअप बेकार है। यह नोट कर लें कि आपकी key कहाँ स्थित है।

एक env file के लिए, फाइल ही secret है, इसलिए बैकअप को encrypted होना चाहिए। SOPS के लिए, encrypted फाइल को कहीं भी public स्थान पर रखा जा सकता है, लेकिन ~/.config/sops/age/keys.txt पर मौजूद age private key वह चीज है जिसे आपको खोना नहीं चाहिए। systemd credentials के लिए, .cred फाइलों के साथ /var/lib/systemd/credential.secret का बैकअप लें। Infisical के लिए, PostgreSQL dump लें और ENCRYPTION_KEY को उससे अलग किसी स्थान पर सुरक्षित रखें।

raft storage के साथ OpenBao अपना snapshot स्वयं लेता है:

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

snapshot में आपका encrypted storage होता है, इसलिए इसे एक नए सर्वर पर restore करने के लिए भी bao operator init से unseal shares की आवश्यकता होती है। एक nightly job जो snapshots को object storage में कॉपी करती है, जबकि shares कहीं भी सुरक्षित नहीं हैं, वह किसी भी काम का बैकअप नहीं है। उस पर निर्भर होने से पहले एक throwaway VPS पर restore का परीक्षण करें।

Audit logging: कौन सा secret किसने पढ़ा

Files आपको कोई audit trail नहीं देती हैं। mode और owner केवल यह बताते हैं कि secret को कौन पढ़ सकता था। वे कभी यह नहीं बताते कि किसने पढ़ा। path पर watch के साथ auditd इसका सबसे करीबी विकल्प है, और यह केवल यह रिपोर्ट करता है कि फाइल खोली गई थी, न कि कौन सा मान (value) इस्तेमाल किया गया था।

OpenBao हर request को एक audit device पर log करता है जिसे आप स्पष्ट रूप से enable करते हैं:

bao audit enable file file_path=/var/log/openbao_audit.log

उस log के बारे में दो तथ्य यह बदलते हैं कि आप सर्वर को कैसे चलाते हैं। requests और responses में अधिकांश strings को HMAC-SHA256 और एक salt के साथ hash किया जाता है, इसलिए आप log में मौजूद plaintext के बिना भी किसी ज्ञात मान (value) का मिलान कर सकते हैं। Integers और booleans को clear text में लिखा जाता है, इसलिए numeric secret को उस hashing से कोई सुरक्षा नहीं मिलती है।

फिर एक operational trap है: जब कोई enabled audit device उन्हें record नहीं कर पाता है, तो OpenBao requests का जवाब नहीं देगा, और यदि कोई device blocking तरीके से विफल हो जाता है, तो requests तब तक hang रहेंगी जब तक कोई उसे ठीक नहीं कर देता। /var/log पर disk का भर जाना आपके secrets API को design के अनुसार down कर देता है। audit log को अपना अलग space दें और पहले दिन ही logrotate rule लागू करें, न कि पहली outage के बाद।

आपको कौन सा self-hosted secrets manager चलाना चाहिए?

मशीनों की संख्या और लोगों की संख्या गिनें, फिर चुनाव करें।

1. एक मशीन, एक व्यक्ति: root के स्वामित्व वाली और service user द्वारा पढ़ी जाने वाली mode 600 env file का उपयोग करें। जब आप process environment से value प्राप्त करना चाहते हैं, तो systemd credentials जोड़ें।
2. एक मशीन, दो से पांच लोग, configuration पहले से ही git में है: age के साथ SOPS का उपयोग करें। प्रत्येक व्यक्ति को एक key pair मिलता है, और .sops.yaml उन सभी public keys को सूचीबद्ध करता है जिन्हें decrypt करने की अनुमति है।
3. कई मशीनें, एक configuration repository, ऐसे credentials की आवश्यकता नहीं जो expire होते हों: अभी भी age के साथ SOPS का उपयोग करें, जिसमें प्रति host एक recipient key हो, ताकि चोरी हुई host key केवल उसी host की files को decrypt कर सके।
4. कई मशीनें और कई टीमें जिन्हें वास्तव में lifetime वाले database credentials की आवश्यकता है, साथ ही एक audit trail जिसे कोई पढ़ता हो: OpenBao का उपयोग करें, और unsealing तथा restore drills के लिए प्रति माह एक घंटे का operator समय बजट में रखें।

इन चारों के पीछे का नियम एक ही है। वह सबसे छोटी चीज़ चलाएं जो आपकी उस आवश्यकता को पूरा करती हो जिसे आप स्पष्ट रूप से बता सकें, क्योंकि एक secrets manager जो down है, वह एक ऐसे secrets manager से अलग नहीं है जो खाली है।

FAQ

क्या एक VPS के लिए self-hosted secrets manager का उपयोग करना उचित है?

आमतौर पर नहीं, यदि आपका तात्पर्य OpenBao या Infisical जैसी सेवाओं से है। एक सर्वर और एक या दो उपयोगकर्ताओं के लिए, mode 600 वाली env file या systemd encrypted credential किसी अन्य स्थानीय उपयोगकर्ता के विरुद्ध समान सुरक्षा प्रदान करते हैं। इसमें न तो unseal करने की प्रक्रिया की आवश्यकता होती है और न ही पैच करने के लिए कोई अतिरिक्त सेवा। secrets service तब उपयोगी होती है जब आपके पास कई मशीनें और कई उपयोगकर्ता हों, या आपको ऐसे credentials की आवश्यकता हो जो बिना किसी मानवीय हस्तक्षेप के expire हो जाएं।

Password manager और secrets manager में क्या अंतर है?

Password manager उन credentials को सुरक्षित रखता है जिन्हें कोई व्यक्ति टाइप करता है और जिसे वह स्वयं unlock करता है। Secrets manager प्रक्रियाओं (processes) को credentials प्रदान करता है, इसलिए इसे रात के 3 बजे भी बिना किसी मानवीय निगरानी के काम करना होता है। इसका परिणाम यह है कि locked password manager आपसे master password दोबारा मांगता है, जबकि sealed secrets manager उन सभी सेवाओं को रोक देता है जो seal होने के दौरान restart होती हैं।

यदि reboot के बाद OpenBao seal हो जाए तो मेरे apps का क्या होगा?

वे अपने secrets प्राप्त नहीं कर पाएंगे, इसलिए वे start होने में विफल हो जाएंगे। systemd उन्हें बार-बार restart करने का प्रयास करेगा जब तक कि कोई unseal threshold प्रदान न कर दे, जो डिफ़ॉल्ट रूप से 5 में से 3 shares होता है। OpenBao root key को केवल memory में रखता है, इसलिए हर restart पर यह फिर से seal हो जाता है। या तो auto unseal को चालू करें (यह स्वीकार करते हुए कि एक VPS पर unseal key उसी डिस्क पर होगी जहाँ डेटा है), या deploy के समय secrets को एक file में render करें ताकि booting प्रक्रिया API पर निर्भर न रहे।

क्या मैं SOPS encrypted files को public repository में commit कर सकता हूँ?

values encrypted होती हैं, इसलिए वे age private key के बिना किसी के लिए भी सुरक्षित हैं। keys encrypted नहीं होती हैं: कोई भी यह देख सकता है कि आपके पास STRIPE_SECRET_KEY और SMTP_PASSWORD हैं, और वे कितनी बार बदलते हैं। अधिकांश प्रोजेक्ट्स के लिए यह metadata स्वीकार्य है, लेकिन कुछ के लिए नहीं। age private key को repository से बाहर रखें, और जब भी आप कोई recipient जोड़ें या हटाएं, तो हर मौजूदा file पर sops updatekeys चलाएं।